3.4　基础软件版本升级与架构优化

我们决定在小型机下移x86服务器的同时，将系统中相关的基础软件版本也一并升级至软件版本管理办法中要求的最高版本。例如，待下移的系统涉及IHS、WAS、JDK、MQ和Db2等多种软件产品和开发工具包，待系统下移时，要综合考虑这些基础软件版本升级对应用系统的影响。从变更角度来看，这个决定无非承担着较大风险。项目初期，在整体下移方案中，是否再进行基础软件升级，就成为大家争论的焦点。

基础软件升级后，与应用程序本身是否兼容必然存在某种不确定性。我们是否能有合适的测试方案或一套理论支撑就一定能保证升级和迁移的成功吗？答案是否定的。从历史上经历过的诸多升级案例来看，没有万无一失的方案能100%保证升级后一定不会出问题。因此，从整体系统下移方案来看，许多人赞成拆分方案，分步实施。虽然这样看似将风险降到最低，来解决一次性系统下移和基础软件升级的多点变更带来的不确定性，但实际上也隐藏着诸多不可见的风险点，而这些风险可能直接导致小型机下移整体方案的失败。这些风险点主要有：

（1）项目层面，系统下移与基础软件升级方案拆分后，每套系统面临工作排期压力，很难在计划的时间内完成所有系统的下移工作。

（2）技术层面，主要是系统软件与基础软件的兼容性带来的过渡版本的选择性问题。例如，系统在小型机的基础软件版本较低，下移后操作系统更换为Linux平台后，迫于基础软件版本兼容性要求，软件本身也要随之升级。如果选择过渡的版本，再升级到最终版本的做法略显多余。另外，选择应用程序和数据库分开升级，也会存在新老版本共存，同时维护两套环境的问题，这同样带来不必要的复杂性，同时带来隐患。

经过讨论研究，我们将在小型机下移项目中统筹考虑基础软件升级的方案，将其融合到整体下移方案中，与此同时也解决系统中软件退出服务期（EOS）的问题。对于前面提及的问题，我们并没有采用传统互联网的做法，用灰度发布的方法来进行上线后分流测试，这种方案在某些金融系统场景中并不适合。我们依然采用测试的方式在软件升级前安排专项测试，创新思路在于测试范围大幅度的缩减。这部分主要在软件版本差异性对比的方案中说明。

3.4.1　升级策略

因为小型机下移项目中涉及的系统较多，每个系统架构和软件现状又千差万别，因此，需要从整体下移方案中考虑基础软件升级。为了贯彻和落实我们提出的技术方案，在每套系统小型机下移分析前，都要形成一份专业化的技术评估报告，例如《某系统小型机下移技术分析报告》。在报告中形成有针对性的基础软件升级策略，主要包括应用相关软件升级策略和数据库升级策略两部分内容。

在生产环境下，待下移的系统比重比较大的还是传统的企业级应用架构，经过前期的梳理和汇总分析，我们的生产环境相关软件主要包括Web服务器、中间件、数据库和应用程序，如表3-6所示。

表3-6　应用程序软件分类

1．Web服务器软件升级

主要有两种软件产品，IBM IHS是基于Apache的高性能Web服务器，其版本要求和应用服务器的版本一致，一般升级了中间件也会一同升级IHS，同时也会将Plugin组件一同更新到相同的版本。如果Web服务器暴露在公网，前端是负载均衡进行轮询分发时，这时会选用版本较高的Nginx代替IHS。或在IHS前面再加一层Nginx做反向代理，达到软负载均衡的效果。

2．中间件升级

分为应用中间件和消息中间件，具体如下。

（1）IBM WAS应用中间件。WAS的版本选择V9的大版本，主要也是为了解决软件退出服务期的问题。同时，也考虑升级WAS内置JDK版本至V1.8。根据前面的介绍，在下移的项目中优先沿用原先的软件，所以应用中间件并未选择市面上的开源中间件或其他商用产品。

（2）IBM MQ消息中间件。主要负责系统间数据传输，它与应用程序间兼容性很高，在整体系统测试中通过报文捕获的方式验证消息传递的准确性。

3．数据库软件升级

待下移的系统中，数据库产品使用很单一，全部是IBM Db2。而现有的数据库版本是多样的，最低版本有Db2 V9.1，最高有Db2 V10.5。对此现状，系统下移后，将统一升级至Db2 V11.1.4.5。当时选择这个版本的原因有二：主要考虑到V11.5刚刚出厂，还不稳定；而V11.1.4.5又解决了之前许多程序缺陷，且在读写分离支持上略有提升。

数据库跨平台升级的常用方式有两种：一种是比较简单的数据迁移方案，即将数据导出后，在新环境导入的过程；另一种是通过工具准实时跨平台同步日志数据的方式。这两种方案各有优略，细节将在3.6节来详细描述。

4．应用迁移

主要分为Java应用和C/C++应用，具体如下。

（1）Java应用迁移。

由于JDK目标版本是1.8，在应用代码重新编译后，还需要大量的测试工作。从理论上来讲，JDK升级后，对某些方法不推荐使用，在程序中依然使用这些老方法可能会带来效率问题。我们曾在某套JDK 1.4的应用中找出了比较严重性的方法弃用问题，在JDK 1.8中不再使用这些方法了，这些问题都是在程序测试阶段发现并改造的。

另外，JDK升级后的难点不仅是应用程序本身的兼容性问题，最难解决的是第三方程序组件的适配。例如，报表类jar包或框架类的程序，如Spring、Hibernate等，对于常见的框架，可能官网或社区会公布是否支持JDK 1.8，但大多数边缘组件可能都无从查证，只能通过测试进行验证。所以，我们对于第三方的程序采用的策略主要是先在官网确认兼容性，不确认的通过测试手段辅助确认。

（2）C/C++应用迁移。

待下移的系统中也有一部分是通过C/C++开发的应用程序。因涉及平台的转换（从AIX到x86），应用必须要做重新编译。小型机下移后的操作系统采用红帽Linux 7.7版本，对此类应用先找到源码用新版Linux平台下的GCC编译器进行重新编译。考虑到程序员的开发水平良莠不齐，在开发的过程中对程序的兼容性和健壮性考虑不足，更换环境后极易出现如内存越界或访问地址错误等问题，所以需要通过一些辅助工具进行验证。

3.4.2　不同版本差异性对比

商业银行业务系统的复杂度超过很多人的想象，系统间的调用和级联关系错综复杂。软件升级必经之路就是全量测试，通过全量交易码的梳理和后续的全回归测试，最终才能上线。迫于软件版本管理要求，亟待找到一套完善的工作机制来应对后续软件的升级常态化。

要想改变现状，墨守成规是不可取的，必须利用科学的方法来改善这种“地毯式”测试方案带来的测试周期长和资源消耗大的问题。我们分析了以往的测试方案，结合各专业方向的专家建议，梳理了同业软件升级时遇到的问题和相关软件厂商公布的软件版本差异，总结出一套辅助测试的方法，主要目的在于缩减后续系统测试的范围。随之测试案例也会缩减，那么将会节省一部分软件的测试时间和资源消耗。这种辅助测试方法叫作“软件版本升级差异化分析”，分析结论主要基于软件版本差异库。基础软件升级带来的变化后对应用程序的影响是未知的，我们往往期望测试越全面越好。那么，如果已知这些软件的变化项，也就是软件升级前后的差异，只针对应用所调用软件变化部分的功能即可发现软件升级后给整个系统带来的影响和变化。

1．Web服务器、中间件等版本差异

这些软件产品与应用程序本身代码的耦合性不强，只负责交易请求的转发、负载均衡、消息传递等。因此，Web服务器、消息中间件、编译器等软件升级，根据规范配置相关参数后，结合系统完成普通功能测试即可。

2．应用升级版本差异

对于Java程序，按照如上逻辑，需要找出JDK 1.5与JDK 1.8的具体差异，如果真能从API层面整理出差异，那可能是非常厚的一本手册，但缺乏实用性。所以，只能从各项目组在以往升级项目中积累的实战经验发布到软件差异库中，这样也可以应用到其他相关软件升级项目中去。

对于应用程序升级JDK，最难的并不是应用程序本身的调整，因为我们掌握这些源代码，很清楚版本变更后做出相应的调整。而对于第三方插件或框架的升级是重点，针对升级JDK带来的差异，只能采用官方确认结合通过性测试的方法来验证。

涉及C/C++程序的编译器，由于操作系统的平台更换，由原来的Xlc更换为GCC，对于C/C++程序第一步要做的就是先要通过GCC的编译。那些在开发初期不考虑兼容性、鲁棒性的程序将会在编译中暴露出大量问题，这就需要根据之前总结出来的软件差异库中的专家建议来调整相关程序，并最终完成测试目标。

3．数据库版本升级差异化对比策略

在应用程序代码逻辑不变的情况下，对于数据库的影响冲击较小，主要包含以下两方面考虑。

第一，是新版本数据库带来的新老功能的兼容性，而这部分变动主要由原厂发布前的大量相关产品级测试，无须再投入更多的精力，只需要针对应用程序使用到的差异部分进行测试即可。

第二，涉及应用与数据库交互的SQL语句执行计划发生变化。因为数据库版本升级后带来统计信息的变化，从而影响数据库优化器的最终判断，造成SQL语句的运行时长无法达到预期。这就无法通过软件版本差异化分析来提前预估影响的交易场景，即使将统计信息更新到最新，SQL的执行效率也有可能与之前版本不同。

如图3-2所示，我们梳理了所有待下移待升级的数据库产品，总结出适合现有软件升级场景的数据库版本差异库，主要由以下三部分构成。

第一部分由原厂提供的软件版本差异和已知升级后的版本问题构成。

第二部分由专家建议构成，这部分信息是历史以来数据库版本升级的问题与经验总结。

第三部分是同业的相关升级案例与知识分享。

图3-2　软件版本差异库

基于软件差异库的“软件版本升级差异化分析”是一种辅助手段，它存在的目的是对传统测试进行有效的补充，尽量避免“大水漫灌”式的测试方法，针对存在差异的软件功能项所对应的交易码进行针对性的测试，从而有效降低测试成本。

3.4.3　软件架构优化

软件层面，应分别从应用程序、数据库、网络等方面进行优化评估，目的也是在完成系统下移的同时，将下移后的系统性能发挥至极致。下面就介绍在系统下移过程中在软件上的优化方案。

1．应用层优化方案

除了应用层相关软件升级以外，考虑分别对Web层、应用服务器、数据缓冲层进行了不同程度的优化。

首先，将Web层物理机资源转换为虚拟机（后称P2V资源转换），这样既便于服务器资源管理又能有效提高Web可靠性。为进一步提升系统高可用能力，对重要的交易系统增加硬负载（如F5）或软负载均衡器。

其次，对业务压力较大的应用服务器集群进行纵向扩容（Scale-up）或横向扩容（Scale-out），并优化相关参数。目的是为提高应用集群可用性，并进行压力分摊。

最后，还有一些特殊应用场景的优化，为并发压力大或存在“抢购”类业务的交易系统，在中间件层和数据库层之间增加缓冲层。事实证明，这些应用缓冲层在提供更好的客户访问需求的同时，大大缓解了后端数据库层的压力。

2．数据库层优化方案

据统计，涉及小型机下移的数据库系统均为IBM Db2，不考虑下移至其他的数据库产品，也不涉及国产化的改造方案。

针对集中式数据库的优化方案，将首选Db2高可用容灾功能（HADR）提高单节点高可用能力。针对A+类系统，考虑应采用一主三备的数据库级高可用方案，实现两地三中心的高可用部署架构。针对A或部分B类系统，可搭建一主两备的数据库级高可用方案，实现同城容灾。

多节点并行处理架构（后称DPF）的优化方案，根据业务与数据量增长趋势，针对单分区数据量达到TB级别，且应用主要进行大数据量加工、流转、清洗等动作的在线分析类业务（OLAP）。为了充分利用每台x86服务器的计算资源，考虑将数据库架构转换为多分区（MPP Share Nothing）模式。

数据库读写分离场景用于解决“读”的压力，主要针对在线事务类业务（OLTP）。例如，在性能压力测试环境中，单节点数据库无法应对高并发读操作时，可以考虑将读业务（或部分读业务）分摊到更多数据库备机上，这样将有效地缓解主库压力。

对于数据基础体量大，且读写压力都非常高，尤其针对在线事务类业务（OLTP）短事务写的压力，如果性能压力测试数据无法达到预期，将考虑采用自研的分布式数据库进行分库分表的拆分优化。

3．网络层优化方案

小型机下移x86服务器的项目中，涉及系统网络层面的优化主要涉及智能DNS和网络安全性方面的改造。

智能DNS改造方面主要从应用和数据库两个层级部署实现。应用层建设DNS主要为了实现双活应用调度，在同城机房配置应用服务器集群实现应用双活。数据库层的DNS改造主要用于结合当前数据库主流的高可用架构进行平滑服务切换，提高高可用性的同时，配合实现系统自动化切换。

网络安全性方面的改造主要涉及应用前端反向代理的更换。部分商业银行安全规范中规定了Web服务器禁止使用Root账户配置启动的要求。另外，传统的80端口也需要进行相应的调整。基于安全规范的发布，从技术层面建议将暴露在公网的DMZ的Web服务器统一调整为Nginx。

3.4.4　商业汇票系统软件升级和架构优化结果

根据基础软件的升级策略，商业汇票系统最终评估结果如表3-7所示。

表3-7　商业汇票系统软件升级列表

从表3-7可以看出，除了第三方开发框架的依赖包版本未升级以外，我们的目标是将商业汇票系统内部的所有基础软件升级到当前（2020年）最高版本。

1．软件升级评估结果

在这里比较大的风险点是对JDK的升级，主要体现在以下两个方面。

（1）源代码兼容性存在问题。通过JDK 1.8编译，先后发现程序转码问题、FTPClient实例化等问题，需要进一步调整代码，并将其总结编入软件差异库中。

（2）对第三方框架和第三方jar包的影响。我们需要花费大量的时间和精力反复确认相关程序jar包与JDK的兼容性。这也将作为测试环节的重点测试场景。

另外，配置新版本应用消息中间件时，只遇到常见的MQ 2035异常，需要单独关闭通道权限。

runmqsc <qmname>
alter qmgr chlauth(disabled)
alter qmgr connauth('')
end

数据库方面，在升级评估过程中，根据总结的软件版本差异库进行应用代码梳理，均未发现问题，剩下的工作就可以顺利进入测试阶段了。

应用服务器方面，由于进行了横向扩容，所以需要重新调整Web服务器、Web容器、JDBC连接池等相关参数。

2．架构优化结果

架构方面，为了避免资源争用，将应用服务器从数据库服务器迁出。另外，考虑到未来3年的业务增势，TPS峰值预计增加20%。参考应用程序服务器性能测试结论，单台应用压力较大。为能更好地向客户提供优质服务，计划将4个服务器横向扩容至6个，分别部署在3台虚拟机中。

数据库方面，从主备加存储复制的架构，优化为Db2 HADR一主三备，两地三中心架构，并使用本地盘替换共享存储。

消息中间件方面，将原有的单节点MQ优化为集群部署架构。

网络方面，应用服务器前端已经改造为智能DNS，实现同城平滑切换，本次下移将数据库层也改造为智能DNS。