【IT168 评论】2012年春节，铁道部推出12306网站，进行网络实名购票。每一个返乡人原以为不用再忍冻排队，就能买着一张回家的火车票，但结果还是大失所望。7天内，12306网站访问用户已占全球互联网用户的0.902%，每天点击量高达10亿人次;系统一度支撑不住如此庞大的访问量而陷入崩溃。针对12306的责难也不绝于耳。
面对12306，人们发表种种猜想，究竟是哪里有问题引起了大家的兴趣，IT168也特意邀请了网站架构方面的专家-ITpub资深版主丁昊和腾讯架构平台部刘天斯，跟我们一起聊聊12306背后的故事。
12306订票网站存在哪些需求特点和挑战?
刘天斯：12306订票网站具有分时段、分区域、高并发等特点，如何确保在高峰时段正常提供服务是一个非常大的挑战，放眼春运期间网上订票系统，表现为页面访问延时大、登录异常、支付失败等问题。这其中存在一定客观因素，也不排除对流量预估不准确、架构设计不合理等情况。
同样类似的电商性质，12306和淘宝、京东等一样吗?
丁昊：其实这三者间基本没有什么可比性，12306购票系统更像是秒杀性质，但是要比淘宝、京东上的秒杀活动更强大，所需的处理能力也要比秒杀更多。
面对同样经历过宕机事件的淘宝和京东，性质和12306网站崩溃一样吗?
丁昊：TMall宕机更多的是准备不够充分，另外还可能是超出预计;京东的宕机则主要是自己的业务逻辑造成的;而12306则是两者的合集。
面对如此不堪一击的12306，有何改进意见?
刘天斯：个人认为更有价值是体现在数据分析上，如得到宽带数据、用户流量、区域分布、请求特点、应用瓶颈点、服务器的性能指标等等，这些数据对优化、改良现有架构非常有帮助。抛开宽带因素，以下是对12306平台系统架构的几点建议：
一、前端优化
具体参考：yahoo前端优化34条规则，针对12306平台，个人建议在没有多运营商链路接入(如BGP)的情况下继续使用CDN进行加速。动、静态应用分离，静态业务使用非12306.cn域名可以减少无用cookie带来的流量。任何一个小细节在高并发下都会被无限放大(截止目前发现平台还是以dynamic.12306.cn域名做静态引用)。查询页面的结果是通过Ajax异步返回填充iframe框架来实现，这对动态CDN加速是一个挑战，因为CDN节点并没有真正缓存页面中主要加速的内容。另外提高验证码的复杂度及多样性，可以缓解刷票机给平台带来的压力。
二、运用缓存
缓存最大的好处是减少后端数据存储的I/O压力，从一个普通用户订票轨迹来看，查询读往往是入库写的好几倍，如何减少数据库的读I/O对提高平台的整体性能至关重要，比较流行的缓存技术有针对页面级和数据级，页面级缓存有varnish、squid等，如使用CDN，页面级的缓存可以不用考虑，重点将精力放在数据级的缓存规划上，技术方面可以用Nosql来实现，比较成熟的Nosql有memcached、redis、mongodb等。可以根据班次、出发与目的地ID组合或出发日期进行hash分区，这样可以很好地提高缓存命中率，减少后端数据库的压力。
三、代理层
引入代理层的目的是拆分业务，目前平台绝大部分功能都共用一组WEB服务器(从域名及URI结构猜测，不一定准确)来对外提供服务，比如登录、注册、车票查询、余票查询、列车时刻表查询、正晚点查询、订单管理等等，只要其中一个功能模块出现堵塞，影响必定是全局性的。一个好的方法是优化、规范各业务URI，在代理层实现业务的划分，可用的技术有Haproxy、Nginx等，如将/otsweb/regitNote/映射到注册组WEB服务器，/otsweb/AppQuery/映射到查询组WEB服务器，/otsweb/Pay/映射到支付组WEB服务器等等，如此一来，当查询业务出现延时堵塞时不会影响到用户支付。
四、数据库层
之前接触过一些政府行业的业务，数据库服务器往往都使用一台高端的硬件，比如小型机，在互联网行业，尤其是类似于12306订票系统，这往往是最致命的，理由很简单，在大流量并发下处理能力再强的服务器也吐不出数据，因为受网络I/O、磁盘I/O、业务逻辑等方面的限制，所以必须将数据打散，方案有进行读写分离、分区、分片。主从模式可以很好实现读写分离，大部分数据库都支持这点，除此之外还建议使用分区模式，分区策略可以根据业务特点进行，按地域进行分区是一个好主意，因为每个区域都是一个大分区，还可以从业务层面对它做二级甚至三级的"扩展分区"。需要在细化拆分与运营成本上做好平衡。另外I/O密集的点尽量使用SSD代替。
五、负载均衡层
保障一个业务平台的高可用性，采用负载均衡策略必不可少，即使是提供给CDN的源服务器。目前有商用的F5、NetScaler、Radware等，也有开源的LVS，看成本的投入来选择，此处不详细展开讨论。
六、业务层
此次12306网站瘫痪事件，业务层面有无优化的空间?12306网站平台是铁道集团在互联网上对外服务的窗口，与电话订票、代售点都是平级的，后端肯定还关联着很多复杂的业务系统，在没有对整个集团业务系统做扩容的前提下(短期内估计不能实现)，可以将网站业务平台剥离出来，当然，完全剥离也不太实际，至少可以延长同步、一致性校验的时间。时间的长短随班次的发车时间成正比，因为大部分的用户都是提前一周以上就着手预定车票。
一个大型的高并发高性能网站架构需要从哪些层面去考虑呢?
丁昊：缓存、队列、锁机制、数据库分表、代码、灵活性、扩展性等等都是要考虑的因素，而且各因素之间相互联系、缺一不可。
关于使用开源技术建设高并发网站，有什么样的看法?
丁昊：拥抱开源，就等于拥抱了变化，这样才能更好的发展。开源软件可以读源码，可以修改源码，也可以增加功能，而且这些还是免费的。如果facebook，google这类网站都用收费的，估计也活不到今天了。对于构建大型高并发网站，主要的是看产品的设计，采用哪种开源软件其次，要能hold住使用的开源软件。
云计算目前大热，使用云计算平台来搭建高并发网站可行吗?
丁昊：可行，在业务不繁忙的时候甚至可以关掉一些服务器。但是，不足之处也有，目前国内并没有什么成熟的云平台能提供高可靠性，高性能的解决方案。
针对数据库的问题，有人建议采用NoSQL技术解决，但也有人质疑NoSQL技术不成熟，并且在实现数据一致性方面存在问题，您怎么看?
丁昊：NoSQL的技术其实是很成熟的，只是它刚刚被认知起来，另外大多的NoSQL都倾向于内存操作，所以可靠性降低了，以此来换取高性能。对于数据一致性问题，主要还是看业务的需求，是要求实时一致性还是最终一致性。互联网大多数产品都是最终一致性，对于交易系统大多数都是实时一致性，也不排除最终一致性(例如跨行转账)。
虚拟化如何在大型高并发网站中应用?
丁昊：虚拟化技术主要目的之一就是降低IT成本，但是随之而来性能也会降低。不过如果用作Web server，缓存服务器之类的倒是可以考虑。