Shell's Home

Jan 11, 2012 - 1 minute read - Comments

最牛电商

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

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.cn12306.cn两个域名,上面用squid做了缓存。后面是一堆应用服务器。其中有一些Coyote服务器的响应特别慢,大概在1-10s这个量级。而这些服务器当访问数据库的时候,就彻底变成访问无望了。按照网络上说法,铁道部用的是Oracle数据库,估计已经半瘫痪了。

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

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