针对12306问题乱弹架构设计


关于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该怎么做,这个其实不是问题,因为铁道部根本没有问过这个问题,就如同给京东提建议给支付宝提建议无人响应一样,都不过是技术人手痒产生的意淫罢了。不过这些讨论还是可以看出很多闪光点,让我们在以后的设计中采用或者注意类似的方案。


《“针对12306问题乱弹架构设计”》 有 1 条评论

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注