主题：说说我对12306的看法 -- 未来的未来

先给大家拜一个晚年。

这篇东西是春节前写了大部分内容，然后由于回老家过年，一直没有完成，今天算是草草写完，怕再不提交上来，就没有机会了。

-------------------------------

现在12306网站是一个热点，我也凑一个热闹说说我的一些看法。

先看看目前我找到的一些信息吧。

“刚才打电话慰问了一下大学同学，他去年计算机博士毕业去了铁科院，12306.cn订票系统他没参与，但是现在一直在忙着想方案解决性能问题。

系 统主要问题是业务逻辑层并不是直接访问数据库，而是与现在的TRS系统(基于Sybase)和TBS系统(基于Oracle)通信，通过JNI访问C实现 的专用接口。这样并发支持很成问题，等于造成了一个瓶颈。现在解决的办法是查询时采用了缓存，所以造成了每次刷新不一定能够获得最新的票额。”

http://www.newsmth.net/bbstcon.php?board...3681&pno=1

”后台连TRS，跟售票窗口一回事“

http://www.newsmth.net/bbstcon.php?board...id=1174345

”12306是刘志军时代招标设计，原本只打算拿来卖高铁票，本来就没有设计为抗春运流量的。这个网站的架构抗日常流量没问题，抗春运必然崩溃。这就是某些领导瞎决策、硬上马的恶果。

trs能支撑的交易量有多少，具体数字我说不准。但是在窗口售票的情况下，热门车票必然都是秒杀，30秒钟卖光热门卧铺是不成问题的。更多的交易量进来，反正也是没有票额无法成交，所以就根本不需要支持那么大交易量。

如果说公平合理，那么应该按奥运门票模式抽签，这时候大家yy的架构还有用。如果现在这种在线售票，肯定不可能抛开TRS。“

http://www.newsmth.net/bbscon.php?bid=26&id=1173943

"这样又回到90年代卖纸票的老路了。车站打出一坨纸票，卖票直接出一张，卖不掉退回，多好？事实根本不是这样。不是每个人坐每趟车都要始发终到。trs不是一个票额管理系统，所有车票经过trs销售才真正做到系统高效率运转。

http://www.newsmth.net/bbscon.php?bid=26&id=1173938

以上是我看到的对于摸12306这头象比较有用的信息，从中大致可以看出售票系统的大概情况：

1.存在一个原有的售票系统TRS(有一部分通过TBS，但是不是主要的)，这个系统”不是一个票额管理系统，所有车票经过trs销售才真正做到系统高效率运转“。从其他零散的信息可以推断出，trs是整个铁路售票的核心系统，在其中实现了售票的业务逻辑。顺便说一句，这个业务逻辑的复杂程度很有可能超过普通的网上商城(我看过普通的网上商城，并不复杂)。单单是车票可以按站拆开卖就比较麻烦。

2.但是显然，从各种原因考虑，不可能直接将TRS推向用户面前让用户进行操作。于是做了一个前端系统12306用于互联网用户进行操作，12306再将用户的订票信息提交到TRS中完成实际订购过程并且返回订票信息。

3.TRS中自然会有关于票务的所有信息，但是在12306中，也有一套车票的信息，但是不是实时的。这个信息的作用是为了查询，并且“采用了缓存，所以造成了每次刷新不一定能够获得最新的票额。”

4. TRS并不完全为12306服务，还同时可以通过电话，车站，代理点进行购票。其他的这些购票方式是不是直接介入TRS还是通过某一个前端系统后接入不清楚，但是我倾向于是有通过前端系统接入的。

5.12306是通过JNI的方式调用TRS的C接口。同时也有消息说是TRS也有JAVA接口，但是没有通过JAVA集成。

6.现在看起来最大的瓶颈是在于12306和TRS的接口。并且可以看到为了解决这个瓶颈现在采用的办法是通过缓存的方式来减少，由此大胆推断在过去查询余票是也是直接连接到TRS来进行的。

综合起来说一下：

铁道部已经存在一个完善的售票系统TRS，这个系统支持了现有的车站购票，代理点购票系统，甚至还支持了电话购票系统。由于需要，需要提供互联网服务，于是很自然的架设了一个前端系统，这个系统就是12306。12306通过JNI的方式调用C接口来访问TRS系统。

这是一个并不新鲜的故事，换一个更普通的场景也许就好理解多了，某公司存在一个用了很久的销售系统，在大型企业，这个系统十有八九是SAP的SD模块，随着时间的发展，需要在网上直接向下游厂商进行网上直接下单，但是安全、授权用户数、易用性等原因显然不能够直接开放SAP的权限，于是就开发一个前端系统来支持这个需求。这个需求如此普遍，以至于SAP自己也开发了一个模块来企图支持这个需求。

铁道部的故事和SAP的故事所不同的是，一般情况下，这些企业往往只是面对少量的用户。

目前的瓶颈

我们先从第一个信息中提到的瓶颈开始"通过JNI访问C实现 的专用接口。这样并发支持很成问题，等于造成了一个瓶颈"。没错，问题就处在这儿，两个系统（也可能是两个以上，因为可能TRS系统不止分布于一个地方，前端的不仅有12306还有电话等）链接的地方出问题了，显然这种方式是有问题的。

可能形成瓶颈的原因

"通过JNI访问C实现 的专用接口"，这种方式显然是直接将两个系统耦合起来，这样做，基本上是相当于把后台的TRS直接暴露在成千上万的用户，从而失去了前端的缓冲，直接冲击业务系统，造成业务系统的发生阻塞、性能急剧下降，甚至可能导致业务系统完全宕机。此外这样一些其他问题，比如：

1.耦合度太高，容易造成一个系统出问题，其他系统也全面倒霉的局面。

2.还是由于耦合度太高，某一个系统如果其中一个接口出现变更，其他的系统就要跟着变更，并且很有可能你都不知道那些系统调用了这些接口。不妨想象一个场景，如果有十几甚至几十个应用，通过系统间直接调用的方式，那是一幅多乱的关系图啊。

3.其他各种缺点。

针对当前问题的改进

其实针对这种情况，业界早就提供了解决方案------在两个系统之间增加一个中间层EAI系统来负责，首先，隔离各个应用。其次，利用中间件的功能缓冲前端提交的压力。并且整合12306，TRS，甚至包括支付等系统的业务流程。

EAI是干什么的呢？简单的说，就是将不同的异构系统集成，从而实现企业的数据共享和流程的无缝连接。

简单的列出一个方案：

1. 12306作为一个前端系统，负责用户管理，查询等工作，在这个基础上。

2. 用户提交订单以后，将订单信息提交到EAI系统。EAI系统异步处理订单。

3. EAI系统将订单提交TRS，TRS处理后将结果返回EAI，EAI可以通过控制每条提交订单数，过期时间等参数控制对TRS的压力。

4. 用户收到订单成功信息以后，进行付款操作，在收到银联付款成功信息以后，将付款成功信息通过EAI提交TRS，完成整个订票过程。

5. TRS将余票信息定时或者实时通知EAI，EAI将余票信息分发到12306，电话购票系统以及其他系统以供查询。

• 我在河里写过一篇，和估计的差不多 。