1、描述12306系统与大型电商交易系统的主要差异并说明此差异为何需要巨大的计算资源来支撑。
2、进一步探讨12306混合云设计的考量 - 安全性和系统资源扩展性，并说明为何只将“余票查询业务”放在阿里云提供服务。
3、以论证的方式“推测”12306两地三中心的混合云架构设计。
很多人喜欢将12306与淘宝网做比较，认为12306互联网售票网站从属性来说是电子商务B2C的一支。用户必须登录，浏览，选择商品，下订单，订单确认，支付和物流。如果只看整个交易流程，它们确实是一样的。 但从深层次的细节探讨，12306背后所隐藏的业务逻辑是非常复杂的，远远超过一般人的想象。
1.1 12306网站与电商交易系统业务逻辑的差异
如何解决大型网站所面对的高负载流量和高并发访问题，一直以来都是全世界公认的技术难题。任何一个交易系统不外乎做两件事，一是提供查询，二是数据计算。任何查询业务都有响应时间的要求，从用户体验角度考虑，查询时间最好不要超过5秒钟。而数据计算（实时计算或非实时批量计算）与实际业务逻辑有密切的关系。
对于电子商务网站的交易系统，例如淘宝网，当店家出售一件商品，库存减一，客户退货，库存加一，当库存为零，商品下架，有问题线下讨论。此类交易系统提供简单快速的计算。因为不同品牌商品的销售彼此之间没有关联性，不会因为某件品牌商品的出售关联到其他品牌商品的库存量，它们的商品库存是属于“静态库存”。所以电商交易系统的主要设计重点是提供快速响应时间，高可用性（容灾和备份）和系统扩展性。避免在高峰交易期间，因为响应时间慢或是系统当机而失去庞大的商机。
12306互联网售票系统是业务逻辑很复杂的系统，如果将每张可出售的火车票当成一件商品来看，每张票的销售都会关联到整条路线每个站点可销售的余票量,有些站点的余票量会产生变化， 有些站点余票量不会有变化。由另外一个角度来看，当销售一张票、改签或退票时，整条路线每个站点的余票量都需要重新计算，也就是说每个站点的余票库存是个“动态变化库存”。站点与站点之间的余票库存有巨大的关联性，此“动态库存”概念的业务逻辑是12306与电商网站最大的差异。12306的系统除了要具有大型电商网站所具备的特性（要提供快速响应时间，高可用性（容灾和备份）和系统的扩展性），还需要有强大的CPU计算资源来支撑。
1.2 12306 系统主要瓶颈 - 余票计算与配票规则
由上面所述，每张火车票的销售状态变化（买票，退票，改签），都会影响到整条路线火车站点可销售的余票量；例如，某条火车路线有100个车次，每个车次可承载1000人，有100个一等座， 900个2等座，另外还有50个火车停靠站，这有多少个排列组合？ 从理论上来说，余票计算是在解答数学模型的难题。
在整个客票系统里，有数十条行车路线，有3000多个车次（G,D,K,Z,C,..），5000多个火车站点，有不同的席次（硬座，硬卧， 软座， 软卧，无座），座位等级(商务， 一等， 二等)，和车票等级（一般，军人，学生等）等因素，将这些参数放在数学模型上，至少有数千亿条排列组合。而目前的客车运量有限，每天不超过1000万名旅客。 如何将1000万张车票分配到数千亿条的排列组合里面呢？并且还要考虑公正，公平的合理分配。
如果将整条路线的所有车票都放在起始站出售的话，乘车距离最远的先购票，创造的利润最大，但是下游站点就买不到票，违背了公正和公平的分配原则。所以，每个站点的余票计算并不是简单的两站之间算好的票数，做加加减减的计算。
铁路运输为民众提供便捷的出行， 如何将有限资源公正公平的合理分配，让大众满意是需要靠智慧解决的。 参考国内外的售票原则，运输部门一定要制定一套复杂的分配规则，这些规则是与车次，路线，加班车，席次，座位等级，车票等级，乘车区间，x天预售期和搭乘时间等都有密切关系。
每一个特定的余票查询，都会触发余票计算，每班车次的余票计算都有上万条规则需要匹配，所有经过“乘车区间”的车次都需要做余票计算；全国有3000多个车次，5000多个站点，这些分配规则总数可能达千万条级别。例如，以沪宁线为例，在春运尖峰期间，经过“上海到南京”区间的车次达300多班次，每次查询需要计算300多班车次的余票量。
这意味着余票查询/计算需要使用大量的CPU计算资源，同时必须快速反映余票查询的结果给用户。在春运售票高峰期间，每分钟都有数万张车票的销售，假如余票查询的响应时间缓慢，这些信息就失去价值，会发生看得到票，但实际上买不到票的情况发生。
一般的商业活动都有旺淡季之分，在旺季时烦恼是否有足够的库存，以免错失商机，在淡季时就要想办法促销，降低库存。使成本最小化，利润最大化，是市场经济的商业法则。12306互联网售票系统，也面临节假日和非节假日高高低低的需求，12306在春运售票高峰期间的访问流量（PV值）和平时访问流量高达上千倍的差异。如果按原来的系统架构，要解决春运时高流量高并发的问题，可能需要扩充“数十倍”或数百部的Unix服务器才能满足需求。 如果12306自建系统，在春运以后，又该如何处理服务器过剩的问题，才不会造成资源浪费呢？
2.1 混合云托管考虑因素
根据百度百科对混合云的定义，“混合云是融合公有云和私有云，是近年来云计算的主要模式和发展方向。企业用户出于安全考虑，更愿意将数据存放在私有云中，但是同时又希望可以获得公有云的计算资源，在这种情况下混合云被越来越多的采用，它将公有云和私有云进行混合和匹配，以获得最佳的效果，这种个性化的解决方案，达到既省钱又安全的目的”。
由上面的定义，混合云服务模式应该是12306最佳的选项，可以将“有计划，难预测，暂时性”需要巨大资源的业务放在公有云提供服务。如果12306采用混合云的服务模式，有哪些重要因素需要考虑？
托管方式：整个业务托管还是部分业务托管？
安全性的考量：敏感性资料该如何存放和保护呢？如何规避风险？
业务子系统的独立性：如果是部分业务托管，被指定托管业务的子系统是否能独立剥离原先系统的业务流程？
协同合作：在公有云的业务子系统的数据又如何回流与私有云的原来系统在业务上配合，协同合作呢？
数据源的传输和复制/同步：如何复制/同步私有云和公有云的数据？
资源的弹性扩展：迁移到公有云的业务子系统是否能实现按需弹性扩展，利用云计算数据中心的网络和服务器资源来提供服务？
2.2 混合云的规划
按需弹性扩展改造
要解决12306面对“高流量，高并发“的难题是需要从软件平台和应用系统层面出发，要实现“可扩展的应用云平台架构”，灵活和快速热部署的机制，才是真正解决高并发访问的根本。12306承建单位-铁科院在此方面做很多改进，使用Pivotal Gemfire内存数据管理平台，重新设计和改造核心子系统，从用户登录，余票计算，票价计算，实名身份认证，到订单查询。这些改造后的业务子系统都能支持“按需弹性扩展”， 不再受限于原来关系型数据库无法做分布式扩展的问题。这些一连串的改造，打通各个环节，实现“质”的大跃进， 也为未来使用混合云服务模式的架构打下良好的基础。
信息安全和业务子系统托管的选择原则
下面进一步探讨如何选择“业务子系统”放在公有云提供服务，主要考虑两点因素，一为个人信息保护， 二为需要“短暂”且强大计算机资源支持的子系统业务。
1. 购票流程和个人信息：
登录：含个人信息
余票查询/计算：不含个人信息
订单确认和订单查询：含购票人信息和身份确认
付款：含个人的支付信息
2. 主要服务器集群和个人信息：
Web服务器 - 不含个人信息
应用服务器缓存服务器 - 不含个人信息
登录服务器 - 含个人信息
余票查询/计算服务器- 不含个人信息
订单确认和订单查询服务器 - 含个人信息
实名制身份确认服务器 - 含个人信息
…
3. 最耗用网络资源
Web服务器
应用服务器缓存服务器
余票查询/计算服务器
4. 最耗用服务器资源
Web服务器集群
应用服务器缓存集群
余票查询/计算集群
5. 售票高峰期访问量振幅最大业务
Web服务器
应用缓存服务器
余票查询/计算服务器
综合以上的分析，余票查询/计算业务符合安全性考虑和售票高峰期访问量振幅最大，最耗系统资源。其他适合放在公有云提供服务有三大服务器集群，Web服务器集群， 应用服务器缓存集群， 和余票查询/计算集群。
互联网有一篇关于2015年春运12306用户体验报导，中国铁道科学研究院电子计算技术研究所副所长、12306网站技术负责人朱建生说，为了应对2015年春运售票高峰，该网站采取5项措施：一是利用外部云计算资源分担系统查询业务，可根据高峰期业务量的增长按需及时扩充。二是通过双中心运行的架构，系统内部处理容量扩充一倍，可靠性得到有效保证。三是对系统的互联网接入带宽进行扩容，并可根据流量情况快速调整，保证高峰时段旅客顺畅访问网站。四是防范恶意抢票，通过技术手段屏蔽抢票软件产生的恶意流量，保证网站健康运行，维护互联网售票秩序。五是制定多套应急预案，以应对突发情况。
“为了保障春运期间正常订票，12306网站建设了两个生产中心。在中国铁路总公司又增加了一套设备。这样就增加了一倍的网络内部处理能力...多建中心的同时，也增加了网络的带宽，带宽从5G扩容至12G。增加带宽就等于我们多开了几个门，能让更多的用户同时进来 … 还不只这些，我们在春运高峰期租了个”云” … 在网络高峰期间，12306网站的查询量最大，占到整个网站的85%，就把75%的查询业务都放在租来的“云”上… “春运高峰期的点击量、浏览量是平时的几倍，甚至十几倍。从经济角度考虑，一个网站不太可能以最高峰值的承受力为标准来建设。我们只能在满足日常需求与高峰期售票需求之间寻求一个最佳点，合理进行硬件配置。” 现在云技术成熟，高峰期租个云用几天，价格合理，安全也有保障。
有这些新设备、新技术，今年的用户体验大为改善。据测算，今年12306网站的点击速度和页面打开速度比去年缩短了一半。
由上面对话透露的信息，再以专业IT经验来分析并推测12306 混合云的架构设计。
1. 两个生产中心和壹个“云”：
两个生产中心应该是指铁路总公司数据中心和铁科院数据中心，“云”是指阿里云。
2. 75%的查询业务都放在租来的“云”上：
意谓着12306只将75%流量的查询业务交给阿里云托管，阿里云只提供租赁查询服务，不涉及任何系统功能的改造。
3. 两地三中心 高可用性和容灾设计：
以专业的IT来看，12306提供全国的网上售票服务，在系统设计上一定有高可用性和容灾的设计。Pivotal Gemfire平台已具备高可用性的设计， 所以，两个生产中心一定运行整套业务流程服务，彼此作为异地容灾备份的准备，而阿里云只提供部分业务查询的服务。
4. 业务连续性，应用不中断，操作可持续的设计:
在2012年12月24号下午，由于空调设备故障，12306中断服务数小时。这可以看出12306是单数据中心的设计， 没有考虑容灾的设计。
为了吸取以前的经验，假设12306已经考虑业务连续性，应用不中断，操作可持续的设计，这意味着双生产中心是需要并行作业提供服务；万一有一个生产中心系统出故障，可以在瞬间将流量导至运行良好的数据中心，保持服务的连续性。
5. 数据源的传输和数据库的复制：
过去数据源的传输和数据库的复制机制已经证明此技术是稳定和成熟的，所以会沿用以前的设计。
6. 阿里云的余票查询业务托管：
在前一节已经详述，考虑个人资料的敏感度和安全性，12306不会将这些资料放在阿里云，但会将需要耗费巨大资源的余票查询业务放在阿里云提供服务。另外符合此条件的有3大服务器集群，Web服务器集群， 应用服务器缓存集群， 和余票查询/计算集群。
综合上述的分析，推测和描绘12306混合云的架构如下图：
12306两地三中心的混合云架构是目前国内规模最大，业务系统最复杂的混合云服务。在12306承办单位 - 铁科院的领导下，经过精心的设计，部署和试运行，在2015年春运上线，它的表现是很令人瞩目的。它的效果和影响总结如下：
1. 提供“高并发，低延迟”的解决方案，一劳永逸，不用烦恼后续硬件升级的问题。
2. 通过多集群技术，实现多重的高可用性，确保高峰压力下和系统异常的情况下保证业务的持续性。
3. 构建一个可扩展的云应用平台架构，灵活和快速热部署的机制，为未来混合云的部署打基础。
4. 使用数十部 x86服务器 （或是上百部虚拟机）可以达到 10,000 TPS以上，提升原来系统性能达30倍以上。余票查询集群性能从之前的10余分钟提升至2分钟左右。
5. 12306“订单分库二级查询”子系统：将订单生成与订单查询分库处理，订单查询性能提高50倍， 订单生成性能提高4-5倍。
6. 使用pivotal Gemfire改造后的分布式系统，极易分散部署到不同的数据中心
12306混合云设计的特点归纳如下：
1. 业务托管：
从整个购票流程来说，12306只是将部分流程的环节-“余票查询”业务交由阿里云提供服务，并不是“整个系统”按需扩容的托管，这与一般企业的业务托管有最大的差异。如何将“业务子系统”剥离整个系统独立作业，再将数据结果传回系统，协同作业，这需要从应用系统框架设计着手。
2. 敏感资料的存放和安全性：
12306是公共服务平台，敏感性资料的保护和安全性是首要考虑因素。在混合云设计上，12306将这些资料存放在私有云的数据中心， 确保数据安全无虑。
3. 业务连续性，应用不中断的容灾设计：
双数据中心并行作业，不但可以分担高负载运行，而且可以相互备份， 保证操作不间断。
4. 资源动态扩展：
将“难预测，暂时性”的巨大访问量-余票查询业务放在阿里云，阿里云可以按需动态调整网络带宽和“虚机“资源，保证12306的服务品质，并解决网络传输瓶颈问题。
5. 关系型数据库（SQL） 和非关系型数据库（NoSQL）混合应用
12306将热点数据放在NoSQL的Gemfire平台，提供快速查询和计算；将关键数据持久化到关系型数据库。
总体而言，目前12306混合云架构是很合理的设计，求稳，求安全，又省钱。如果追求技术的完美性来说，有如下四点建议：
1. 提供同个车次不同车厢的联程票 （例如，在同个车次， 北京到上海没票， 但北京到天津， 天津到南京， 南京到上海有票），和不同车次的联程票 （中途站点换车），使旅客出行订票更方便。
2. 思考“数据大集中”的模式，摒除路局和12306数据中心的数据交换，提高处理效率，且易于整个售票系统的维护。
3. 整合12306售票网站和线下作业系统（窗口购票，电话订票，代售点），提供更快速的服务。
4. 大胆采用“软件定义数据中心”的技术，可以做更灵活更快速数据中心的迁移/复制，为将来多数据中心混合云的部署和服务（分散网络流量）或异地容灾设计打基础。
注：有关12306混合云的架构和解析是作者个人的推测，有误解地方请求交流和指正
作者介绍：
刘云程
毕业于台湾清华大学。
在IT行业有近30年工作经验，曾任职于IBM中国研究中心负责电子商务和移动互联网方面的研究。
现主要负责帮助客户应用系统升级、迁移到高性能和高扩展性的“云应用平台”。
技术编辑：
杨志洪
【DBA+社群】联合发起人。Oracle ACE、OCM、译著《Oracle核心技术》。
往期作品：
小编精心为大家挑选了近日最受欢迎的几篇热文：
回复001，看陈爱珍《从文艺女到技术咖，一位美女工程师的华丽转身》；
回复002，看丁俊的《【重磅干货】看了此文，Oracle SQL优化文章不必再看！》；
回复003，看胡怡文《PG，一道横跨oltp到olap的梦想之桥》；
回复004，看陈科《memcached&redis等分布式缓存的实现原理》；
回复005，看陆传胜《听阿里巴巴JVM工程师为你分析常见Java故障案例》；
回复006，看郑晓辉《存储和数据库不得不说的故事》；
回复007，看袁伟翔《揭秘Oracle数据库truncate原理》；
回复008，看杨建荣《立等可取:工具定制让Oracle优化变得更简单快捷》；
回复009，看丁启良《LINUX类主机JAVA应用程序占用CPU、内存过高分析手段》；
回复010，看徐桂林《以应用为中心的企业混合云管理》。
230721
1、导入Mongo Monitor监控工具表结构（mongo_monitor…
上面提到： 在问题描述的架构图中我们可以看到，Click…
PMM不香吗？
如今看都很棒