某银行核心系统基于浪潮 K1 Power 架构的升级改造实践

【导读】本文以某银行核心业务系统升级建设项目为背景，根据该银行近十年以来银行业业务发展的功能与非功能需求，建立短期以及中长期的核心业务系统建设目标，详尽设计核心业务系统业务逻辑、基础架构、容灾架构和浪潮K1 Power服务器选型配置、性能测试、架构方案设计等多阶段、多维度项目实施和运维管理经验，为同业核心系统升级建设提供可参考、可操作的真实案例和宝贵经验。

【作者】zihan，某城商行系统工程师，负责行内小型机、存储、基础监控、存储容灾等日常维护，有多年的实施、运维和规划经验。

一、项目背景

在银行的整个IT蓝图中，核心业务系统是负责处理和管理核心银行产品的生产系统。所谓的"核心"银行产品，就业务而言，是指银行主营业务中向客户提供存款、贷款、中间业务等产品和相关的服务。在一定程度上，核心业务系统是一个商业银行日常运作的基础，核心业务系统的先进程度对整个银行的运作有着至关重要的影响，一套专业化的核心业务系统在优化业务流程、提高生产效率和盈利能力方面的重要性越来越被银行高管层所重视。传统核心业务系统对银行业务变化发展的适应性问题越来越浮上台来，以至于逐渐失势，随着业务的快速发展和银行业加速转型，需要对现有的IT系统架构、业务体系进行重构和优化，打造运行高效、长期可用、满足专业化经营要求的新一代核心业务系统，相关技术面对的挑战主要表现在以下几个方面：一是移动互联网时代的业务快速增长；二是利率市场化的业务产品创新加速；三是业务连续性要求日趋苛刻。通过银行新一代核心业务系统升级建设，从整体架构、系统功能、产品功能、数据支持和技术创新等各方面实现核心系统全方位能力的提升，逐步实现银行数字化，为对接“植入式”银行 4.0 夯实基础，进一步满足未来金融市场的需要。

二、需求分析

我行的核心业务系统于2006年投产上线，自上线以来，运行稳定，为我行业务发展提供了有力的支撑，随我行业务的快速发展，原有的核心系统受到传统系统架构的限制，以客户为中心的设计程度较弱，参数化和产品组件化程度不高，在客户体验、产品创新、差异化定价、参数管理方面的需求响应程度较弱，整体开发实施费时费力，周期过长，不能快速响应业务部门的需求，对未来银行的业务发展支撑能力不足，为使我行更好地开展业务，需重建新一代核心业务系统，新一代核心业务系统将实现“以客户为中心”的经营理念，实现产品模型化、风险管理体系化、配置管理参数化、数据标准化、定价灵活化、账户体系化等以及支持高性能高扩展，我行于2018年启动了新一代核心业务系统建设，目标包含如下内容：定义新建核心业务系统在全行级总体IT系统架构中的位置和重要性，满足新建核心业务系统对于丰富业务开展的需求；系统功能较灵活，产品参数化程度较高，可快速支持业务发展；通过模块化、组件化、参数化设计原则，便于以较低的再投入扩充新的业务功能，同时不影响系统的原有功能；满足自主、安全可控的监管需求；吸收互联网架构的优点，具备分布式横向扩展能力，支持高并发亿级账户；支持7*24小时服务，系统批量窗口时间短；支持产品核算分离；实现核心业务系统数据读写分离；符合业界安全标准，支持多级安全、保密、权限控管机制，确保业务数据的准确性、完整性、一致性和安全性。

三、建设目标

本次核心业务系统升级改造目标是搭建一套行业内先进主流、稳定、安全、可靠的核心业务系统，满足新建核心业务系统对于丰富业务开展的需求，通过模块化、组件化、参数化设计原则，便于以较低的再投入扩充新的业务功能，同时不影响系统的原有功能；在非功能性需求方面，满足自主、安全可控的监管需求；吸收互联网架构的优点，具备分布式横向扩展能力，支持高并发亿级账户，最后为银行数字化转型成功奠定基础。

四、技术选型

我行新一代核心业务系统数据库软件采用Oracle 12C，对于此种集中式数据库服务器选型，考虑的最重要的因素是单机处理能力、响应时间及稳定性等。

1、服务器型号的选择

我行进行新一代核心数据库服务器选型时正是浪潮K1 Power 系列服务器Power8和Power9并存的阶段，主要型号有浪潮K1 Power E980、E950、S924、S922、E880、E850、S824、S822等几种型号，其中E850、E950及以上为高端机型，在扩展性、稳定性、可靠性上比其他中低端机型会更甚一筹，根据我行实际情况，综合价格、稳定性、可靠性等因素，本次项目考虑选择浪潮K1 Power S924，但我行对S924是否能满足核心业务系统TPS 2500+的要求存在顾虑，于是我们采用与原核心系统一样配置，即24 core的S824机器来测试新核心系统TPS，发现可以达到2800+。最终我们选择了浪潮K1 Power S924作为主服务器，S922作为读写分离和灾备服务器。

2、服务器CPU数量的选择

浪潮K1 Power S924 CPU有多种型号，有8核、10核、11核、12核。

从图中可以看出，20core的S924比24core的S824在SMT4模式下性能要高一点，但在SMT8模式下，20core的S924比24core的S824性能要高出30%左右，所以我们选择了20C的S924。

3、操作系统和数据库版本选择

操作系统、数据库等基础软件的选择应该遵循“行业主流，安全稳定”的原则，我们选择了AIX 7.1 TL5 SP3和Oracle 12C的稳定版本及最新的补丁。

五、性能测试

我们对核心系统进行了多轮性能测试，在购买正式生产机器前，进行性能测试，目的是为机型选择提供依据，生产机型选定后，对到货的正式生产设备进行性能测试，主要目的是对生产系统进行不断优化，发现隐藏的问题。机型选择性能测试使用S824和S822小型机，生产设备性能测试使用S924和S922小型机，其他保持不变。

测试环境配置基本与生产配置保持一致，我们配置了4台压测机，运行Loadrunner环境;6台24C、128G应用服务器外加F5环境，2台浪潮K1 Power数据库服务器，2台浪潮K1 Power数据库只读服务器；账户数据4000万，选取的交易包含10支最常见的交易，并按照实际最常见交易场景分配读写比例，保证性能测试案例与实际交易场景的匹配性，测试结果如下：

（1）S924和S922性能测试场景下，比S824和S822场景TPS高出50%以上，应该是Power9充分发挥出SMT8多线程优势的结果。

（2）机器的性能和官网的rPerf值是正相关的。

当使用S824数据库做测试时，系统TPS随着并发用户数的增加，系统处理能力呈线性增加，并发用户由207逐渐增加至352时，系统处理能力由1954笔/秒逐渐上升至3009笔/秒，当并发用户数352增加到531时，系统处理能力已趋近于平稳，无明显上升趋势。系统最大处理能力3016笔/秒，下图为不同用户数情况下TPS增长情况和高峰时段CPU资源利用率情况。

当使用S924数据库做测试时，在613用户并发下，系统处理能力达到4800TPS左右，读写主数据库CPU使用率70%左右，同样的数据库CPU使用率，系统处理能力提高了50%以上。读写应用服务器CPU使用64%左右，只读应用服务器CPU使用55%左右。

六、架构方案设计

1、面向SOA的技术架构

系统设置为通讯层、业务流程执行控制层、内部总线层、业务组件/服务层、数据库访问层以及作为整体技术支撑的技术平台（如下图所示）。核心系统各层之间通过标准的接口连接，实现各层之间的相对独立性，其中一层的改变不会影响到与它联接的其它层，保证系统的稳定性和可扩展性。

通讯层负责核心系统与外围系统、渠道、终端的连接，主要包括负责通讯协议的处理、负责数据的拆包和组包等功能；

内部总线层负责模块间访问接口的发布；业务流程执行配置层负责将外部服务请求转换成核心系统内部的交易、转发核心系统对外部的服务请求、基于服务的业务流程组合等功能；业务组件/服务层负责业务逻辑的处理。业务处理被封装为基本业务组件，再按具体业务处理规则进行组装成为可被调用的业务服务。一些公共函数处理、控制处理被封装成为技术组件，可被其它各类组件所调用。核心系统基于组件的设计，从根本上保证了业务功能的稳定性和可扩展性，并且易于组合使用，使业务的变化能够快速地得以实施，能够应对激烈的市场竞争；数据访问层在核心系统中负责对业务数据和系统参数的访问，其隔离了系统业务处理部分和具体的数据存储，使业务处理不用关心物理存储方式。数据访问层同时还在一定程度上降低数据结构变化对业务处理部分的影响；技术平台提供核心系统运行所需的基础设施和处理机制，包括系统开发、运行以及操作的一系列标准、工具和公共函数，和具体的业务处理无关，但又是业务运行的基础，技术平台将这些功能封装为技术组件供业务组件进行调用，其主要作用在于使业务处理无需考虑具体的技术处理和控制的细节。技术平台无论从功能还是数据的设计上都是和业务处理部分相对隔离的，其修改和扩充不会影响到业务处理部分。

2、核心业务系统物理部署架构

核心业务系统数据库采用4台浪潮K1 Power，安装Oracle 12C，组成两套Oracle RAC，每套RAC使用Oracle ADG技术，实现核心业务系统的读写分离；NAS共享存储作为文件服务器，用于存放核心系统与外围系统交互的文件。

3、核心业务系统容灾架构

新核心业务系统数据部署整体架构

我行核心业务系统应用采用Vmware SRM+VR进行容灾，数据库采用两台浪潮K1 Power S924，使用Oracle RAC技术实现高可用，同城和异地灾备中心分别采用两台浪潮K1 Power S922作为灾备服务器，也使用Oracle RAC；核心系统数据库容灾采用环形3DC存储复制和Oracle ADG方案，并使用备份技术实现数据逻辑保护，其中备份软件每天晚上对核心数据进行全备备份，数据库日志每30分钟备份一次。

4、核心业务系统软硬件资源配置

为确保新核心业务系统基础架构资源方面能够满足功能要求、性能需求、数据标准要求以及稳定、可靠、安全等非功能性要求，核心数据库和只读库完全采用LPAR方式（DLPAR-enabled）进行部署（黄色部分），详细如下所示：

七、项目经验分享

1、小型机选型配置

经过前期性能测试和近一年的生产运行表明，在运行Oracle数据库的情况下，同样核数的浪潮K1 Power服务器，POWER9系列CPU的处理能力是POWER8系列的至少1.5倍，对于追求性价比的中小城商行来说，虽然性能提升，但是总体拥有成本较低。

2、高可用配置和测试

高可用的最终目的是保障业务连续运营，因此要从整体上考虑高可用配置，对于核心系统的每一个环节都需要考虑到，并通过实际业务场景验证核心系统的高可用性。在应用层面，通过部署多节点应用，利用F5实现负载均衡和故障转移；在数据库层面，采用Oracle RAC和Oracle ADG外加统一的服务名实现核心数据库的无缝切换；数据库存储层面，建议采用本地存储双活，将数据放在两台存储上，避免存储单点故障；在硬件设备层面，采用双网卡、双硬盘、双交换机、双路由、双线路等；在多系统交互层面，统一通过F5虚地址与ESB进行交互。

有一点需要注意的是，从Power8开始，内置硬盘默认采用RAID卡管理，出厂就将每块内置硬盘默认做成了RAID0，这样在多台主机装机的时候无法进行克隆，另外RAID如果坏了，有可能硬盘信息就丢失，建议操作系统层面rootvg做mirror的时候，将hdisk分布在两块RAID卡上，避免RAID卡的单点故障。

3、CPU线程数

POWER9默认是开启了SMT8，根据实测，POWER9比POWER8在同等CPU核数情况下，至少高出50%，有部分原因是因为Oracle数据库使用了SMT8线程，建议保留SMT8线程设置。

4、虚拟机CPU资源争用

在进行性能测试时，2台应用程序虚拟机部署在同一台宿主机上，在高并发情况下存在虚拟机CPU争用，即使从操作系统层面看CPU利用率正常，这种情况下需要注意，可以从vCenter上观察宿主机CPU使用情况，并将虚拟机分布在不同的物理机上。

5、存储设备选型

随着业务不断发展，对核心系统性能要求不断提高，原有的机械硬盘存储阵列可能存在瓶颈，主要表现在大量交易下的随机IO访问，建议核心业务系统选择高端全闪存阵列，满足核心系统稳定和高性能需求。

6、系统监控

对于系统监控，我行采用Zabbix监控主机等基础资源，包括操作系统、数据库、中间件等，针对浪潮K1 Power系列服务器，除了通用的基础监控外，还需要监控硬件、磁盘路径状态等，目前我行通过自定义脚本采集AIX errpt日志、HMC event、lspath日志及各种多路径软件磁盘路径状态；另外，为满足故障排查需求，建议在主机上部署Nmon采集，推荐一款Nmon文件解析工具NMONVisualizer，可以批量解析，比Excel使用方便。

7、小型机批量信息采集

对于拥有大批量浪潮K1 Power系列小型机的情况下，信息采集、配置管理成了比较复杂的事情，手工采集比较费时，可以通过自动化工具采集AIX信息，通过HMC采集小型机信息，推荐一款小工具hmcScanner，通过HMC采集小型机信息，方便做配置管理。

八、效果总结

目前，我行核心业务系统已连续运行一年，无任何计划外数据库主机停机故障发生，通过持续不断的监控及维护，可以看到，浪潮K1 Power 硬件平台的安全、稳定、可靠性是其它硬件平台无法比拟的，核心业务系统作为全行最为关键的信息系统，在硬件选型上一定要本着“安全稳定”的原则。这样才能保障核心系统持续运行，提高业务连续性。