某银行核心系统架构升级改造

我行新一代核心业务系统数据库软件采用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采集小型机信息，方便做配置管理。