关于12306网站架构，不少人提出了自己的设计思路，有的人很简单，比如说nodejs就行，nosql一定可以，或者是某某方案最适合了。看了不少文章，感觉还是coolshell的最实际靠谱 http://coolshell.cn/articles/6470.html 。由于末学对网站架构方面翻译的文章很少，不敢说自己是大型网站架构师，实战经验更是没有，就不充大头提什么技术方案了，只从比较虚的架构设计方面说说自己的一些见解。
一个实际的不成功例子
最近组内一个内部项目，从设计到实现一起群体智慧完成，但是进度和完成质量却比我想象的差了很多。项目很简单，大概就是一千多条数据，使用Asp.net MVC3搭建。为了技术练手，把后台部分大部分逻辑做成webservice，使用WCF搭建。业务内容也相当简单，不过就是CRUD。因为数据库使用Access（客户决定），所以SQL都是手写，包装成DBHelper给业务使用。就这样一个简单设计，却也经过了两次总体设计，比预期进度慢了很多，完成度和设计优美程度都比预期的差。个人感觉而言，项目不能说失败，但也称不上成功。好在我们当时的想法就是用这个项目来锻炼团队，这样想心里还能好受些。
自我反思，不成功原因很简单，最主要是团队在这方面经验不足造成的（还有其它原因不方便说）。某个人是否能很好地完成一项工作，首要的是态度，其次是能力，所以选择的时候这两方面都需要考虑清楚。另外，对于新人不要设置太高标准，需要适当给以监督和辅导。
从这个实际例子就可以看出来，架构问题不会也不可能是简单的说几句话，指个方向就能完成。再好的纸上谈兵，放在现实中也可能出现预料不到的困难。所以最好的办法是找靠谱的人，最好是有相关经验的靠谱的人，去做靠谱的事；从试错的过程中吸取教训，不断完善架构设计。架构师的工作不仅仅是把简单问题复杂化或者复杂问题简单化，而是根据项目具体需要，以及相关环境约束，平衡取舍得到一个最合适的方案。
12306的问题
由于春节出行需要，在12306上购买了往返车票，在购买春节前车票的时候，遇到了无法登录的问题，大约花了将近两个小时，才登录成功，并且在下订单时也碰到几次问题，但是总体而言，相比去火车站排队还是要轻松很多，另外提前12天购票也让购票更提前了。
没有准确数据，很难估计12306在高峰时的并发和负载到底是什么样的。如同下面报道中的数据一样，不少说法要么不专业，要么有水分，很难让人信服。http://bschool.sohu.com/20120117/n332409067.shtml 另外铁老大的封闭性以及项目本身可能具有的保密性，谁设计实现，花了多少钱，大致架构如何，也都是个迷。
在9月份以后大致有两个并发相关的大事件，一个是京东促销，两次促销两次接近当机，成绩只能说不及格。另外是淘宝还是淘宝商城的双十一促销，没有怎么关注，据说效果还不错。
除了淘宝比较开放一些，架构方面的宣传比较多，京东这个新晋小生一样是对架构讳莫如深，或者从另一个方面说明，刘强东这个人并不怎么重视信息系统建设。
相比这两个事件而言，12306的成绩不算太好，但也不算差，如果我评分，会给一个70分，已经是及格以上。12306的问题不是技术问题，而是人的问题，或者说是一个权势角力的结果。技术选择从来都不是从底层技术人员发起的。
另外有人评论：界面丑，用户体验差。这个真的不是问题。不少微博上叫唤的欢实的，他们自己公司内部系统的界面和用户体验可能会更差，尤其以报销系统或者人事系统更甚。说句实在的，他们连自己boss都说服不了，让他们自己换换这些差系统，还提出这个那个方面，实在是没有说服力啊。
架构再好，也要团队，软件开发的关键是人
有不少人一说高负载分布式，动辄就是什么nodejs，nosql，缓存，文件系统，大数据这些关键词，好像这些关键词一说，问题立马就解决了。问题在于，这些关键词只是一些点，架构设计和实现其实是一个面或者是立体的。
举一个简单的例子，一个团队，其中的成员大部分是dotnet背景或者是java背景，他们熟悉的是sqlserver或者是oracle，了解的是项目中用到的那些技术，超出这个范围的，不知道不了解都是理所应当的。这样一个团队，如果某个架构师听说nodejs或者nosql可以解决他们的问题，边学边做，照猫画虎，摸着石头过河。你觉得这样的项目会成功吗？！
所以，只有团队整体素质够高，才能够产生一个比较完美的解决方案。这样的团队，只能是有腔调的技术带头人加上比较靠谱的执行者才行。
合适的架构是磨出来的，没有一开始完美无瑕的方案
@fire9 在微博上说好的架构不是设计出来的，而是运维出来的，我对运维这个方向了解很少，对此不评论。我的观点是合适架构是磨出来的，需要一个持之以恒，反复迭代的过程，在某个阶段，也许还需要涅磐重生，关于这个观点，在《The Pragmatic Programmer: From Journeyman to Master》书里就有一个完美草地的例子。
架构设计必须满足几个条件，一个是满足客户需求，在微博上不少人提出种种解决方案，但是越看越像是在炫技，是他们自己有这方面的需要和想法，与客户需求没有一毛钱关系。合适的架构也要获得高层的支持和投入，这一点在中国尤其重要。还有一点，合适的架构要考虑到执行效果，仅仅设计出来，无法实现也是不行的。好的架构师必须保证控制自己的欲望，不要什么技术都往上堆，什么需求都想满足，否则项目的结果只能是失控。
如何磨一个架构？我的经验不多，简单说一些务虚的内容。首先是态度积极，真心想把事情做好，而不是凑付。另外要保证项目的长期性，让团队有归属感。技术上保证不断学习，整个团队一直保持上升势头。另外是团队搭配合理，主力程序员，程序员，项目经理搭配工作，没有很明显的短板。有了这些软件支持，磨出一个好架构不是难事。
方案是经验的体现
回到12306的设计方案可以看出，云风的方案有点类似网游服务器，酷壳陈皓在服务器开发和Amazon积累的经验，让他能够介绍一些关于业务上的问题。 他们以往的经验很好的反映在设计方案中。
如果真的要设计方案，谷歌百度腾讯这些公司里面的大规模并发/大数据/高可用性这些方面的专家很有帮助，但我更相信，来自淘宝Amazon这样电商公司的经验更准确有力，因为他们对业务更熟悉，对于业务流程设计中可能有的风险问题会有更好的体会。技术必须契合业务，才能发挥正面作用。任何时候都不应该是先提技术后谈需求，可惜这样本末倒置的事情经常发生。
12306该怎么做，这个其实不是问题，因为铁道部根本没有问过这个问题，就如同给京东提建议给支付宝提建议无人响应一样，都不过是技术人手痒产生的意淫罢了。不过这些讨论还是可以看出很多闪光点，让我们在以后的设计中采用或者注意类似的方案。
