问诊12306之四：产品设计团队缺乏经验

        【搜狐 IT 消息】9月 28 日消息，在多位信息化专家和技术专家问诊 12306 之后，大家最后都指向了同一个问题，12306产品不给力，与产品设计和运营管理团队的经验不足有一定关系。以下的 2 个实例或在一定程度上印证了专家们的判断。

搜狐 IT 独家解剖 12306 网站结构图

        根据铁道部在 2012 年初对外公布的信息看，12306客票系统于 1996 年 6 月被列为“九五”国家科技攻关计划，1998年又列为“九五”国家科技攻关计划重中之重项目。是在铁道部的领导下，由中国铁道科学研究院牵头组织，由全国 数十家高校和科研机构的上百名科研工作者联合攻关，采用核心技术自主研发、通用软硬平台开放的技术路线，历时两年研发成功。

        在 10 余年的成功运营过程中，先后完成 6 次版本升级。其中，1.0版本实现了计算机售票取代人工硬板票，2.0版本实现了区域级联网，3.0版本实现了全国联网售票，4.0版本实现了与清分清算 系统的对接，5.0版本实现了席位复用和共用，5.2版本了实现实名制售票、电子客票和电子支付。目前正在使用的，增加了“强制排队”功能的版本应该是 5.2版之后的最新一版。

        在实际操作过程中，开发和生产环境即软硬件平台采用外包方式，目前公开招标的也是这一部分，而产品设计和软件开发则是由中国铁道科学研究院电子所（以下简称铁科研）团队负责。

        某国内知名互联网公司的技术负责人李先生向搜狐 IT 透露，2012年 3 月，他面试了来求职的铁科研 12306 产品开发团队的一位成员，该成员长期负责 12306 的架构设计。他向李先生详细介绍了 12306 的架构设计思路和过程，李先生认为这位架构师基本没有互联网产品设计经验。

        据李先生介绍，12306架构设计中连基本的分布式和高性能都没考虑过，诸如读写分离、高并发下的分布式处理也没考虑过，系统也没有考虑设置不 同数据库分布到不同的服务器上，甚至都没有考虑为读写做相应的缓存，整个流程中也没有考虑过队列，所以卡住后排队等基本情况都没想过。

        而这些都是互联网架构师需要具备的最基本的思维，这位 12306 的架构师完全没有这样的思维。

        其实 12306 这个系统的业务项比较复杂，跟机票系统一样，出票等业务规则复杂，由于规则负杂，会有特殊的颗粒、特殊的流，比如分段出票，退票、新增票等，所以必须要有 相应的架构设计与之相对应。比如从技术角度看，订票是一个写操作，查询是读的操作，不能因为查询很多影响订票操作，需要通过使用读写分离就可以实现。

        李先生认为，对于大的互联网的公司，12306是一个很简单的项目，好的架构设计再加上 10~20人的团队，产品和技术一体，可以很轻松地做好。而李先生从 12306 的架构师处了解到，其产品设计团队基本属于学院派的团队，与外部接触比较少，没有任何互联网产品经验，他们把 12306 当做了一个内部系统来开发，开发完成后又作为一个外部系统开放使用。所以出现现在的问题是难免的。

        另外这个团队解决问题的思维很业余，出了问题，比如出现拥堵就加服务器，再出问题还加服务器，服务器中使用了大量的小型机，价格都很贵。无限制地通过增加服务器来解决原始架构缺陷，人为地增加了系统成本。

        有意思的是，一位曾经参与过该项目的搜狐网友也在搜狐网上披露：这个系统，当年有些生产环境是我搭建的，去过开发现场。整个项目也就十几个人 吧，说实话，算下来一年人力成本三四百万撑死了。现场人员基本没有大型集成系统开发经验，否则不至于连环境都不会搭建。唯一让我印象深刻的是，现场吃的真 多——红牛，可乐，方便面，火腿肠。。。至于系统本身呢，也很糙。铁科研没有买 Oracle 的现场服务，导致所有环境都没有厂家的支持及现场服务。这么大的系统，没有分布式，甚至连个集群都没用，两台机子共享存储，居然做的是单活，不是集群。通 俗点说，本来可以用两台机子处理的事儿，生生放着一台不用。去搭建前对于软件服务器版本没有任何要求，很不严肃。。。根据我的经验，单单人力成本，最多五 百万，加上服务器和网络成本，不到一千万。

        另外“人称T客”也在微博中爆料：网友检验一下 12306，爆露出这个这个神奇的网站，是怎么做出来的。 数据库： Oracle 应用服务器：WebLogic 开发框架：Spring\Hibernate\Struts 连接池：C3P0 没有做基本判断，输入特殊字符，直接 SQL 语法错误，完全没有经验测试，太极这 3 个亿赚得好轻松呀。连 SQL 注入防范都做。