我们用一组数字说明12306.cn的流量是多么的惊人。据网友统计，截至1月5日，互联网权威流量排名机构Alexa显示，元旦一周，12306网站的“一周平均排名”为339，日均IP为194万。而国内航空网络售票网站“travelsky.com”的“一周平均排名”为11340，日均IP为8万多。相比之下，火车票的需求为机票的25倍左右。
巨大的火车订票需求必然催生12306网站瘫痪的风险。有句话说得好，成长是要付出代价的。一位行业人士说，“12306网站只是在高铁、动车上进行尝试，之前并没有遇到春节这样巨大访问量的经验。不仅没有做过模拟，并且一上来就是全国性的访问，系统瘫痪在意料之中。”而我们对比电信、金融等并发访问量大的行业，不难发现，这些上新的大规模系统时，在压力测试之外都会进行区域试点。人们不禁要问，对于12306.cn，走路都不稳，你就让它跑，它准备好了吗?
而显然，揠苗助长的故事告诉我们12306网站系统瘫痪在意料之中。那么，从技术的层面，我们能把一把脉么？
我们下面从技术层面加以剖析。
首先，通过访问与分析12306网站，我们发现N多URL都以.do结尾，这是典型MVC架构Struts的风格。下图是http://dynamic.12306.cn/TrainQuery/passCodeAction.do对应页面。红色的struts说明这一点，这与网友分析的12306网站的前端基本架构是jQuery+Struts+CDN(即content distribution network)不谋而合。
其次，通过底部红色标记，我们可以清楚地看到这里采用的是JBoss应用服务器，版本为2.1.1。据官方资料，JBoss是一个开源的J2EE应用服务器。
综合来讲，前台的Struts框架配合JBoss均走的是开源路线。众所周知，开源的最大卖点是免费。这也解释了网友分析的铁道部之所以选择CDN提供商网宿科技。有媒体此前分析说，网宿科技自2010年起两项主营业务CDN和IDC(互联网数据中心)毛利率均迅速大幅下降。而网宿科技的解决之道则是开始走低价路线，“在没有技术优势的前提下，网宿科技打出了最擅长的低价牌，然而号称要做行内龙头企业的网宿科技，在高科技旗下的低价路线，面对着不断上涨的营业成本，似乎已经走上了一条不归路。”
第三，12306网站系统瘫痪是否与数据库有关，采用的是何种数据库，这个要打问号。有传闻采用的是划归SAP旗下的Sybase商用数据库，笔者并没有找到直接证据。但是无论采用何种数据库，网站的自身优化是一个绕不开的话题。据网友普遍反映12306网站反应速度慢。这个恐怕和前端的JS与CSS设计脱不了干系。据报道，系统将JS和CSS加载起来毫无意义，用户点击”预定按钮“，就会跳出了33个CSS格式请求，每个耗时5-6秒的，直接造成网络繁忙;网站全部采用旧时的iframe架构，每次点击时候都要全部加载页面，极大拖慢网速。
12306网站的瘫痪与系统反应速度毕竟是两回事。对于“付款成功却无法购票”的情况，12306官网表示，“这是由于网络等原因导致银行的支付结果数据没有及时回传至12306网站。”而接下来的一个问题是，为什么会导致网络问题?对于这些问题，铁道部官方进行了回应，称访问流量过大，导致出现了系列问题。目前已在进行改进，增加网络带宽，处理退费事宜。从技术的层面上说，12306网站出现无法访问、扣费异常等问题的原因，不在于带宽，而在于系统开发中的系统均衡处理未做好。
难怪有人将12306瘫痪追究为系统架构规划问题。
最后，安全性问题最近一直刺痛互联网的神经。最近CSDN的600万用户泄密，天涯网4000万用户泄密给所有互联网企业敲响了警钟。而不幸的是，中国铁路客户服务中心(12306)是以明文传递密码的，这也更加引发了网友对个人身份以及银行卡信息泄漏的担忧。
无论怎么样，利用网络购票，解决“一票难求”是一项民生工程，值得赞扬。但是12306网站瘫痪只是一个表现问题。核心问题是利益分配问题。铁道部的有限预算决定了网站提供商的资质，也就决定了系统瘫痪是在意料之中的事情。而如果过大投入，势必会造成30天春运之外的巨大浪费。如何拿捏分寸，做好项目的前期评估，中期测试，以及后期模拟是领导层应该重视的问题。
