在海子潜水N年，从一个IT人士的角度 分析下12306
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:01 编辑
介绍得专业性太强，还得慢慢消化。
介绍得专业性非常强，必须得慢慢消化。
介绍得专业性特别强，一定得慢慢消化。
介绍得专业性特别强，不得不慢慢消化。
介绍得专业性特别强，看了也没有慢慢消化。
介绍得专业性特别强，不得不慢慢消化。
来自: 海子铁路网社区 iPhone客户端
介绍得专业性特别强，不得不慢慢消化。 本帖最后由 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神马的 一大堆
都是各种补来补去的结果
借用当时的研究，大家都很怀疑当时3.0的售票程序是不是铁科院研究生的毕业设计
附上一些经典的代码段给大家参观参观
介绍得专业性挺强，确实得慢慢消化。
但是我想加一句，12306 确实用到了 HTTPS。实际的订票过程全都是在 https://dynamic.12306.cn/ 中进行的。 在上点代码片段 Q神 发表于 2012-9-21 13:50 static/image/common/back.gif
在上点代码片段
介绍得专业性特别强，看不懂也得慢慢消化！ 拖沓的设计，啥也不说了 SSL还是有必要的，作为这种国家级别的涉及金钱的网站，为了安全是可以牺牲用户体验的 这个帖子技术含量量挺大啊！12306应该还是会整改，现在民怨比春节时候大~ 呵呵，竟然是PB做的 各位师傅，各路师傅：我农民了。。。 假设马云呢？ 耐心学习了两遍没有学明白还得再学{:4_104:}
页:
[1]
2