海子铁路网

 找回密码
 注册进站

QQ登录

只需一步,快速开始

查看: 6663|回复: 28

在海子潜水N年,从一个IT人士的角度 分析下12306

[复制链接]
发表于 2012-9-21 09:58:12 | 显示全部楼层 |阅读模式
12306吐槽的太多,海子也一样。无外乎就是用户多,排队,买不上票,退不了票而已。从一个IT从业了9年数据中心建设人的角度我也说说12306。

12306网站的失败是无疑的。我从我自己的角度分析分析
第一:非要下载根证书才允许订票,用CA证书系统的确是国外的先进技术,就好比银行U盾,银行的U盾也是在USBKEY里面加入个人证书,来和服务器验证保证用户的真实性和唯一性。但是这里有个问题,使用证书我觉得要有个人证书和个人私钥。如果没有这种认证体系,你弄个证书干个鸟?如果用证书,必然用SSL加密来传输。网站头必然是HTTPS:// 我从订票开始至结束也没发现浏览器启用https的某个过程。而且如果启用的SSL 必然造成服务器的解SSL,压SSL造成CPU负载增大。启用证书,但没见SSL 不知道12306你们是怎么想的。我想用用广大群集最普遍的短信,要比你弄个证书来验证好的多吧,至少你吧一部分压力转给运营商了。

第二:现在整个售票系统已经联网,实现全国统一了。那必然TDB的数据库是大集中的。有点类似于银行,银行能实现通存通兑,也是基于数据库大集中。那整个系统的核心就是数据库操作,必然读写数据库请求增加。我想TDB不至于SB到自己开发一个数据库,而不用成熟的数据库系统,例如oracle DB2 INFOMINX等等。现在这种硬件性能过剩的年代,我倒觉得硬件性能早就不是什么瓶颈。而现在的12306出现的状况一定是系统结构的问题。目前主流数据库全部支持群集技术,例如ORACLE的 RAC等等,对于大型数据库一定要用负载均衡设备。专用的负载均衡设备均衡带宽现在都可以做到40G或者更多。用多台再做群集,负载个1000万人的请求绝对表示无压力。淘宝在高峰期登陆之后对于后台数据库的读写,每一个用户的session对数据库压力,绝对比12306大的多。我真不知道12306是怎么设计的。
而网络链路绝对不是12306的瓶颈所在。现在的网络太成熟了。TDB能调动的网络资源,也绝对能满足他们的需要。

第三:对于设计院的设计我只能说。无语。毫无设计理念,跟国内设计院一个水平。之所以中国现在到处高楼大厦长的都一样,就是中国缺乏设计人才,设计理念和设计环境。当然最主要的是设计环境,大大小小的建筑设计院,电信设计院图纸我也见过太多太多,叫设计院重新搞套图纸,有些不负责任的人,连名字都不改就发过来,照着图纸建楼,不到三层就得塌了。叫他们完全掌握一个系统的从头到尾,难。而设计人员以一句:“只有错误的设计,没有错误的施工。”把本该是设计人员该承担的社会责任推的一干二净。鸟巢设计之所以请外国人设计,政府也不傻。IT行业和别的行业不一样,真正的先进技术和先进手段,完全掌握在核心厂商的手里。真正的高精尖设计人员,是大厂的研发人员。这些产品只有经历了商业的考验才能使厂商获得利润。

相信也有不少厂商给12306提过整体解决方案,不过都被PASS了。自己搞不是不可以,但最好站在巨人的肩膀上。对于大家的吐槽,我只能说对于目前虽然,12306几个亿几个亿的往里面砸。不博采众长改变一下管理者的思路。今年的春运大家依然会在网上排队。没啥悬念。

发表于 2012-9-21 10:00:14 | 显示全部楼层
本帖最后由 沈局辽段 于 2012-9-21 10:01 编辑

介绍得专业性太强,还得慢慢消化。
发表于 2012-9-21 12:32:45 | 显示全部楼层
介绍得专业性非常强,必须得慢慢消化。
发表于 2012-9-21 12:42:00 | 显示全部楼层
介绍得专业性特别强,一定得慢慢消化。
发表于 2012-9-21 12:50:53 | 显示全部楼层
介绍得专业性特别强,不得不慢慢消化。
发表于 2012-9-21 13:02:33 | 显示全部楼层
介绍得专业性特别强,看了也没有慢慢消化。
发表于 2012-9-21 13:13:43 来自手机 | 显示全部楼层
介绍得专业性特别强,不得不慢慢消化。

来自: 海子铁路网社区 iPhone客户端
来自: iPhone客户端
发表于 2012-9-21 13:37:21 | 显示全部楼层

介绍得专业性特别强,不得不慢慢消化。
发表于 2012-9-21 13:41:30 | 显示全部楼层
本帖最后由 Q神 于 2012-9-21 13:49 编辑

作为一个不了解TRS的IT人 分析的够多了
但是有很多东西分析不太对 主要出在对TRS系统的不了解

12306网站不是一个单独存在的东西 他依托于后面的TRS存在 类似于TRS的一个界面形式

更多的问题在后面

凭着我对TRS源代码的研究,从网站系统看,今年8月份以前的系统是几乎完美的。本身12306部分负载很低,otsweb服务器池只开放一半不到就可完美应对去年春运的巨大压力,前台JAVASCRIPT、HTML代码写得也非常非常漂亮,所有的问题都出在后台对接那里的效率


而现在的12306网站是有巨大问题的。之前微博有个什么萝卜的爆了一张选座系统的截图,从那个图我直接预估了代码怎么实现的,联想到TRS架构,当时就预言了这系统上线整个12306必将崩溃,因为结合那个库结构架构,归集座位信息的数据库开销要达到以前系统开销的100倍以上!

后来 TRS应对12306的需求进行了一次升级,没错,升级TRS后台来应对12306的功能需求,结果就是这次变态的升级导致全国各站第二天取不出网上订票,杭州站据说爆发了很多旅客和承运人的言语冲突,这次升级以后,原来每次12306取票操作的开销由1~3秒直接跳跃到9~12秒(神器有详细dump数据),之后杯具了以后,选座系统说是15号上线,某“了解内情的南京大师”对我的崩溃判断不屑一顾,什么内部测试完美了之类,结果维护TRS第二天崩溃……之后到现在没开放

后来 出了个坑爹的队列系统。这个队列系统吧,也不能说他不好,如果只有网上一个渠道,那么这玩意算是一个比较完美的解决方案,但是他们不知道有电话订票并发么?电话订票的处理时间跟以前老的网络取票差不多 1~3秒有结果,网上这个时候队列基本不走路

另外 现在队列的取票开销也很杯具,不是“升级”前的1~3秒
最近两天12306都是0点关闭,在关闭前每天我做实验测试开销

选取无队列订票的拉萨中心取站票、北京中心、沈阳中心三个中心队列对比测试。
前方排队人数是0 时候给出的预估开销时间是5~10秒,这本身就是一个巨大的落后性能,落后于春运的实时系统三倍不止





之前在模拟售票系统的群,我曾对内小范围公开了TRS客户端的源代码,SYBASE+PB的开发结构,架构是3.0时代一点点改来改去从未重新架构,设计思想也是开销巨大的局域网实时+缓存模式,核心还是是那时候售票系统还叫smart的时候的东西

整个系统要正常工作维持的数据库连接数就很变态
sqlca sqlcb sqlcc sqlcd sqlxx sqlxa sqlxb sqla sqlb sqlc神马的 一大堆
都是各种补来补去的结果
QQ截图20120921133834.jpg

借用当时的研究,大家都很怀疑当时3.0的售票程序是不是铁科院研究生的毕业设计

附上一些经典的代码段给大家参观参观
QQ截图20120921134145.jpg

发表于 2012-9-21 13:50:15 | 显示全部楼层
介绍得专业性挺强,确实得慢慢消化。

但是我想加一句,12306 确实用到了 HTTPS。实际的订票过程全都是在 https://dynamic.12306.cn/ 中进行的。
发表于 2012-9-21 13:50:34 | 显示全部楼层
在上点代码片段
QQ截图20120921134323.jpg
发表于 2012-9-21 13:55:46 | 显示全部楼层
Q神 发表于 2012-9-21 13:50
在上点代码片段

QQ截图20120921134837.jpg
发表于 2012-9-21 14:01:14 | 显示全部楼层
介绍得专业性特别强,看不懂也得慢慢消化!
 楼主| 发表于 2012-9-21 14:22:35 来自手机 | 显示全部楼层
拖沓的设计,啥也不说了
发表于 2012-9-21 17:10:28 来自手机 | 显示全部楼层
SSL还是有必要的,作为这种国家级别的涉及金钱的网站,为了安全是可以牺牲用户体验的
发表于 2012-9-21 17:19:40 | 显示全部楼层
这个帖子技术含量量挺大啊!12306应该还是会整改,现在民怨比春节时候大~
发表于 2012-9-21 17:20:44 | 显示全部楼层
呵呵,竟然是PB做的
发表于 2012-9-21 17:32:11 | 显示全部楼层
各位师傅,各路师傅:我农民了。。。
发表于 2012-9-21 17:33:17 | 显示全部楼层
假设马云呢?
发表于 2012-9-21 19:04:19 | 显示全部楼层
耐心学习了两遍  没有学明白  还得再学
您需要登录后才可以回帖 登录 | 注册进站

本版积分规则

手机版|小黑屋|Archiver|海子铁路网 ( 京ICP证120035号 京公网安备11010702001036 )

GMT+8, 2024-11-16 09:46

Powered by Discuz! X3.4

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表