12306大考：高压下的云策略

　　转眼，春节将至，背上归家的行囊，拿起视若珍宝的火车票，期待着旅途一切顺利～

　　每逢年终，抢票就像是春节的序幕，在每个归家游子身上上演，而这场序幕的导演正是12306。

　　今天我们不谈火车票供求是否平衡，今天我们只聊聊高压下的那些技术革新。

　　五年前，12306作为一个新晋网站，怀揣着美好的愿景，观摩了外国购票网站后，在2011年6月12日，正式上线了自己的页面。然而，随之而来的十一黄金周、春运都将“理想很丰满，现实很骨感”演绎得淋漓尽致。至此，12306进入了一个全民大吐槽的时代。

　　有人说：为什么我的眼里常含泪水？因为我对12306爱得深沉；有人说：12306虐我千百遍，我待12306如初恋；还有人说：还不如把12306项目外包给阿里巴巴或IBM等大企业……

　　事实真的是这样吗？据知情人士消息，12306在2012年春运经历了悲惨亮相之后，确找了阿里巴巴、IBM等大型企业，希望提供解决方案，但是，由于12306网站与普通的电商平台有很大的不同，并没有企业能给出完备的解决方案。

12306后台（图片来自网络）

　　那么究竟有什么不同呢？

　　答案就是：B2C库存。

　　举个栗子来说，北京到上海的1461车次一共有30个停靠站，假设一个人从北京出发，那么他可能选择廊坊北到上海29个停靠站作为自己的终点站，所以，单个1461车次，一次座位复用计算最多涉及30*（30-1）/2=435个商品（SKU）。如果再算上不同类型的车票（卧铺、硬座和站票），则共有1305种产品。正是因为这种B2C库存管理变态之处，让我们无法将12306与某宝做简单、直接的对比。

　　即便如此，在高压之下，12306也在积极做出改变，下面我们就来看看，那些年被我们一路骂过来的12306，究竟做过哪些技术上的努力呢？

　　上云：两地三中心混合云

　　12306作为世界上规模最大的实时交易系统之一，高流量和高并发一直是需要解决的关键问题。首先我们要了解在整个12306系统架构中，请求次数最集中，最频繁的是什么？毋庸置疑，一定是余票查询系统。它的请求次数占到整个网站的85%。一般我们在买票过程中，都会多次提交查询请求，更不要说大量刷票软件问世后，说增加的工作负载；这一切都让余票查询系统成为整个系统的“累赘”。

　　那么12306又该如何甩掉这个“累赘”呢？

　　答案就是：就把75%的查询业务都放在租来的云上！

两地三中心混合云（图片来自网络）

　　在2012年春运后，12306痛定思痛，不仅组团去某宝学习后台搭建经验，更采用了混合云架构，将阿里云引入自己的系统架构，搭建一个两地三中心（铁路总公司数据中心、铁科院数据中心和阿里云）混合云架构，将大部分余票查询流量引导到阿里云提供查询服务。

混合云架构（图片来自网络）

　　这里12306选择引入公有云，一方面，可以让12306在高流量时期提供了充足的空间，避免了因为高并发的流量冲击导致的宕机；另一方面，在请求次数减少时，可以缩减公有云，这样就节省了成本开支；除此之外，将余票查询（而非核心系统）托管在公有云上，还能避免敏感性资料泄漏，保护用户数据安全。

　　“云化”后的余票查询系统能够做到按需获取所需要的服务器虚机资源，可以动态调整网络带宽，利用这些可扩展资源，解决在高流量和高负载情况下，系统无法快速弹性扩展导致的性能瓶颈和系统崩溃。同时，两地三中心混合云模式提高了12306的灾备能力。

　　Pivotal Gemfire分布式内存数据平台

　　在子系统上云的一期改造之后，12306开始利用GemFire（Pivotal企业级大数据PaaS平台的一部分）改造订单查询系统。

GemFire架构（图片来自网络）

　　在改造过程中，12306并没有用传统的Unix小型机，而是大胆的选择了X86服务器，采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力，单次查询的最长时间从之前的15秒左右下降到0.2秒以下，缩短了75倍以上。

　　Pivotal Gemfire分布式内存数据平台是通过云计算平台技术，将诸多X86服务器内存集中起来，形成一个资源池，然后将全部数据加载到这个资源池之中，进行内存计算。同时，为了提高灾备能力，Gemfire还在集群中保存了多份数据，这样当一个机器故障后，并不会影响整个系统的运行，也不会造成数据缺失。

　　12306在经过Gemfire改造后，能够通过客户业务逻辑性和数据关联性，将关联性强的数据放置到同一个服务器节点，进而提升系统性能；同时，根据测试，可以得出结论，由X86服务器为基础搭建的应用云平台可以随着客户业务增长，增加服务器数量，能够保持系统性能随着服务器增加几乎保持线性增长。

　　经历了两地三中心混合云架构应用和Pivotal Gemfire改造后，12306达到每秒至少支持10000 TPS以上，基本满足高并发需求。通过GemFire多集群技术，实现多重的高可用性，确保高峰压力和系统异常的情况下保证业务的持续性。

　　在2015年，12306进一步使用GemFire对系统进行升级，总共建立5个Gemfire集群。提升了系统性能，同时保证了数据安全。

　　整机柜服务器

　　近年来，数据规模持续增长，大型互联网企业持续扩容，融合架构越来越受到重视，整机柜服务器也应运而生。应该说，整机柜服务器从天蝎计划初始就备受关注，主要是为了给大型互联网企业提供一种打破传统束缚，专注于提升整体性能，节约数据中心能耗（PUE）的解决方案。在同样规模、同样投资的情况下，通过服务器节能优化，优化空间利用率，降低成本。

　　经历了采用混合云架构和GemFire改进后，12306并没有止步于此，而是开始了自己的扩容采购。面对不低于大型互联网公司的请求和高并发、高流量的特点，12306采购了大批整机柜服务器。而自从2011年天蝎项目组成立以后，包括浪潮、华为、联想在内的IT基础设施供应商，都开始了自己的整机柜服务器研发旅程。

计算密度更高、节点形式更灵活的SmartRack整机柜服务器

　　其中浪潮SmartRack打破了传统服务器固有设计架构和机柜的标准限制，节点高度增加5%，单机柜最大达80个节点，机柜深度增加19%，并取消了机柜侧柱设计，总体空间利用率提高了31%，部署密度最高可提升2倍；整机柜模块化的设计使运维更为方便，集中供电、散热和集中管理者大大节省了能耗，降低了运维成本。

　　12306移动购票平台后台系统正是采用了包括SmartRack在内的整机柜服务器，根据实测数据表明，能耗相比传统产品可降低15%，相比传统刀片降低6%。而且SmartRack可以提供更加灵活的GPU节点方案，计算密度相比传统刀片可提升2倍以上。我们可以看见，12306并没有固步自封，相反，在舆论和现实高压之下不断改进自身IT架构，保持自己的系统处在科技前沿。

12306架构图（图片来自网络）

　　2016年的春运大考正在进行，而12306的大考已经逐渐落下帷幕。我们可以看到12306在经历了亮相之初的全民声讨之后，通过采用混合云架构、Gemfire改造和引入整机柜服务器几个步骤已经逐渐走上正轨。虽然网站前端还不甚美观，但12306的内在已经发生了巨变，笔者认为：今年的12306大考已经过关。如需吐槽，请留言。或出门左转，查看《12306你“购”了！论验证码逼死多少人？》