在互联网从业者看来，12306购票网站问题的根源在于铁道部自成一体的积习与互联网开放透明的时代潮流之间的不兼容。尽管与“铁老大”之间难有对接沟通渠道，“程序员”们还是自发成立了旨在优化和开发12306的开源项目。我们从项目中邀请数位专业人士，测评12306网站，并对“铁老大”的互联网表现做出分析和建议。
像修铁路一样建网站
洪水般凶猛的春运势能推动下，作为“铁路官方唯一购买火车票的网站”，12306确实承受了相当大的压力——数据机构Hitwise披露，2013年1月19日，12306页面浏览量（PV）达到1.2亿，平均每个用户浏览14个页面，这意味着12306当日独立访客（UV）接近千万，这样的数据已经超过京东、去哪儿等网站。
在2012年的春运期间，全国数千万用户遇到了服务器宕机、支付故障、排队时间冗长等一系列问题。有70%用户反映无法在30分钟内正常登录网站，剩余的30%人中分别在查询-选定-下单-支付这四步过程中随机遇到服务器拒绝访问、网站停止响应、当前用户数过多的情况。
“问题的实质是传统思维的铁老大在进入互联网的过程中准备不足。”某知名电商公司技术副总裁何然认为，12306遇到的首先是服务模式的挑战：互联网产品需要“小步快跑”式的微创新，首先快速推出业务占领市场空白，然后在最短时间内进行技术迭代，在此期间内以良好服务提升用户体验，降低流失，这是一个正常互联网公司所应遵循的发展轨迹。
而12306的建设与修建一条铁路的传统模式没有什么分别：承包方签订服务协议，完工后不再负责运营、维护及后续开发。这种模式本身就存在隐患，再加上春运期间的流量和访问数远远超过想象，直接导致服务器故障。何然做了一个对比，“12306访问峰值数据相当于淘宝的‘双十一’活动期间数据量。为了实现稳定的数据库结构，淘宝用了将近八年，而12306却只有短短几个月。”
缺乏中间层的设计硬伤
“程序开发中有一个堤坝理论：修建堤坝为了抵御大浪，一般会做几层，一层比一层高，这样可以分批次抵挡波浪。网站流量也是如此，层级越多，分流后压力就越小，网站也就越安全。12306在设计上，缺少中间层的缓冲，前端用户需求直接涌入最后端的数据库，造成了一系列的故障。”
何然进一步解释，如果按照大型商业网站的思路来设计12306，最底层的是车票池（集中式数据库），对接传统铁路系统票务TRS（铁路客票系统）和TBS（高铁售票系统），“这部分是传统业务，有多年的积淀，做得不错”。
第二层是分布式数据库。从集中式数据库到分布式数据库，其实就是从一个大车票池分流到很多小车票池。比如华北地区一个池，珠三角一个池，把不同的需求分散出去。
第三层是交易网关，主要是处理订单信息及支付环节。并发式是这一层的主要特点，同时会有百万级别的用户进行在线交易。
第四层是安全层，起到防火墙的作用，用于过滤和清除黄牛刷票等恶意流量，及网络攻击防护，保障普通用户的正常访问。最上层是服务网关，基于这一层，可以搭建购票网站（12306）、安卓客户端、iOS客户端等，这一层也是直接对接用户的。
第二层到第四层在开发中一般叫作引擎，而如果引擎的部分设计失误或实现不完全，直接表现就是前端服务不稳定，容易发生出票故障、支付错误等问题。
“看起来之前12306的架构就是在第五层服务网关接受了用户购票的请求后，直接推到底层的数据库环节，缺少中间层引擎部分的缓冲和分流，这就使得集中式数据库在瞬时大流量请求面前崩溃了。”
原始的前端水平
在架构之外，12306还存在一系列问题，包括至今仍未更改的简陋界面。众多网站的前端工程师在分析后均表示，这样的前端水平实在过于原始，技术还停留在三四年前。
一系列12306的漏洞接二连三地被发现。比如有“技术宅”通过修改12306提交页面的代码，成功定到卧铺下铺（正常出票为随机铺位）；还有人写出了提前20天以上购票的脚本；最终则出现了“购票助手”、“浏览器购票插件”这类工具。
“打开主页要建60多个HTTP连接，现在的浏览器都是并发请求的，100万用户就是6000多万个请求，太多了；首页图片共计700k左右，如果100万用户首次同时访问，并在120秒之内返回，就要下载47Gbps的数据。如果网站能减肥，节约带宽后访问速度会大幅提升。”程序员“银魂最高”建议。
软件工程师赵会军认为：“即使这个并发量做到足够大，结果只能是所有票瞬间卖完，然后系统全天剩余时间无所事事。所以，首先要解决的是把购票时间规则改变，进行分散，然后才轮到解决并发量的问题。”
丁香园CTO冯大辉则建议使用通用的数字证书。“12306的数字证书是自己签发的而非通用的，需要浏览器和其他应用来兼容，在某些浏览器上甚至根本无法使用，这显然影响用户体验。”
这些建议部分已经被实现。比如今年的放票规则就已经修改为8至18时，除14时外每小时均有部分新票发售。自2013年1月7日开始（提前20天）发售春运客票至今，整个12306只有两次时间不长的技术故障。结合数据库的一系列改进，2013年绝大多数人的反馈不再是“登不上”，而是“买不到票”。
有限的网络票源
买不到票当然并不只是因为客票有限的原因。在这个显而易见的问题背后，隐藏着的是新老系统的对接问题。
12306并非一套独立的购票系统。铁道部原先用的是一套人工售票系统，12306是建立在这个系统之上的互联网通用自助购票平台，两者共享同一个票池。这就引出一个最现实的问题，一列火车的所有客票，究竟有多少应该通过互联网发售？
比如今年春运在“购票助手”出现后在互联网上曾引发热议：既然网络客票提前20天发售而售票窗只提前18天，拥有“购票助手”对排队买票的农民工是否公平？
通过了解整套购票系统，答案已经很明显。但我们有理由相信在去年的春运时期，铁道部由于首次设计客票方案，在两者的比例上缺乏经验，导致12306可买的票数实际上并没有想象的那么多。
“从今年整体情况来看，12306及电话订票的总出票数占到客票总量的30%至40%。这个比例比去年高一些，但我们不能因此认为这已经是最优方案。网络渠道出票比例多大最合适，还要慢慢摸索”，一位铁路系统的内部人士表示。
可以想见在今后很长一段时间内，这种网络+人工售票双轨并行的销售方式不会改变，而这也就注定了无论你是使用360浏览器、购票助手软件或是每天坚持自行点击鼠标，你争取的都只是本就为数不多的车票中比较小的那一部分。
至少在互联网上做到开放和透明
虽然并不明白个中原理，但得知整个12306项目的中标金额合计在3亿人民币以上时，公众还是发出了愤怒的声音：3亿就换来这么个玩意？
曾负责过大型资讯门户和电商网站技术架构的何然坦言：“12306技术上的难度很大。3亿的数字肯定含有水分，但差距并不像一般人所想象的那么大。”
例如把12306与淘宝对比：虽然“双十一”活动期间淘宝总交易数1.06亿笔，但淘宝商品实际上是静态的，只需要做购买队列，当排队者超过商品数时即关闭购买，其间并不需要查询数据库。而12306的所有查询都必须实时，尤其是同一条线路上当起点站的票状态被确定时，沿途各站的车票状态都会随之变化，因此即使试图做分布式数据，整条线路上所有支站状态表加在一起也是一个相当大的数字。
“通过测算可以看出来，去年可用性太差了，今年技术和业务都有优化。”丁香园CTO冯大辉透露，2012年5月铁道部邀请阿里巴巴等多家互联网公司技术骨干，作为顾问向12306项目提建议，其中部分已被采纳。
尽管能得到专业人士的理解，也有不小进步，但12306仍然被千夫所指。可以说，铁道部建设网站的传统方式即埋下隐患；在应对业界讨论和公众舆论方面仍然缺乏开放的姿态，则放大了问题。
例如2012年9月，何然看到很多程序员无法在12306订购火车票，即牵头成立了12306ng.org社区。该项目所有开发过程、开放文档、源代码都是开放的，所有互联网公司都可免费调用（包括12306）。何然的想法是，12306开源项目能够部分替代12306在线订票或分发、处理数据，并且能与12306无缝切换。目前这一社区已经聚集了1万多名开发者，也做出了一些相关的产品如浏览器抢票插件、手机客户端等。
但何然表示前景并不乐观：“离想象中还很远，和铁道部的沟通基本没有；他们也没有开放接口，我们走得很艰难。”
2012年，曾有网友提出铁道部应当对12306进行公开招标，亦有人戏言应当让淘宝接管这部分业务。而以铁道部自成一体的特殊状况来看，这些提议都缺乏可行性。但铁道部若希望减少批评，降低舆论压力，则应当公布网站建设资金去向，并在维护和后续开发上呈现互联网时代所应有的开放姿态。至少在以开放和透明为时代潮流的互联网上，“铁老大”的前现代思维应该改一改了。
