前言
2015年春节最大的特色就是“摇一摇”，微信红包在春晚摇一摇互动总量超过110亿次，峰值达8.1亿次/分钟，有185个国家传递微信祝福。支付宝钱包在除夕晚上8点达峰值，首页被点击的次数为8.832亿次/分钟。表面上来看“摇一摇”是在送红包，但从深层次的互联网思维来看，摇一摇的目的是要创造和凸显“移动支付”在互联网金融的价值链，甚至一带一路，将“移动支付”模式的业务，带出国门推向全球，此举对金融行业未来的生态影响意义重大。
摇一摇隐含的商业模式不是此篇文章讨论重点，在此要强调的是在云计算和大数据时代，任何一个商业模式的创新都需要有最先进的技术配合和支撑。从技术角度来看，这些看似业务逻辑简单的“摇一摇”在面对高流量和高并发情况下，承载天量的访问量对系统框架设计师来说是巨大的挑战。当面临“有计划、难预测、暂时性”的巨大访问量，该如何解决此问题？是花巨资建设系统呢？ 还是将需要“短暂”巨大资源的业务托管在云计算数据中心，让它们提供快速灵活可调度的资源呢？
本文作者从互联网收集大量有关12306的信息，首先描述12306系统与大型电商交易系统的主要差异和说明此差异为何需要巨大的计算资源来支撑； 再进一步探讨12306混合云设计的考量 - 安全性和系统资源扩展性，并说明为何只将“余票查询业务”放在阿里云提供服务。最后以论证的方式“推测”12306两地三中心的混合云架构设计（有关12306混合云的架构和解析是作者个人的推测，有误解地方请求交流和指正）
在此篇文章，不探讨火车运能不足，抢不到车票返乡引起民怨问题，因为铁路的基础建设需要时间解决；以Pivotal Gemfire为例， 是因为2015年12306在两地三中心部署数百个Gemfire节点，这些应用节点（“异于虚机节点”）可按需以热部署方式来扩展，体现“云”的伸缩特性和流动性。
一、12306与电商交易系统
很多人喜欢将12306与淘宝网做比较， 认为12306互联网售票网站从属性来说是电子商务B2C的一支；用户必须登录，浏览，选择商品，下订单， 订单确认，支付和物流。如果只看整个交易流程，它们确实是一样的。 但从深层次的细节探讨，12306背后所隐藏的业务逻辑是非常复杂，远远超过一般人的想象。
12306网站与电商交易系统业务逻辑的差异
如何解决大型网站所面对的高负载流量和高并发访问，一直以来都是全世界公认的技术难题。对于任何一个交易系统来说不外乎做两件事，一是提供查询，二是数据计算；任何查询业务都有响应时间的要求，从用户体验最好不要超过5秒钟；而数据计算（实时计算或非实时批量计算）与实际业务逻辑有密切的关系。
对于电子商务网站的交易系统，例如淘宝网，当店家出售一件商品，库存减一，客户退货，库存加一，当库存为零，商品下架，有问题线下讨论。此类交易系统提供简单快速的计算。因为不同品牌商品的销售彼此之间没有关联性，不会因为某件品牌商品的出售关联到其他品牌商品的库存量，它们的商品库存是属于“静态库存”；所以电商交易系统的主要设计重点是提供快速响应时间，高可用性（容灾和备份）和系统扩展性，避免在高峰交易期间，因为响应时间慢或是系统当机而失去庞大的商机。
12306互联网售票系统是业务逻辑很复杂的系统，如果将每张可出售的火车票当成一件商品来看，每张票的销售都会关联到整条路线每个站点可销售的余票量,有些站点的余票量会产生变化， 有些站点余票量不会有变化。由另外一个角度来看，当销售一张票， 改签，或退票时，整条路线每个站点的余票量都需要重新计算，也就是说每个站点的余票库存是个“动态变化库存”的概念。站点与站点之间的余票库存有巨大的关联性，此“动态库存”概念的业务逻辑是12306与电商网站最大的差异。12306的设计重点不但要具有大型电商网站所具备的特性外 （要提供快速响应时间，高可用性（容灾和备份）和系统的扩展性），还需要有强大的CPU计算资源来支撑。
12306 系统主要瓶颈 - 余票计算与配票规则
由上面所述，每张火车票的销售状态变化（买票，退票，改签），都会影响到整条路线火车站点可销售的余票量；例如，某条火车路线有100个车次，每个车次可承载1000人，有100个一等座， 900个2等座，另外还有50个火车停靠站，这有多少个排列组合？ 从理论上来说，余票计算是在解答数学模型的难题。
在整个客票系统里，有数十条行车路线，有3000多个车次（G,D,K,Z,C,..），5000多个火车站点，有不同的席次（硬座，硬卧， 软座， 软卧，无座），座位等级(商务， 一等， 二等)，和车票等级（一般，军人， 学生，残障，小孩）等因素，将这些参数放在数学模型上，至少有数千亿条的排列组合。而目前的客车运量有限，每天不超过1000万名旅客。 如何将1000万张车票分配到数千亿条的排列组合里面呢？并且还要考虑公正，公平的合理分配。
如果将整条路线的所有车票都放在起始站出售的话，乘车距离最远的先购票，创造的利润最大，但是下游站点就买不到票，失去公正和公平的分配原则。所以，每个站点的余票计算并不是简单的两站之间算好的票数，做加加减减的计算。
铁路运输为民众提供便捷的出行， 如何将有限资源公正公平的合理分配，让大众满意是需要靠智慧解决的。 参考国内外的售票原则，运输部门一定要制定一套复杂的分配规则，这些规则是与车次，路线，加班车，席次，座位等级，车票等级，乘车区间，x天预售期和搭乘时间等都有密切关系。 每一个特定的余票查询，都会触发余票计算，每班车次的余票计算都有上万条规则需要匹配，所有经过“乘车区间”的车次都需要做余票计算；全国有3000多个车次，5000多个站点，这些分配规则总数可能达千万条级别。例如，以沪宁线为例，在春运尖峰期间，经过“上海到南京”区间的车次达300多班次，每次查询需要计算300多班车次的余票量。
这意味着余票查询/计算需要使用大量的CPU计算资源，同时必须快速反应余票查询的结果给用户。在春运售票高峰期间，每分钟都有数万张车票的销售，假如余票查询的响应时间缓慢，这些信息就失去价值，会发生看得到票，但实际上买不到票的情况发生。
二、12306 混合云考虑因素和规划
一般的商业活动都有季节性的旺季和淡季之分，在旺季时烦恼是否有足够的库存，以免失在商机，在淡季时就要想办法促销，降低库存。 使成本最小化，利润最大化，是市场经济的商业法则。 12306互联网售票系统，也面临节假日和非节假日高高低低的需求，12306在春运售票高峰期间的访问流量（PV值）和平时访问流量高达上千倍的差异；如果按原来的系统架构，要解决春运时高流量高并发的问题，可能需要扩充“数十倍”或数百部的Unix服务器才能满足需求。 如果12306自建系统，但在春运以后，又该如何处理服务器过剩的问题，才不会造成资源浪费呢？
根据百度百科对混合云的定义，“混合云是融合公有云和私有云，是近年来云计算的主要模式和发展方向。企业用户出于安全考虑，更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到既省钱又安全的目的”。
混合云托管考虑因素
由上面的定义，混合云服务模式应该是12306最佳的选项，可以将“有计划，难预测，暂时性”需要巨大资源的业务放在公有云提供服务。如果12306采用混合云的服务模式，有哪些重要因素需要考虑？
- 托管方式：整个业务托管还是部分业务托管？
- 安全性的考量：敏感性资料该如何存放和保护呢？如何规避风险？
- 业务子系统的独立性：如果是部分业务托管，被指定托管业务的子系统是否能独立剥离原先系统的业务流程？
- 协同合作：在公有云的业务子系统的数据又如何回流与私有云的原来系统在业务上配合，协同合作呢？
- 数据源的传输和复制/同步：如何复制/同步私有云和公有云的数据？
- 资源的弹性扩展：迁移到公有云的业务子系统是否能实现按需弹性扩展，利用云计算数据中心的网络和服务器资源来提供服务？