秘密合作半年 阿里同12306关系被曝光

　　通信世界网消息(CWW) 1月16日，网络问答社区知乎上一名阿里云工程师爆料，12306网站已将车票查询业务放到阿里云上。该工程师表示其曾参与过12306春运项目，认为双11在业务规模上更有挑战，而12306则在业务复杂度上更高。

　　文中详细介绍了12306使用云计算的一些技术细节。内容如下，部分有删减：

　　铁路运营是一个庞大的社会工程，每年春运，相当于把全国人口“搓一圈麻将”。事实上，在互联网售票之前，网点售票已经实施多年。换句话说，铁路售票实际上一直有一个相当庞大且复杂的、跨多个路局的信息系统在支撑，而且可以追溯到80或90年代，维护至今。这个系统也许不仅支持了售票，可能还包括调度等核心业务。那这里就有一个问题：在做互联网售票的时候，是否要重构一下原有的系统呢?

　　这个问题值得反复掂量。大家应该知道，彻底重构一个运行数十年的系统的开销和风险吧，粗略一想涉及到各种业务逻辑、软硬件供应商、版本与维护协议等等。

　　绝大多数的互联网技术同僚应该会倾向于在现有系统上做web前端，先让系统“用起来”，然后再集中技术力量逐步优化整套系统架构。这也是当时12306的选择，这就导致有很多历史的包袱，还要考虑线下售票系统。

　　知乎上很多人拿春运售票和我厂(阿里)双11比较，究竟哪个牛逼?个人感觉两者同属于重量级的网站业务，双11在业务规模上更有挑战，而12306则在业务复杂度上更高。

　　火车票跟很多票(包括淘宝天猫的商品、机票、体育场馆门票等)有不一样的属性。比如，从北京到广州，沿途有多个站点，理论上乘客可以选择任意 一段区间购票，所以每买一张区间票，可能同时裂变出多张区间票。这个逻辑比大多数电子商务系统要复杂的多。假如说要再添加一些更人性化的feature，比如根据订票者身份证里的年龄优选上下铺、优选号等，那么查询和出票逻辑就更复杂了。

　　在一个后端上，setup一个web前端(包括入口、安全、缓存和逻辑，非指web页)，这个挑战也是巨大的。因为这个前端很容易瞬间胀大， 甚至被撑爆。“撑爆”的概念不难理解，奥运会的订票高峰，中美海底光缆拥塞，包括杰克逊去世后瞬Google瘫痪，或者DDoS拒绝服务攻击，都是这种现象。

　　根据官方公布的数字，有人统计了一下：需要数千个pv，才能出一张票。这个说法并不能得出“出票效率低”的结论，但是恰恰很形象的说明了查询量的巨大。

　　天量的火车票查询是影响12306性能的重要原因之一，大概占了90%以上的访问流量。更棘手的是：峰谷的查询有天壤之别，几乎没有办法在成本和并发能力之间做一个好的平衡。以往的一个做法是从几个关键入口流量控制，保障系统可用性，但是会影响用户体验。

　　淘宝/天猫大促的时候，也会增加服务器，阿里的业务盘子大，这些新增的机器很快会被其他业务(包括阿里云)消化掉，可能还不够。但是对于 12306来说，就比较难做到这一点。

　　这成为今年12306与阿里云合作的一个契机：通过云的弹性和“按量付费”的计量方式，来支持巨量的查询业务，把架构中比较“重”(高消耗、低周转)的部分 放在云上。这是一个充分利用云计算弹性的绝好实例，也是在系统架构上做“轻重分离”的一个典型case，把小而精的核心业务系统保持不动，把 “傻大笨粗”(非贬义)的系统迁移到云计算上。

　　今年初我们和12306的技术团队开始讨论如何将余票查询系统放到云上，十一黄金周做了测试效果不错，到春运12306决定将75%的余票查询业务放到云上。

　　做这个项目一晃有小半年了，感触很多。大家知道双11对阿里技术团队是一个不小的挑战，我参加了4年，其中有两年过的尤为艰苦。当时技术团队经常被业务方指责，就像现在大家对待12306的态度一样。但客观说，双11大促推动了阿里的技术成熟，春运也推动了12306采用更多面向未来的技术。

　　为什么是余票查询?

　　1. 访问量巨大，占12306整个网站流量的90%以上，业务高峰期并发请求密集，性能要求是整个业务系统中最为重要的一环;

　　2. 与其他业务在逻辑上相对独立，使用云计算的话不需要对整个网站的业务架构做改造。

　　实施过程可否透露?(隐去部分敏感信息，请理解)：

　　1. 把余票查询模块和12306现有系统做分离，具备独立部署的能力;

　　2. 在云上独立部署一套余票查询系统。这样子12306和云上都有了一套余票查询系统，，调度更为灵活;

　　3. 一些安全措施,吧啦吧啦吧啦……

　　根据运行情况，云上的余票查询与12306原来的余票查询可以互相补位，根据实时的负载情况，来调配不同的访问比例，充分利用云的弹性。

　　云计算跟“堆硬件”有什么区别?

　　这里主要是"春运 vs 平时"、"业务量 vs 成本"的问题：

　　1. 传统IT方案，为应对春运的业务压力，需要按照峰值采购大量硬件设备，从规划、建设到投产、服务整个供应链条长成本高，capex和opex上的投入都比较大，很难精确把控，而春运后大量设备会处于空闲状态，利用率低，造成巨大的浪费。

　　2. 还有至关重要一点是，假如按照传统方案，在实际业务峰值超出了初始评估量时，服务将面临无法完全承载而瘫痪，因为为大规模服务器的采购、交付、部署到应用上线所耗费时间以月计，根本无法在业务量激增时"即插即用"。

　　3. 云本身就比自己买硬件要便宜，另外所有资源都是“按量计费”，从十一黄金周到春运的过程里，12306在云上做了两次大型扩容，每次扩容的资源交付都是在分钟级就完成。业务高峰结束后，可以释放掉不必要的资源，回收成本。