wamp5.2.1集成包:针对12306.cn网站应用架够的一些看法

[置顶]针对12306.cn网站应用架够的一些看法

背景

针对最近比较热点的列车网上订票系统频繁出现的系统问题，提出了一些自己的看法。

分析

几经分析考虑，认为可能存在几个系统瓶颈。

1.关联系统的系统负载能力比较弱。

2.网上支付的负载能力不够

3.网站本身吞吐量问题

4.网站出口带宽不足

方案

针对以上分析的一些可能的问题点，提出了一些自己的想法

1.关联系统接口问题的话，我的想法是采用排队制。用户登录以后根据车次取号排队，排到后进行订票付款，这样可以减少并发数，保证系统可用率

2.网上支付系统负载不足，可以采用异步。用户订完票以后进入队列，因订票时候是根据实时的数据订票的，因此不会说支付后无票取的情况。队列中的用户可以一次取支付系统允许的人数进行支付操作。完成后用短信或者邮件通知下一批用户登录系统进行操作。在系统可用率提高的情况下，减少了因错误不停操作带来的压力

3.网站服务器问题，可以将重点的功能，如登录和订票两个分出来，投入较多的服务器，其他查询等功能因可使用缓存可减少服务器投入。各个服务之间用sso。登录oid或服务器采用master slave，注册网master 登录等查询用slave

4.网站出口带宽问题，这个没有好办法，可以用在主要的几个城市各部署一套。因铁道部门系统应该是全国联网，因此接口不成问题。这样可以充分利用网络带宽资源。

以上就是我分析出的一些结论，谨用于理论分析探讨。欢迎高人赐教。

思考

关于分流和其他电子商务网站类比。

    这几天我在网站上也看到很多关于12306.cn的讨论，其中有方案是借鉴成功电子商务网站如淘宝，京东的经验。还有一个就是类似于机票订购的分流。

    对于这两个方案我也有一些思考，除去商业上的一些利益关系。从技术角度上去分析，认为方案有待商榷。

    1.首先说下c2c和b2c型电子商务网站，有个特点，就是商品缺货时可以进货。而机票，火车票这种特殊的商品一天就那么多，没办法在增加。因此在逻辑上是不同的，前者在订单的控制上显的比较宽松，而后者就比较严谨。

    2.再来看下火车票是否可以借鉴订机票的方案，抛去铁老大是否愿意和分销商分享这块蛋糕。抛去分销商绞尽脑汁去想办法分享这块蛋糕，但从技术角度上去考虑。我在考虑了相当长一段时间认为也不是很可行。

    对于第2点有点改进的地方是各分销商网站可以自行支付，这点上确实可以缓解支付的压力。但是火车和飞机这个压力不是一个数量级的。飞机一天多少航班？春运期间火车多少列次？从乘客数量上讲（数量就是系统压力的来源）更不是一个层次。那航信的原始接口走socket协议，是否能够集中承受那么大的压力也是个疑问。不用说经过webservice/rmi之类封装过的接口了。

    总之，我还是认为能够控制系统核心功能的访问量是一个方面。因为在没有经过实际使用时是不知道有多大的并发量。就算知道了春运的客流量也不等于就知道了系统的访问量，并发数。而且在技术能力有限的情况下能够很好的控制用户的访问并发也是一个办法。这个和系统性能优化并不冲突。当然系统优化后控制的口径可以放宽。但系统的性能也是有峰值的，并不是无限大的，因此还是需要一个控制阀来控制。这样才不至于系统出现服务无法使用的情况。

跟踪：

 根据最新网易的一片文章，确实有一点应该是符合我的猜想的，就是12306.cn后有铁道部的核心系统。这个是已成型的系统，而且铁道部自称曾多次获奖，应该还算比较稳定的系统。按照铁道部的说法关键是访问量。

确实，12306.cn在正式上线投入生产前没有经过足够的测试和试运行。风险评估误差很大，可能也是政治原因造成的。大家都知道政治问题是很紧要的问题，尤其是做过金融系统的人更有深刻体会。上峰命令*****系统需哪一天上线，因此大家就要没天没夜开始加班，最后很重要的工作往往草草收场，因此忽略了很多极为重要的环节。这个也是造成12306.cn今天如此局面的一个原因。不过这个就不是技术上的因素，而是项目管理的因素了。

以下内容来自网易：http://news.163.com/12/0113/17/7NLPCOST00014JB5.html

问：能否给我们介绍一下，12306互联网购票系统的发展情况？

答：12306互联网购票系统是基于中国铁路客票发售和预订系统(以下简称客票系统)这一核心系统构建的。该客票系统于1996年6月被列为“九五”国家科技攻关计划，98年又列为“九五”国家科技攻关计划重中之重项目。在铁道部的领导下，由中国铁道科学研究院牵头组织，由全国数十家高校和科研机构的上百名科研工作者联合攻关，采用核心技术自主研发、通用软硬平台开放的技术路线，历时两年研发成功。

2011-1-15 0:19 更新

看来很不幸，铁道部也逃脱不了软件开发的弊病，我在上面说了项目挂你方面因政治原因导致系统匆匆上马，刚浏览网易新闻时看到一篇文章印证了我以上的观点

以下内容摘自网易http://discovery.163.com/12/0114/10/7NNKG3NU000125LI.html

1. 准备不足问题重重  
2.   
3. 回望12306网站在2011年12月底以来的表现，铁道部高层也直呼想不到。  
4.   
5. 铁道部副部长胡亚东介绍，今年第一次在全国铁路实行网络电话订票，截至1月8日已经达到每天200万张，12306网站的注册用户已超过1000万人。1月1日至7日，“12306”网站日均点击次数已经超过了10亿次，专家认为瞬间点击可能达到了“世界第一”。  
6.   
7. 高度的关注、巨大的访问量，导致12306网站频繁出现系统崩溃、无法登陆、无法支付等情况。  
8.   
9. “像春运这样庞大的需求量，难道铁道部没有预想到并有所准备？”隆梅资本管理有限公司副总经理马宏兴对此困惑不解。  
10.   
11. 在探究12306网站问题的深层原因以及解决之道时，各家看法不同，“12306网站的问题最终还是系统架构的问题。因为用户有大量的动态、交互式访问，所有的请求都会发送到12306网站的服务器端，同时在线并发用户数量太多，导致网站无力承载，造成拥堵。”华南师范大学计算机学院副院长单志龙认为。  
12.   
13. 又有说法认为，如果给12306网站增加服务器和带宽，也能够缓解拥堵的症状。这一观点铁道部内部颇为认同。  
14.   
15. “得承认，我们对访问量估计得不足。”铁道部信息技术中心一位中层向记者透露，12306网站曾在2011年春运期间试运行，高峰时段访问量约在1亿点击量，因此，信息中心估计2012年春运期间的访问量约在3亿至4亿。  
16.   
17. 但是，结果却大大出乎人们的预料。“12306”网站在1月9日的日点击量达到14亿次，是原来料想峰值的5倍之多。“崩溃”在所难免！  
18.   
19. 另外一个原因是“上马得太过仓促”。铁道部一位不愿透露姓名的高层向记者透露，事实上网络售票系统的上线在前部长刘志军时代因种种背后利益纠纷，迟滞多年未能成行，直到现任部长盛光祖上台之后，号令加速上马，“以至于应对不了如今庞大的需求量”。  
20.   
21. 据记者了解，“12306”从方案设计招标、设备采购到正式投放运行时间不到一年。  
22.   
23. 2010年7月15日和11月8日，中国铁路建设投资公司受铁道部信息技术中心委托，对铁路客户服务中心信息系统一期工程和CDN服务进行招标。  
24.   
25. 此后卷入“宕机”漩涡的太极股份和网宿科技正是在这两次招标中中标的。按照太极股份2010年年度财报中披露的信息，太极股份与铁道部信息技术中心的合同额达 4895万元，占其当年全部营业收入的2.49%。网宿科技则并无披露相应的合作金额。  
26.   
27. 盛光祖上任后，铁道部信息技术中心又对铁路客户服务中心信息系统二期工程进行招标。  
28.   
29. 两次招标的总金额铁道部不曾披露过，“窄口统计，投在12306网站的资金约在1亿多。”铁道部高层向记者解释道，所谓窄口统计，是指新增资金部分，网络售票系统实际上也运用到了铁道部历年在客票发售与预订系统的资源，如加上那部分投资，则极难计算。  
30.   
31. 2011年6月，12306网站正式上线运行。铁道部分三步逐步将G打头的高铁列车车票、C打头的动车车票以及Z、T、K打头的直达、特快与快车等车次分批次地上网售票。完全实现所有车次都可网购的，事实上直到春节前夕才实现。  

----

回复网友留言：

回复1楼 falconfei 

    falconfei 您好，手写感谢您的留言。我说一下我的观点

    网站只是一种订票的渠道，因此我猜可能是调用接口，不会直接操作数据库，如果这样订票的核心逻辑应该是早以前就有的，因为还有柜台和电话系统在使用，因此逻辑应该不会改。

    任何系统都有一定的负载值的,一般来讲再厉害的票务数据库也无法承受如此夸张的访问，越是订不到越是点击，越是点击宕的更快。这个恶性循环会一直下去。
所以要只允许所能承受的一部分进来操作，一批完以后再进行下一批。就如火车站春运拿到车票的2小时内发车的先进站。走完一批，下一批再进站。如果不控制，再大的火车站候车厅也难以承受。
取号机制就可以过滤掉一批没有必要的人。取到号的就等着订票，没有号的干脆就不要让他进去点了。只让他随时关注有无余票可取号就OK，读操作肯定强过些操作。而且是没有目的的盲目的写操作。

这个是我的观点

回复5楼 ycc5617

               ycc5617您好，非常高兴看到您的留言。

         对于您提出的疑问，我认为可以在发出通知用户付费的邮件后，规定用户需要在一定时间内（例如5分钟）登录系统支付，如未在规定时间内登录系统，可以认为用户自动放弃，可以回收订单。用户登录后，订单时间调整为固定的时间如2小时，因为电话订票不止2个小时，因此认为2个小时也是恰当的，或者可以1个小时。因为真正有效的用户操作，因此系统更稳定，用户只要操作1次或几次就可以付款。付款收到返回信息后订票成功，否则超过1或2小时，自动解锁释放车票。在队列中可以不记时间，这就意味着锁的时间可能会更长，这个要看支付的吞吐量和速度，然后设定队列的大小和优先级。队列满了，可以让用户排队。

其实一个操作熟练的网友可以在10分钟之内就完成支付，如果是对网络部署的用户1个小时应该也足够了（前提是系统可用性要高）。

         欢迎继续讨论，多谢

回复6楼 ihxwangcong

        ihxwangcong您好，您的留言我已自信看过。您说的架构和事务并发确实是根本性问题，但问题在于解决这个问题不是在个别系统上就能解决的。铁道部的系统也类似于企业系统，是由很多系统构成的。保守估计核心类系统不止一个。从根本上解决这个问题确实是最好的办法。但也是一个耗时耗力的过程。去年我公司进行银行系统的整体改造升级，大大小小的系统几百个。经过几百IT精英差不多一年不休的努力才能够勉强上线。只是备用方案的指定和预演就经过了很长的时间。因此涉及到核心的东西不是不能改，是要谨慎改。在铁道部那边我是这样认为的。暂时宁可舍弃网站这部分，不会丢掉在他们看来比较稳定的核心。除非是遇到很大的问题，无法支撑下去，否则轻易不会动的。

回复8楼 jingyexiaoyue

      DDos是关于网络安全方面的问题了。这方面有不少硬件防火墙可以根据一定的规则过滤掉或屏蔽掉不满足三次握手的网络包。
      对于这种情况属于基础架构的层次了。这个铁老大凭借强大的经济实力如果有个懂的专家应该可以做的不错。实际情况来看也确实还可以。

      现在网络上的讨论我看过很多，很大一部分是从应用的设计上去讨论的。而且有个大的也是比较热的论点就是事务上。这个我也比较赞同。但是这个问题就脱离了电子商务网站的范围，我一直不认为网站会直接操作铁老大的核心数据库。因为网站没有经过大规模的试运行，无法知道会给核心造成何种影响，因此我一直认为是网站调用了核心系统的接口这种设计。而且核心的逻辑是原本存在的，已经供至少两个售票渠道在使用

     1.柜台（包括车站窗口和代售点）

     2.电话订票

这样的话，就是在原本的系统上要扩展出一个渠道子系统来。

我曾经也遇到过类似的情况。公司外购了一个系统，但是这个系统不够能满足公司的实际需要，仅此做二次开发。如果运气不好，找到的是第三方代理商。这个就很痛苦，因为代理商并不是真正的系统开发商。他只具有一定的开发能力，但涉及到系统底层的核心逻辑他就吃不透。如果动了，问题随之就来了，各种莫名其妙的错误甚至宕机。

     这次我认为也类似上面这种情况。核心逻辑因各种原因没有进行重构，因为向这样的逻辑重构也是有巨大风险的。因此我判断是为了规避风险而用了不是很适合的原有的售票逻辑。

感谢13楼 ywjq的留言

        您的留言我已仔细看过。对一点保留意见无卡无密支付，这点估计做不到。因为银行做的系统有银监会监管。这点上银监会肯定是不会同意的。除非是一种，就是银行缴费。事先和铁道部签订好协议。在有正是协议的前提下应该可以做到自动扣款，不过这个应该也要银行核实，估计要比网银接口到账要慢。具体内部银行的内部机制不是很清楚，不过有一点要受银监会监督收银监会制约是肯定的。

       欢迎ywjq再次留言讨论。多谢

一些题外话：

        我所描述的方案只是从一定程度上缓解系统的压力的方案，并不是提高系统性能的方案。

 当然，我没有参与过铁道部系统的设计和开发，以上所述都是本人凭借6年开发设计的经验的一些推断。网友所说之上谈兵也是对的。因为不清楚铁道部系统里的道道，因此所有谈这个问题，有没有接触过的人都是纸上谈兵。

       我的原意不在于是否之上谈兵，而是通过这个事件看能得到些什么启发，能想到些什么，然后在从大家的集思广益中能概括出有用的东西，并应用到今后的工作和生活中。

       再次感谢每位留言的网友！