揭秘12306技术改造（三）：传统框架云化迁移到内存数据平台

注：本文首发于CSDN，转载请标明出处。

【编者案】在年前的「技术揭秘12306改造」专题中，负责12306改造的技术架构师刘云程从技术的角度、用科学论证的方式说明 12306是如何实现高流量高并发的关键技术，和深入探讨了12306两地3中心混合云架构，今天，他继续为大家带来第3篇：传统框架云化迁移到内存数据平台。

以下为正文》》

摘要

12306混合云成功案例给予最大的启发就是打造1个从下到上都可做弹性扩大的“云利用”系统，企业客户可将关键业务的“子系统”部署在资源丰富的云计算数据中心，“云化”后的子系统可“按需”获得所需要的服务器虚机资源和动态调剂网络带宽，利用这些资源解决在高流量和高负载情况下，系统没法快速弹性扩大致使的性能瓶颈。

此篇文章罗列不同类型的系统改造迁移到云平台方案，从改造思路探讨，系统框架设计和项目实行的全部迁移进程，供大家参考和交换。在此以Pivotal Gemfire云平台为例子， 由于它已有大范围部署成功案例。 客户IT环境是5花8门， 对系统改造的思路和目的也不尽相同，Gemfire是不错的选择，但它不是唯1的选项。

前言

在过去20年，系统架构师最经常使用的系统框架是3层架构设计， 即Web层， 利用业务逻辑层和数据库层；Web层和利用逻辑层可随着业务变化做快速弹性扩大，但绝大部份关系型数据库层没法实现此功能。 在云计算，大数据和移动互联网时期，由于业务成长快速，服务多样化， 数据量急剧增加，用户对系统响应时间有更严格的要求； 在高负载情况下，没法横向扩大的数据库层常常成为系统性能的绊脚石。

在此篇文章，讨论重点是从软件中间件平台（PaaS）和利用系统（SaaS）层面动身，使用“散布式内存数据网格( In Memory Data Grid)”技术，将传统架构改造迁移到云平台。系统改造有多种不同的方式，主要是要看改造的目的和所受的限制来决定; 为了具体化说明， 我们以以下3个案例提供给读者参考和交换。

1. 12306项目：全部售票环节的1系列核心子系统都经太高度“云化”。 目的是可以将云化后的子系统“按需”灵活部署在不同的数据中心（公有云或私有云），提供优良服务。 云化的手段是将子系统业务逻辑和数据都放在Gemfire集群上履行， 利用Map Reduce的技术，建立可弹性扩大平台，提供“高性能CPU计算能力”。
2. 某市社保项目：采取短平快的局部“子系统云化”，针对有高并发需求会致使瓶颈的子系统进行改造。改造的手段是将子系统业务逻辑和数据放在Gemfire节点上履行, 建立可弹性扩大平台，利用Gemfire散布式并行查询技术来解决“高并发查询”的要求。
3. 金融单位POC测试项目： 问题在于系统的查询业务量多，关联表格多，在高并发情况下，查询反应时间长。 POC目的是要验证在不更改子系统业务逻辑限制下，以最小的代价，对“数据访问层 （DAO）”进行修改，建立可扩大的“内存数据缓存层”，解决“高并发查询“的方案；另外，还有数据库与Gemfire集群之间“失效转移 fail over”的设计。 以此为基础，以后再将业务逻辑逐步放到Gemfire平台，进行改造升级。

1、12306 混合云的启示

在前两篇文章提到，2012年春运后12306承办单位-铁科院引入”散布式内存数据网格” 技术，将余票计算/查询子系统改造迁移到Gemfire云平台，局部解决12306的主要瓶颈；改造后的子系统在2013年春运时上线，其效果是显著的，虽然全部系统运行还是有”卡，顿”等不足的地方，但铁科院对此技术深具信心坚持改革，才有后续1连串的子系统改造出炉。在2015年春运，建立两地3中心混合云的服务模式，将大部份余票查询流量引导到阿里云提供查询服务；此举的目的是要借助云计算数据中心的资源，“临时性”解决在春运期间由于互联网购票和刷票软件所引发的难预测，高流量，和高并发要求，下降系统不稳定的风险。

12306混合云成功案例最大的启发是给企业客户和政府部门带来新的思路，就是将关键业务的“子系统”改造迁移到云平台架构，根据实际情况，将“云化”后的子系统部署在资源丰富的云计算数据中心（私有云或公有云）。 例如， 12306核心系统在经过全面改造和优化后， 每一个云化后的子系统都具有特定的独立性，由于相干数据都放在Gemfire内存数据网格节点；这意味着这些子系统类似“云”1样， 可以随着业务需求变大或变小，1分为多，任性的漂移到多个不同数据中心来协同合作，避免在IT装备方面的重复投资， 并提高资源的使用率。

云化后的子系统部署在多数据中心，需要特别注意以下两点建议 ：

1. 如果将子系统部署在公有云提供服务时，数据隐私的保护和安全性应为重要斟酌。
2. 如果计划将子系统部署在多数据中心时，在系统框架上必须斟酌上下游子系统之间的数据传输或同步/异步的设计。

以12306为例，两地多中心混合云的架构示意图以下；在春运售票高峰期间可以将余票查询功能部署在多个公有云数据中心提供快速服务（例如阿里云和电信天翼云）。 

两地多中心混合云架构

2、系统改造迁移的思路和需求

随着企业成长，对1个复杂的大系统来讲， 其业务功能不断增加，服务方式多样化，数据存储量愈来愈大，但系统性能愈来愈慢，而用户对响应时间的要求愈来愈严格；特别是在过去5年里，每一年都有新技术的演进 （大数据和散布式内存数据平台）和新业务的衍生（物联网利用，社交利用平台和移动利用）。

当传统架构系统已逐步没法满足日益成长的业务需求时，有两种方案可供选择， 1是从硬件着手，scale up的选项， 就是更换性能更强大的服务器；2是scale out的选项，从软件平台着手， 进行利用系统改造，采取弹性可扩大的框架设计。

更换硬件服务器是最简单的做法， 但以后更换本钱会愈来愈高，系统性能提升是愈来愈有限。 软件利用系统的改造，是1劳永逸从根本做起，改造本钱是与系统的复杂度有关，是需要全面改造？ 还是选择性的局部改造 ？这需要根据实际使用情况来决定。

针对系统的scale out设计，如果要颠覆之前的架构，重建系统，那是个大工程，除非有以下3钟情况：

1. 系统已是千疮百孔， 没法再打补钉也无人后续保护
2. 原本的框架设计已优化到极致，不管如何优化，都已没法满足日趋增加的业务需求。 例如，12306就是典型例子。
3. 业务流程和组织管理方式有巨大的变动， 需要重建系统

否则，最省钱和最有效的方法就是针对系统瓶颈做“局部改造”来提高性能，保护过去的投资。例如，社保项目就是典型例子

在此篇文章，讨论的重点是如何将系统改造迁移到云利用平台， 由于每一个系统都有其特殊性和复杂性的开发背景，其设计的系统框架，所采取的软件平台和开发技术也都随着时间演进而不1样。 因此改造的方式需要根据实际的环境来进行。 

1. 12306 系统改造思路和需求