每年的春运都堪比一次人类大迁徙，10年前买回家的票都要搬个小板凳去火车站排队，如果能买到还算是万幸，再赶上一些人家住在小山村，还要到大站转乘长途汽车。可以说，每次回家都是一次痛与乐并存的体验。然而随着科技互联网的发展，12306网上购票系统逐渐走进人们的视野，时至今日已经成为主流的购票手段之一。
当12306走向云端 人们还在为买票发愁吗12306算得上是世界上规模最大的实时交易系统之一，购票人数可能达到数亿级别，意味着放票的时候你可能会同时遭遇上亿的竞争对手。此时，网站的处理能力和实际访问需求难以跟上，直接结果就是网站打不开或者系统不稳定。起初，12306曾想过用分线路分时段的方法进行分流，不过效果并不明显，毕竟用户不会那么“自觉”的去分批买票。
乍看之下，12306有点像电商系统，车票就是售卖的商品，未出售的车票就是库存。不过仔细与淘宝、天猫等电商网站对比之后，就会发现12306的业务属性要复杂很多。例如，北京到上海的1461车次一共有30个停靠站，假设一个人从北京出发，那么他可能选择廊坊北到上海29个停靠站作为自己的终点站，所以单个1461车次，一次座位复用计算最多涉及30*（30-1）/2=435个商品（SKU）。如果再算上不同类型的车票（卧铺、硬座和站票），则共有1305种产品。看到了吧，这可不是简单的库存叠加，还要结合一些人性化的因素。
在去年初的春运期间，12306网站的单次订票交易平均响应时间为0.5秒、网站PV值日均超过400亿次，在云端的查询次数日均高达250亿次。
如果要回溯12306的上云之路，还要从2014年说起，那时候12306就开始与阿里云的工程师探讨如何把余票查询系统放到云上。在之后的春运售票期间，12306将75%的余票查询业务切换到了阿里云上。当时，主要考虑的是将业务系统在前端WEB以满足高流量、高并发的需求。同时，云计算资源的伸缩性也能大幅节省成本支出，而将余票查询（而非核心系统）托管在公有云上，还能避免敏感性资料泄漏，保护用户数据安全。
“云化”后的余票查询系统能够做到按需获取所需要的服务器虚机资源，可以动态调整网络带宽，利用这些可扩展资源，解决在高流量和高负载情况下，系统无法快速弹性扩展导致的性能瓶颈和系统崩溃。此外，两地三中心混合云模式提高了12306的灾备能力。
两地三中心混合云
在子系统上云的一期改造之后，12306开始利用GemFire（Pivotal企业级大数据PaaS平台的一部分）改造订单查询系统。在改造过程中，12306并没有用传统的Unix小型机，而是大胆的选择了x86服务器，采用10几台X86服务器实现了以前数十台小型机的余票计算和查询能力，单次查询的最长时间从之前的15秒左右下降到0.2秒以下，缩短了75倍以上。
Pivotal Gemfire分布式内存数据平台是通过云计算平台技术，将诸多X86服务器内存集中起来，形成一个资源池，然后将全部数据加载到这个资源池之中，进行内存计算。同时，为了提高灾备能力，Gemfire还在集群中保存了多份数据，这样当一个机器故障后，并不会影响整个系统的运行，也不会造成数据缺失。
GemFire架构12306在经过Gemfire改造后，能够通过客户业务逻辑性和数据关联性，将关联性强的数据放置到同一个服务器节点，进而提升系统性能；同时，根据测试，可以得出结论，由X86服务器为基础搭建的应用云平台可以随着客户业务增长，增加服务器数量，能够保持系统性能随着服务器增加几乎保持线性增长。
经历了两地三中心混合云架构应用和Pivotal Gemfire改造后，12306达到每秒至少支持10000 TPS以上，基本满足高并发需求。通过GemFire多集群技术，实现多重的高可用性，确保高峰压力和系统异常的情况下保证业务的持续性。
随着数据中心计算、网络、存储性能的不断提升，所承载的业务载荷也会随之增加，公有云的灵活扩展优势显着。不过倒票的黄牛党也从线上跑到了线上，这就需要云环境不仅需要强大的基础支撑，还要有智能化的抵御机制。举个例子，12306后台的冲突判别系统可以分析购票行为，包括监测异常账户、地址迁移、漏洞筛查等，对一些高频IP进行有效处理。
总的来说，云计算和大数据技术对于传统业务架构的颠覆毋庸置疑，而阿里云和12306的牵手也算是一次成功的应用。未来，当智能化手段更多地赋能于日常生活的方方面面，人们也将受益于这种红利，最终让出行变得更加便捷和高效。
