最牛电商

    昨天聊天,聊到最牛电商的问题,大家都笑了。
    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封装了一个壳子。这种就更麻烦。
    目前还不能确定铁道部订票网站到底是什么情况,不过可以确定的是,这个网站的状态在未来几天内还会继续恶化。搞不好到一定程度就直接没法用,或者被铁道部直接关闭网站一段时间了,需要订票的同学最好尽早想办法。

7 thoughts on “最牛电商

  1. 赵明亮-全国三胖仅剩一(@insocn) 同事去了铁道部网络中心诊断12306了,都快哭了,原话:”靠,我们这样活着太没价值了”….整套系统都是有很大问题—–原来做政府采购项目这么好赚钱.一个上百万的内外网双网隔离,就是一个机器上装俩nginx—-这玩意上有30000多并发,经过这个设备后之后几千,所以…你总登录不了~

  2. 昨天那45分钟真是惊心动魄,比打使命召唤还紧张。
    原本还以为订火车票这种烂事我这辈子都不用摊上,结果前一天晚上大学好兄弟打电话来要求帮忙订票。人家第一次跟老婆回去见岳父岳母,一定要在年初一前到,这事当然义不容辞地给接了!
    当晚就预习了下网上的教程,第二天一早就实名注册了,然后把兄弟跟他老婆的身份证信息加入联系人,方便订票时直接打勾选上。每天是下午三点钟才开始开放新一天的火车票,根据我的印象,那天是15:05分开放新票的。我是下午二点就开始同时开了IE,FF,Chrome,感觉IE刷新4次,Chrome能刷新5次了,最后果然还是Chrome先连接进去了,当时大概14:20分左右吧,还要等40分钟才开始,怕长期没动作会被弹出,就每过2~3分钟切换过去作点查询。就这样到了15点05开放新票,大概刷了N次订票后,成功了,窃喜之!挺容易的!以前CS游戏没白打啊!只要在45分钟内付钱就行。
    接下来就是杯具,Chrome不能付款,而且直接被弹出了!这时再用IE 8从头登录排队是300,800,后来1300….三点到了,大家都来了!三十分钟后终于挤进去了,又被证书问题给弹出来了,而且发现IE 8有时左下脚显示网页有错误。根据Q群友建议,在虚拟机里开了个IE 6,这次倒还好,在最后五分钟进去了,接下来就是文中提到的网银500上限问题,先打电话给兄弟,接着又问自己身边的好友,十几个人中大概只有一个有招行的可以超过500,当然那是45分钟后N久的事情了,首选的K253列车已经全部没票了。
    好在兄弟他有多手准备,找我和他哥在网上订票,让她表姐打电话(表姐在电信工作),他自己在公司那20多人共享的2M网络上蛋定地刷…大概在4点半,终于电话打进了,订到了两张次选K751的硬卧,第二天12点前带上身份证前去附近的售票点交钱就行….
    在精神上我算是被春运了一次…
    据说这个12306花费1600万…

    shell 回复:

    @Frank_Xu, 首先,如果是真的很紧急的事情,别指望铁道部,订机票吧——无论多贵。而且下面的朋友,如果还指望订票,就更不要想铁道部的事情了。他们的网站只会越来越卡。
    其次,这个还是靠专业人士用脚本刷比较靠谱。不过别看我,写脚本需要用到页面,那个鬼页面我碰都不想碰。
    最后,莫说1600W的网站,就是600W,我都会建议直接买一张根证书——最不济也可以问CNNIC要么——尽管我不信任就是了。

发表评论

电子邮件地址不会被公开。 必填项已用 * 标注

*

您可以使用这些 HTML 标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>