专家支招：高并发交易型网站设计四原则

xgnic 实名认证

　【IT168 评论】2012年春节，铁道部推出12306网站，进行网络实名购票。每一个返乡人原以为能买着一张回家的火车票，但结果还是大失所望。7天内，12306网站访问用户已占全球互联网用户的0.902%，每天点击量高达10亿人次;系统一度支撑不住如此庞大的访问量而陷入崩溃。针对12306的责难也不绝于耳。　　对此，中国铁路客户服务中心透露，目前，铁道部已启动了新一代客票系统的规划和设计。考虑采用云计算架构，对现有的客票系统进行全面的优化和改造。IT168企业计算群组特启动“支招12306 大型高并发高性能网站架构经验大家谈”特别专题，针对大型高并发高性能网站架构广泛征集意见，为12306网站提出优化建议，并对更多有需要构建大型高并发高性能网站的用户提供参考。本期采访的嘉宾叶萌，曾任天涯社区CIO，现在从事云计算相关的创业工作。
　　在采访中，叶萌表示，虽然大家对12306网站有所指责，但是站在纯技术指标的角度，从公开的一些数据看，我个人觉得它做得还蛮不错，应该给铁道部一点鼓励。他认为，12306网站归根结底可以归结为在线交易型网站，并谈到了在线交易型网站在前端设计和后端设计方面的一些原则，在线交易型网站最大的难点就是要结合自己的业务特点，把这些设计原则融合到网站的设计中去。
　　问题一：12306网站需求分析 与其他网站有何不同?
　　叶萌：这种大型的服务网站，包括淘宝、京东等电商的网站，还有这类订票的网站，服务的可用性以及响应的时间是刚性的需求，但是不同的网站由于业务不同会导致需求有所不同，同时还有网站的访问压力也同网站的需求有关，压力包括用户的访问压力以及业务流程的复杂度和要处理的数据量的压力。
　　京东、新浪、淘宝、12306等等这些大型的网站，需求方面最主要的区别就在于并发的访问量、业务逻辑的不同、以及数据量的大小。
　　问题二： 12306网站系统的设计存在的问题分析？
　　叶萌：不管是京东也好，淘宝也好，还是12306也好，都可以归结为一种在线交易系统。这种系统大致地可以分前端和后端两大部分。后端再细分一点，可以分业务逻辑的部分和数据处理的部分。
　　前端的设计要在满足功能需求的前提之下做得比较轻，所谓轻就包括前端的格式和数据量，每下载一个页面所需要的数据量以及打开同一个页面上建立的http的连接数要尽可能地少。反之，如果网页比较重的话，每下载一个网页从服务器传出来的东西就会比较多，当访问量很大时，对系统的带宽会有极大的挑战。
　　12306前端设计比较重，主要表现几个方面：第一，把CSS的表和网页混在一块下载。第二，打开一个网页需要建立的http连接数都很多。很多关键的网页包括订票的网页、查询的网页，打开一个网页需要建立的http连接数都很多，有人分析过打开一个网页超过70个http连接数。每一台服务器建立的http连接数是有一个上限，如果大家都去并发访问的时候，服务器的连接数很快就不够用了。
　　在这里我想补充一点：多浏览器的兼容性问题。12306目前好象使只能使用IE浏览器，用google的Chrome的浏览就不能并发的用，所以这也是一个需要注意的问题。
　　后端可以分成两块：一个是业务逻辑，一个是数据处理。
　　从业务逻辑角度来讲，火车票的查询从A地到B地有多少趟车，这个查询的逻辑比电商的要复杂。电商无非是到一个库里看还有没有货，结果要么就是有要么就是没有，不会有第三种。但是对于火车票来讲，从A地到B地可能有多种选择，可能有几趟车可以选择。
　　这个比电商要复杂，因为它做的事要很多，计算就比较多，或者要做好几个查询，才能把信息汇总起来。如果涉及到关联订票的情况就更复杂了，但是目前12306还没有实现关联订票。
　　后端的还有一块——数据处理方面。这个跟订票有关系，订票以后需要做一个事务，就是要从下单到完成订票是一个完整的事务，这个事务和电商下单的时候有一定的相似性，直到付款这一步之前都跟电商就很像。这个部分的问题在哪里?12306采取的一个做法就是同步的响应，同步做法是大家比较喜欢的一种做法，就是下了单马上能看到买到票没有。但是同步的做法对系统的挑战比较高，有很多电商的网站实际已经从业务逻辑的调整为一个异步，就是把订票这个事务变成异步操作来完成。
　　事务的处理有一个最大的挑战是数据一致性的问题，就是一定要保证后端在任何一个时间点它是一致的，伸缩性不管是纵向扩展还是横向扩展，尤其是横向扩展比较难的地方就在于数据的一致性的问题。