注：本文首发于CSDN，转载请标明出处。
【编者按】在年前的「技术揭秘12306改造」专题中，负责12306改造的技术架构师刘云程从技术的角度、用科学论证的方式说明12306是如何实现高流量高并发的关键技术，以及深入探讨了12306两地三中心混合云架构，今天，他继续为大家带来第三篇：传统框架云化迁移到内存数据平台。
以下为正文》》
摘要
12306混合云成功案例给予最大的启发就是打造一个从下到上都可做弹性扩展的“云应用”系统，企业客户可将关键业务的“子系统”部署在资源丰富的云计算数据中心，“云化”后的子系统可“按需”获取所需要的服务器虚机资源和动态调整网络带宽，利用这些资源解决在高流量和高负载情况下，系统无法快速弹性扩展导致的性能瓶颈。
此篇文章列举不同类型的系统改造迁移到云平台方案，从改造思路探讨，系统框架设计和项目实施的整个迁移过程，供大家参考和交流。在此以PivotalGemfire云平台为例子，因为它已有大规模部署成功案例。客户IT环境是五花八门，对系统改造的思路和目的也不尽相同，Gemfire是不错的选择，但它不是唯一的选项。
前言
在过去20年，系统架构师最常用的系统框架是三层架构设计，即Web层，应用业务逻辑层和数据库层；Web层和应用逻辑层可随着业务变化做快速弹性扩展，但绝大部分关系型数据库层无法实现此功能。在云计算，大数据和移动互联网时代，由于业务成长快速，服务多样化，数据量急剧增加，用户对系统响应时间有更严格的要求；在高负载情况下，无法横向扩展的数据库层往往成为系统性能的绊脚石。
在此篇文章，讨论重点是从软件中间件平台（PaaS）和应用系统（SaaS）层面出发，使用“分布式内存数据网格(InMemoryDataGrid)”技术，将传统架构改造迁移到云平台。系统改造有多种不同的方式，主要是要看改造的目的和所受的限制来决定;为了具体化说明，我们以下列三个案例提供给读者参考和交流。
一、12306混合云的启示
在前两篇文章提到，2012年春运后12306承办单位-铁科院引入”分布式内存数据网格”技术，将余票计算/查询子系统改造迁移到Gemfire云平台，局部解决12306的主要瓶颈；改造后的子系统在2013年春运时上线，其效果是显著的，虽然整个系统运行还是有”卡，顿”等不足之处，但铁科院对此技术深具信心坚持改革，才有后续一连串的子系统改造出炉。在2015年春运，建立两地三中心混合云的服务模式，将大部分余票查询流量引导到阿里云提供查询服务；此举的目的是要借助云计算数据中心的资源，“临时性”解决在春运期间由于互联网购票和刷票软件所引发的难预测，高流量，和高并发请求，降低系统不稳定的风险。
12306混合云成功案例最大的启发是给企业客户和政府部门带来新的思路，就是将关键业务的“子系统”改造迁移到云平台架构，根据实际情况，将“云化”后的子系统部署在资源丰富的云计算数据中心（私有云或公有云）。例如，12306核心系统在经过全面改造和优化后，每个云化后的子系统都具有特定的独立性，因为相关数据都放在Gemfire内存数据网格节点；这意味着这些子系统类似“云”一样，可以随着业务需求变大或变小，一分为多，任性的漂移到多个不同数据中心来协同合作，避免在IT设备方面的重复投资，并提高资源的使用率。
云化后的子系统部署在多数据中心，需要特别注意下列两点建议：
如果将子系统部署在公有云提供服务时，数据隐私的保护和安全性应为首要考虑。如果规划将子系统部署在多数据中心时，在系统框架上必需考虑上下游子系统之间的数据传输或同步/异步的设计。
以12306为例，两地多中心混合云的架构示意图如下；在春运售票高峰期间可以将余票查询功能部署在多个公有云数据中心提供快速服务（例如阿里云和电信天翼云）。
两地多中心混合云架构
二、系统改造迁移的思路和需求
随着企业成长，对于一个复杂的大系统来说，其业务功能不断增加，服务方式多样化，数据存储量越来越大，但系统性能越来越慢，而用户对响应时间的要求越来越严格；尤其是在过去5年里，每年都有新技术的演进（大数据和分布式内存数据平台）和新业务的衍生（物联网应用，社交应用平台和移动应用）。
当传统架构系统已逐渐无法满足日趋成长的业务需求时，有两种方案可供选择，一是从硬件着手，scaleup的选项，就是更换性能更强大的服务器；二是scaleout的选项，从软件平台着手，进行应用系统改造，采取弹性可扩展的框架设计。
更换硬件服务器是最简单的做法，但以后更换成本会越来越高，系统性能提升是越来越有限。软件应用系统的改造，是一劳永逸从根本做起，改造成本是与系统的复杂度有关，是需要全面改造？还是选择性的局部改造？这需要根据实际使用情况来决定。
针对系统的scaleout设计，如果要推翻以前的架构，重建系统，那是个大工程，除非有下列三钟情况：
否则，最省钱和最有效的方法就是针对系统瓶颈做“局部改造”来提高性能，保护过去的投资。例如，社保项目就是典型例子
在此篇文章，讨论的重点是如何将系统改造迁移到云应用平台，由于每个系统都有其特殊性和复杂性的开发背景，其设计的系统框架，所采用的软件平台和开发技术也都随着时间演进而不一样。因此改造的方式需要依据实际的环境来进行。
1.12306系统改造思路和需求–按阶段逐步云化核心子系统
2.社保系统改造思路和需求–短平快的局部子系统云化
3.金融单位POC测试改造思路和需求–建立可扩展的“分布式内存缓存数据层”
金融单位系统庞大复杂，所有的子系统从设计到开发都需要严格遵循统一开发流程，
核心子系统业务逻辑不轻易更改。对系统而言，查询业务量多，数据量大，关联表格多，在高并发情况下，查询反应时间长。
怀着淡定从容的心态去面对，也就没有了真正意义上的寂寞了。
