昨天聊天，聊到最牛电商的问题，大家都笑了。

frank订票45分钟花了45分钟，还没搞定。先是从chrome换到IE，因为前面的部分chrome能用，付款不行。然后从工商付款，上限500，不行，必须一次付款800，而且不能用支付宝。问我借卡，我的也不行。最后借到卡了，结果过45分钟了，重排，没票了。

淘宝买东西要是需要超过5分钟，喵喵就会少买好多东西。

还有个朋友说，他的卡能支付5000，买票，扣款后没票。人家说钱能拿回来的——钱能回来可是票回不来阿。好，再买，又扣钱没票。再买——没钱了。

我去阿，这TMD不是坑爹么？

这种网站，转化率还是100%，广告成本0，绝对最牛电商阿——没有之一。

关于顶不住这个问题呢，大家都懂的。我自己也做过类似的事情——甲方设法让自己的厂家中标，也不管人家有没有能力做。厂家领导是先中标再说，不中标自己就完蛋了。下面的人没能力，要么是不知道自己没能力，要么是知道也不敢说。做着做着问题一堆，也不敢和甲方沟通。不沟通问题就越来越多，交货的时候一看，甲方吐血。然后厂家领导就和甲方领导搞协调，厂家要去修一些问题的，甲方延一点时间，最终还是会让这个系统上去的——否则领导也麻烦阿。

最后只要这个烂摊子不被揭出来，大家皆大欢喜。中国政府领域的IT，大多都是这个样子。

比较大的烂摊子揭出来的，一个是绿坝。没办法，太烂了，还要所有机器供应商都来做支持。索尼干脆发了个文，这是中国政府让我们装的，出了问题不要找索尼，谢谢。结果这样还被告上美国法庭了。最后领导实在顶不住压力，撤了。另一个就是这个，最牛电商，估计回头也会撤的。因为后面订票压力越来越大，搞事情的人也越来越多，烂摊子搞到后来领导也会怕的。

其实昨天gary说了一句比较实在的话，这个系统不应该做成这个样子的。一切说中国买票的人太多，瞬间交易压力大，刷不出票的人持续刷的，都是借口。知道压力大，搞分时销售和抽签制分散压力。前端做负载均衡和CDN负担压力，后端真到订票的时候转换成MQ去操作。大型机再怎么做的差，每秒1000个transactions是出的来的。一小时就能完成360W的交易，一天八小时，3000W的票就出来了。中国有多少人需要订票的？3亿？就算做瞬时压力，铁道部车票成交比纽约股市买卖还快，要求还高？技术做不到根本是扯淡，最多是钱的问题——现在还是花钱没解决问题。

为了见证奇葩，我特地上去看了一下，结果第一眼就晕倒了——铁道部需要你自行下载根证书。我去阿，堂堂铁道部，一个多少万的项目，连TM买一张证书的钱都没有？！

其他细节就不多写了，相信用过的人比我都清楚的多。需要多次点击才能买到一张票，访问过程长导致压力大。定时开票，时间集中导致压力大。需要注册，导致注册过程冗长，也是增加压力。这些都不是技术问题。

整个过程中耗时最长的（抱歉我懒得注册，只去看了余票查询），一个是http://dynamic.12306.cn/TrainQuery/leftTicketByStation.jsp。这个的服务器响应表明是来自Apache-Coyote/1.1，由squid/3.1.18缓存，未命中。另一个是http://dynamic.12306.cn/TrainQuery/passCodeAction.do?rand=rrand。这个的服务器响应表明来自Apache-Coyote/1.1，是一张image（验证码），同样未命中。基本squid命中的都在ms级别返回了，出问题的都是dynamic.12306.cn这个域名没有命中的页面。这个表明前端的缓存还行，压力都压到了后端。至于造成这个现象的原因是前端缓存策略错误，还是后端性能相对不足，就不知道了。

我注意到，至少有一个页面https://dynamic.12306.cn/otsweb/css/contact.css。Server字符串是asfep/2.3.0 svn:3075。asfep是什么我不知道，google了一下也没出来。不过svn？这文件是从svn服务器上出来的么？！如果是，这就有点奇葩的味道了。

然后我点了一下查询，这下大奇葩出现了。一个query居然执行了30s以上。在验证码故意输错的情况下，返回速度在10s这个量级，而输入正确就天长地久了。由此可见系统是分成多个部分的，最外面是dynamic.12306.cn和12306.cn两个域名，上面用squid做了缓存。后面是一堆应用服务器。其中有一些Coyote服务器的响应特别慢，大概在1-10s这个量级。而这些服务器当访问数据库的时候，就彻底变成访问无望了。按照网络上说法，铁道部用的是Oracle数据库，估计已经半瘫痪了。

说是Coyote，其实如果没什么意外，这个就是Tomcat。那么铁道部的架构底子基本也就出来了，是J2EE的架构。估计是一帮ERP工程师照猫画虎做出来的。J2EE不是不能用来做电子商务，有些网站还做的很成功。但是不做任何优化，直接就敢拿J2EE做ERP的架构去做大规模电商的，这就是找死了。尤其是某些ERP严重依赖于Oracle，业务逻辑根本就是用Oralce写的，用J2EE封装了一个壳子。这种就更麻烦。

目前还不能确定铁道部订票网站到底是什么情况，不过可以确定的是，这个网站的状态在未来几天内还会继续恶化。搞不好到一定程度就直接没法用，或者被铁道部直接关闭网站一段时间了，需要订票的同学最好尽早想办法。