3.1　迁移项目概述

如果这一切要发生在传统的商业银行，那应该如何应对呢？商业银行的业务系统复杂度很高，并且影响面更广，这套下移动作的难度系数可不低，每个系统都好像带电的老虎摸不得。事实证明，如果不努力改变历史，那就有可能将被历史改变。但这一天终究还是来了，2019年年初，笔者所在的商业银行决定将目前所有在役的小型机下移至x86服务器，当这一举措宣布之时，大家的内心可谓是百味杂陈。

3.1.1　商业汇票系统下移背景与目标

每个商业银行都有自己的应用系统评级体系，笔者所在的商业银行根据系统涉及的交易金额、对外影响及在线用户量等指标，将系统划分为四个等级，由高至低分别为A+、A、B和C类。目前部署在IBM小型机的系统基本都是A+和A类，这些系统的共性是停机时间窗口短，且重要程度高；也有少部分B类系统，该类系统的特点是“体量庞大”，停机时间窗口也很有限。并且这些小型机都存在超期服役风险，其故障率随着服役时间增长而不断增加。根据相关统计，超过5年的小型机，故障率大概增长42%左右；另外，如果系统下移至x86服务器后，硬件采购和维护费都将有一定下降。

结合系统架构的发展趋势，分布式架构已成为大势所趋，这种架构已在互联网行业得到广泛应用，各家商业银行也在研究适合自身业务的分布式系统。特别是近年来，在分布式架构中，各个节点所使用的x86服务器，开始使用本地磁盘（例如性能更好的固态盘）来存放数据。与使用集中式存储的系统相比，这类系统的横向扩展更便捷。因此，在小型机下移中，推荐使用基于本地磁盘的分布式架构。

考虑到运行在这些小型机上的软件版本已经退出厂商产品技术支持周期（End Of Service），存在大量隐患，时刻威胁着生产环境的安全稳定运行，为提升相关系统软件运行的可靠性，利用小型机下移x86服务器的机会，将存在重大风险隐患的操作系统、数据库及中间件进行大版本升级。升级后，从操作系统到数据库，运维复杂度和成本也会随之大幅降低，同时也能实现资源整合，为基础软件的标准化、自动化做好准备，为智能化运维奠定良好基础。

商业汇票系统是一套系统评级为A+的交易系统，该系统主要面向商业银行多个业务部门，用于实现商业银行各项商业汇票业务放款操作与业务管理的信息处理平台。

以上提及的背景问题，在商业汇票系统上体现得淋漓尽致。系统内所有应用程序和数据库都部署在IBM Power小型机上，且服役时间已超限；应用程序与数据库紧耦合在一起，存在资源争用、架构不合理等问题隐患；所有的中间件及数据库产品均已退出厂商产品技术支持周期。

因商业汇票系统在整个项目背景中具有较强代表性，本章将以该系统为例，深入介绍整个系统下移过程。

3.1.2　迁移计划

经过对现有系统梳理，涉及小型机下移的系统均为笔者所在商业银行的重点交易系统，系统可用性要求较高，因此不能出现因小型机下移变更而引起任何生产事件。任何一套系统都不会给试错的机会，这需要做足功课，谋定而后动！谋就是要做好计划，围绕着目标，在具体实施之前，要先计划清楚。

既然首要目标要向x86服务器迁移，先要证明x86服务器有能力代替小型机承载这些应用和数据库。有了理论的支撑，再结合实际测试数据，就可以总结出一套将小型机资源转换为x86服务器资源配置的方法。

项目背景和目标确定后，随即成立了专项工作小组，接下来开始制订“作战计划”。制订详细的计划之前，首先需要分解任务目标。小型机下移x86服务器有以下两个主体目标。

（1）将所有部署在小型机的系统平滑迁移至x86服务器，这是第一个目标。

（2）将所有涉及下移交易系统中的基础软件升级至主推版本，这是第二个目标。

针对第一个目标，计划根据待下移系统的现状，分别对应用程序和数据库进行深入分析，针对不同的场景、不同的系统级别、不同的业务连续性要求、不同的高可用级别，制订出合理的数据“平滑”迁移方案。

针对第二个目标，计划在小型机下移的同时完成相关软件的大版本升级。这需要梳理当前待下移的各系统软件版本，随后根据版本差异、升级策略来制订软件升级方案和测试方案。再根据测试方案进行合理的系统测试，最终才能结合数据迁移方案进行生产环境的实施。

在现代化战争中，给士兵配备各种作战辅助装备，一方面提高了生存率，也同时提升了单兵作战能力。所以，考虑对应用程序部署架构和数据库部署架构进行优化调整，将系统性能和高可用能力发挥到极致。对于每一套待下移的系统都可以通过现有架构分析，形成x86服务器的优化方案。

3.1.3　数据迁移原理

小型机下移项目中，并不是将数据从小型机平台复制至x86服务器就达到系统下移目标，而是需要在一套安全详尽的迁移理论支持下进行。在小型机下移x86服务器的项目中，需要考虑应用和数据库整体迁移。

商业银行的应用程序具有应用及数据架构复杂度高、系统敏感度高、业务连续性要求高等特性。应用程序本身是无状态的，这对迁移来说简单了不少。也就是说，将应用迁移至x86环境后，如果考虑回退，只需要将前端应用请求连接转向原环境即可。只涉及更换应用运行的平台和软件版本，不会变更程序的处理逻辑，所以单纯应用程序的迁移只考虑做适当的黑盒测试即可满足上线条件。

应用程序的迁移并不复杂，但数据库就不同了，在传统的数据库数据迁移方案中，有多种方法可以满足迁移的目的，一般会采用数据导出导入方式和数据库日志复制方式。

（1）基于数据导出导入的方式实现数据迁移。

对于数据传输方法是指在应用停止写入的情况下，将数据从源端数据库全量导出传输至目标环境。随后再进行目标端相关数据对象的初始化，验证应用程序访问数据库后，即可对外提供服务。但方法也存在诸多不足，可能需要花费较长的停机时间窗口，这和数据量有一定关系。对于数据的回退比较复杂，需要提前梳理应用层级的表对象，并手工将目标端的增量数据同步至源端。整个回退的时间也相对较长。

（2）基于数据库日志复制的方式实现数据迁移。

这种方法通常要借助一些数据迁移工具配合完成，如IBM Change Data Capture（CDC）、Oracle Golden Gate（OGG）、IBM Q Replication（Qrep）。IBM CDC和OGG两款软件都是基于数据库日志复制的，也就是需要有程序在源端根据不同数据库的日志API来解析数据库事务日志，随后通过网络传输至目标端进行事务重放。而对于Qrep，它和CDC一样，同属于IBM InfoSphere Data Replication（IIDR）产品系，算是Db2的原生数据迁移工具，功能非常强大。Qrep通过IBM MQ消息中间件作为数据传输媒介，这样在保证消息可靠性的前提下，提升了数据迁移速度。但Qrep在配置管理上过于复杂，所以应用的场景并不多。

关于数据迁移方法的选择和细节的介绍，将在数据库平滑迁移方案中揭晓。

3.1.4　迁移难点分析

在项目启动会上，摆在面前的有以下三大难题。

难题一：如何保证小型机下移x86服务器后系统的性能不低于小型机性能？我们对x86服务器的性能预期是“至少不能低于小型机”。

在小型机下移前，必须找到x86服务器代替小型机的有效配置方案，从而证明经过策略配置的x86服务器足以代替小型机承载相关业务。但很难从公开的数据集中找到一个万能的换算公式，能让我们在小型机下移项目中直接找到资源配比良方。例如，小型机有4核64GB内存，需要买哪种配置的x86服务器才能与其对应，刚好超过性能预期，而又不能过度分配资源，对此，我们决定拿IBM Power小型机与x86服务器进行性能对比测试，找出它们之间的资源配比方案，后续的系统就可以按照这种配比方案选择x86服务器了。3.2节中将揭晓此部分内容。

难题二：数据迁移过程中，如何做到对业务影响最小化？

小型机下移x86服务器还涉及数据的跨平台迁移。数据主要包括两大部分：应用数据的迁移和数据库迁移。其中，应用迁移主要涉及应用程序在新版本中间件的重新安装和部署。而数据库迁移相对复杂一些，需要将数据库内的对象以及数据在有限的时间窗口内传输到新的环境中。3.6节中将揭晓此部分内容。

难题三：待下移的目标系统都部署着许多商业软件产品，如IBM WebSphere Application Server（WAS）、IBM Http Server（IHS）、IBM Message Queue（MQ）、IBM Db2和Oracle等。这种重量级商业软件并没有提供细粒度的软件版本差异项，这样就无法做到针对性的测试，只能依赖传统的地毯式测试方法。根据以往经验，这种测试方法占据了较多时间。

上述三大难题中最让人头疼的就是测试。小型机下移涉及系统架构的调整和基础软件升级，每个环节都需要测试验证。最终，我们打开思路，创造了新的测试方法——高仿真测试方法，在项目实施中将综合运用传统测试方法和高仿真测试方法来达成最终目标。3.5节中将详细介绍。