·2020-10-26 13:42

基础架构组长·西部某城商银行

某银行基于浪潮K1 Power架构设计实现分布式核心系统的实践

字数 7382阅读 5341评论 4赞 10

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

## 一、项目背景
核心业务系统建设是银行信息化建设的核心部分，是银行业运营的基础。当前，核心业务系统的功能与定位已经从"综合业务系统"向稳定、专业、灵活、核心等定位发生转变。核心业务系统在银行业务体系中处于重要核心地位，是数字银行时代不可或缺的关键支撑。当前银行已经迈入以智能方式提供无感知便捷服务的BANK4.0时代，银行业金融机构服务将会通过各种方式出现在人类周围，随着数字化技术的普及，个人银行账户可能来自技术公司的各类智能终端设备，而非来自实体银行。这种银行改变方式带来的挑战不但来自传统银行业内部，也有来自于金融市场上的技术公司。新的时代要求银行前中后台都要做出改变、所有业务与技术需要重构、经营模式需要转变。数字化水平的提升，有助于银行业弯道超车、实现跨越式发展。然而，当领先银行已经在享受数字化红利，大部分中小银行生存空间并不乐观。中小银行要想借助数字化实现错位竞争，不是一蹴而就的。“银行数字化，不是在所谓传统业务之外另建一套数字业务，应该是所有业务的数字化”。一家真正意义上的数字银行包含三大层次：一是底层基础数据平台；二是中间核心业务层；三是顶层的经营决策层，做到智慧经营才是数字化的顶点。

通过核心业务系统升级建设，从整体架构、系统功能、产品功能、数据支持和技术创新等各方面实现核心系统全方位能力的提升，逐步实现银行数字化，为对接“植入式”银行 4.0 夯实基础，进一步满足未来金融市场的需要。

## 二、项目需求
我行的核心银行业务系统于2003年初投产上线，有效的支撑了该行各类业务发展16余年，随着时间的推移及业务模式的快速发展，原有的核心业务系统受到传统系统架构的制约限制，“以客户为中心”的设计程度较弱，参数化和产品组件化程度不高，在客户体验、产品创新、差异化定价、参数管理方面的需求响应程度较弱。整体开发实施费时费力，周期过长，不能快速响应业务部门的需求，对未来银行的业务发展支撑能力不足，已经无法适应当前BANK 4.0时代的快速业务变化。核心业务系统需要实现高度业务规则化、产品参数化、技术组件化、数据标准化的信息系统，以便能够更高效、更敏捷、更安全地响应业务创新发展的要求。

核心系统支持分层、松耦合、面向服务的SOA架构，以适应 IT 系统、服务、产品、流程变化的能力；平台需满足可靠性、可维护性、可移植性、高可用性、系统稽核性、安全性、开放性、扩展性等非功能性需求；系统性能需求主要包括：对集群的支持、文件传输方式的要求、多节点应用部署能力、批量控制、接口性能、并发度控制、数据库几个方面。数据标准要求：符合我行数据标准需求，实施的设计方案要符合我行数据标准，数据架构及数据模型应符合我行相关 IT 规范及数据标准的要求。核心系统软件还具备高稳定性、高可靠性、高安全性、高性能等非功能性要求。在技术能力上需要满足以下特征：支持分布式集群部署、灵活的架构设计、组件化的应用、7*24小时不间断服务能力、数据安全管理、快捷高效的二次开发、详尽的产品文档支持、全面的7*24小时运维监控等。

## 三、建设目标
本次我行新核心业务系统升级建设的目标为：
（一）新建设一套行业内先进主流、安全稳定的核心银行系统。实现信息技术应用和业务发展的双支撑，促进数字化金融应用能力和服务水平迈上新台阶，为银行助力实体经济发展提供有力IT技术支撑，增强和优化运营基础、服务能力、产品工具、风险防控、创新引擎等多领域支撑能力。
（二）实现“以客户为中心，以产品为导向”的服务发展模式。构建统一客户视图、绿色生态的账户管理体系、快速多元化的产品定制、7×24小时不间断的运营服务、严密合规的内控风控管理，从“以账户为中心”的运营模式，向“以客户为中心”的模式转变，为广大客户提供更好、更快、更优的服务体验。

## 四、软硬件选型思路及经验
核心业务系统作为银行最关键的联机事务型(OLTP)系统，在服务器硬件选型阶段建议采用TPC组织的TPC-C型标准。
操作系统、数据库、中间件等基础软件的选择应该遵循“行业主流、安全稳定”的原则，同时，兼顾与硬件设备的兼容性，并充分结合银保监会信息科技基础软件缺陷列表做好版本的规划及相关补丁的更新工作。

## 五、方案规划设计经验
## （一）核心业务系统应用情况
新核心业务系统在应用部分采用zookeeper作为服务注册中心，内部通过微服务架构实现应用的分布式。

![ ▲分布式服务运行图 ](/home/attachment/202010/26/377659_160369040480680.png)
对外提供统一的通讯接入网关，内部使用分布式微服务串接整个业务流程，提供服务路由、负载均衡、集群容错、流量控制等进行内部微服务的调度，在应用层面实现去中心化的分布式架构。在部署方式上，系统内部按照交易与核算分离的设计思想，拆分成交易与核算两个独立的模块，两个模块独立部署。

核心系统的各类应用以分布式集群多节点冗余架构部署于x86架构的虚拟化中，操作系统本版本为RedHat 7.4，各类应用程序未使用单独的中间件产品，而是采用典型的基于Zookeeper、Apache Dubbo等分布式框架软件实现分布式部署。架构设计从核心系统各类服务注册、发布、消费，到应用多活联机服务，再到数据库高可用角度出发，既能满足上层核心与外围系统的业务访问连续性需求，又能保障核心系统自身健壮健全的高可用需求。

核心业务系统应用对外提供服务采用8节点多活模式，8节点中任意节点都可独立提供全部的核心联机服务。ESB （企业服务总线）与核心系统应用通过Zookeeper服务注册、发现等方式进行连接通讯，ESB又将自身的服务发布在Zookeeper服务注册中心，外围系统通过自身操作系统中安装的ESB Agent软件代理采用Round Robbin轮询算法将外部的访问请求均衡的分布到各个ESB 节点，最终均衡的访问到核心应用的8个节点中。一旦某一核心应用节点出现问题，通过Zookeeper服务注册中心探测机制关闭对应的ESB节点通路即可，不影响其他节点提供对外服务。

## （二）核心业务系统应用服务调用方式
核心系统对外提供服务方式主要分为 2 种，第一种是间接访问方式：通过ESB（企业服务总线）进行间接调用访问，网上银行、手机银行等外围系统访问发布在 ESB（企业服务总线）的核心业务系统应用服务。第二种直接访问方式：柜面系统、ESB直接访问核心业务系统应用服务。

第一种方式ESB通过发布通用的Web Services接口，减少外围的报文格式转换，提高了外围系统的改造工作量，提高了外围系统的接口调用的稳定率。

采用第二种方法的系统属于调用接口较为复杂或与核心系统报文接口相似的系统，这类系统一般不适合通过ESB 进行间接调用。

## （三）核心业务系统数据库情况
在部署方式上，系统内部按照交易与核算分离的设计思想，拆分成交易与核算两个独立的模块，两个模块独立部署。在数据库层面进行了垂直拆分将交易库与核算库拆分成两个独立的数据库，实现了数据层面的分布式。

新核心业务系统按照产品功能分为“交易模块、核算模块、通讯网关模块、报表模块、运行监控模块、参数管理模块”，按照数据不同特性将核心业务数据划分为5个数据库。

核心系统的数据库采用Oracle 19.6，根据用途，具体划分为5个数据库：“交易库”、“核算库”、“T+0报表库”、“OM参数库”及“OMS运维监控管理库”。“交易库”承载全部业务交易数据；“核算库”承载每天日库批处理过程中发生的交易数据，当批处理完成后“核算库”中数据再归集至“核算库”，“T+0报表库”承载各类交易报表展示汇总数据，“OM参数库”承载所有的核心关键通用参数配置数据，“OMS运维监控管理库”承载核心业务系统的运行监控及版本变更等各类监控管理数据。

交易模块、核算模块及T+0报表模块等重要的数据库都部署在成熟、稳定的浪潮K1 Power9系列小型机上，操作系统版本为AIX 7.2，数据库版本为Oracle 19c（19.6）。

核心系统的5个数据库都全部通过HDS GAD底层存储双活技术进行数据库的第一层保护，通过数据库的Oracle RAC集群技术实现数据库的第二层保护，通过数据库的Oracle ADG复制技术进行数据库的第三层保护，Oracle ADG复制技术将生产库的数据实时复制到灾备端目标数据库，形成生产数据库的只读库, 只读库可以承载一部分查询业务，并且当生产库发生故障时，也可以将只读库快速切换至可读可写状态，起到生产库实时灾难备份的作用。

## （四）核心业务系统逻辑架构
随着自有新核心业务系统及新数据中心的建成，生产数据中心、同城容灾数据中心以及异地容灾数据中心均发生变化，同城双中心采用“应用分布式双活、数据库主备”的方式进行部署，在合理利用灾备服务资源的情况下最大化的保障了数据的一致性。新一代核心系统项目在新数据中心投入必要主机、存储与网络资源，确保新一代核心系统基础架构资源方面能够满足功能要求、性能需求、数据标准要求以及稳定、可靠、安全等非功能性要求，选择由浪潮K1 Power系列小型机承载重要应用（包含：实时交易应用、核算应用、T+0报表应用）和核心数据库（包含：交易数据库、核算数据库、T+0报表数据库），下图是同城双中心架构下的核心业务系统整体的逻辑架构图，采用浪潮K1 Power系列小型机及PC服务器实现集成部署：
![](/home/attachment/202010/26/377659_160369054948613.png)

同城双中心分别部署两套分布式核心应用，例如：主中心部署5个接入网关、8个核心交易模块节点、4个核心核算节点、2个T+0报表、2个T+0展现端、1套zookeeper注册中心集群、1套redis集群作为分布式缓存；同城中心部署5个接入网关、8个核心交易模块节点、4个核心核算节点、2个T+0报表、2个T+0展现端、1套zookeeper注册中心集群、1套redis集群作为分布式缓存。所有节点单中心内部通过集群的方式实现本地高可用，T+0报表服务对外通过硬件负载均衡设备对外提供服务。

## （五）核心业务系统软硬件资源配置

为确保新一代核心业务系统基础架构资源方面能够满足功能要求、性能需求、数据标准要求以及稳定、可靠、安全等非功能性要求，选择由浪潮K1 Power系列小型机（主要为E950、S924）承载重要应用（包含：实时交易应用、核算应用、T+0报表应用）和核心数据库（包含：交易数据库、核算数据库、T+0报表数据库），完全采用Dlpar逻辑分区技术实现部署，详细如下所示：
![](/home/attachment/202010/26/377659_160369064497306.png)
![](/home/attachment/202010/26/377659_160369066618082.png)
 
文件系统规划，严格按照《XX银行AIX操作系统安装配置规范》要求，统一模板克隆方式进行部署，主要包括：rootvg中各系统文件系统大小、SAN存储VG类型、PP size 和Concurrent属性，LV大小、属组关系，文件系统大小与访问权限，网络存储本地与远程挂载点，自启动配置等。

存储容量配置规划，按照满足未来3年数据增长需求，将存量与增量数据统筹考虑。

## 六、实施经验分享

## （一）高可用性测试
高可用性测试是核心业务系统未来能否安全平稳运行的重要保障，是系统正式上线运行前不可或缺的一项测试工作，是保障业务连续性的一项重要举措，测试目的是配合前端应用压力测试的场景，连带应用负载均衡共同测试，模拟系统上线后的实际压力情况，并通过对单台物理主机的电源、网络线路、光纤线路、操作系统的非计划内关闭与断开，观测对业务连续性的实际影响，判断计划内和非计划内宕机各种异常引发的业务影响情况。配置操作系统层面高可用软件（PowerHA、VMware HA），数据库层面的高可用技术（Oracle RAC及ADG），存储层面的高可用技术（HDS GAD双活），防患设备故障与逻辑故障对生产系统造成不良影响。

核心系统的高可用性测试场景包含架构中的各功能主机数据库和应用服务器，如联机交易应用8节点之间的高可用、联机交易2节点RAC数据库高可用、核算应用4节点之间的高可用、核算数据库2节点RAC数据库高可用等场景的 故障切换过程，验证其中一个节点或一部分节点发生故障后其余正常节点是否能够持续提供服务，记录自动切换及应用时间、交易响应率恢复时间等。

对交易数据库、交易应用、核算数据库、核算应用、T+0报表数据库、T+0报表应用的高可用冗余环节均做高可用性测试完成后，在硬件冗余架构、RAC集群软件、应用负载和分布式的作用下，各系统均通过高可用性测试，且业务连续性未受到任何影响（业务未发生中断情况）。

因核心业务系统的3套关键数据库都采用RAC集群模式部署，当其中一个主机发生宕机情况，另外一个节点会持续提供服务，但从LoadRunner工具界面中会反映出现短时间的交易响应率下降情况。测试过程中，发现当应用程序数据源配置了后端RAC数据库的VIP地址后，当一台主机故障后会导致一部分交易一直失败，原因为“主机故障后VIP地址虽然漂移至另外一台主机，但是该VIP不会启动监听”，故前端应用程序在配置数据源时，必须配置RAC数据库的SCAN IP而非VIP（若使用域名，则域名必须解析至SCAN IP）。具备DNS解析条件的情况下，一定要按照Oracle官方强烈推荐，使用DNS域名实现对RAC数据库的访问。此外，核算数据库承担夜间批量，在配置JDBC数据源时，需要将数据库连接字符串配置为“LOAD_BALANCE=OFF，FAILOVER=ON”，即：关闭数据库负载均衡模式，将RAC数据库工作模式配置为热备模式，否则在数据库负载均衡模式下，夜间批量产生大量的SQL执行导致两个数据库节点间频繁的内存交互会导致GC等待，进而影响批量执行效率，最终导致RAC双节点的执行效率反而比单节点效率低。

## （二）内存消耗异常问题

在测试过程中发现，Oracle 19c数据库服务器的内存利用率远远高于以往经验值，经过反复测试验证，最终发现使用AIX 7.2 TL3 SP2或AIX 7.2 TL3 SP3时，Oracle 19c数据库服务器存在内存消耗异常增加的BUG，该问题为Oracle与AIX兼容性问题所引发，具体如下所示：
![](/home/attachment/202010/26/377659_160369073859578.png)

最后，根据Oracle官方推荐解决了该问题，有效降低了内存的使用率，具体方法如下所示：
Oracle建议的修复方法 （修改makefile，然后relink）

（1）Shutdown database, listener and Oracle Enterprise Manager associated to the ORACLE_HOME software
（2）cd $ORACLE_HOME/rdbms/lib
（3）Make a backup file of the env_rdbms.mk file (cp env_rdbms.mk env_rdbms.mk_backup
（4）Edit the env_rdbms.mk and perform the following change:
replace the next line:
LDSHRSYMTAB=`if ldedit 2>&1 | grep shrsymtab > /dev/null 2>&1; then echo "-bshrsymtab"; fi`
to
LDSHRSYMTAB=`if ldedit -b 2>&1 | grep shrsymtab > /dev/null 2>&1; then echo "-bshrsymtab"; fi`
（5）Relink the oracle executable:
make -f $ORACLE_HOME/rdbms/lib/ins_rdbms.mk ioracle

## （三）硬件资源配置建议
经过近一年的业务测试验证及生产运行，数据表明：同样核数的POWER9系列小型机CPU处理能力是POWER8系列的近乎1.5-1.8倍，故在业务系统测算服务器计算资源时，需要重点关注，以免造成硬件资源的限制浪费。

## 七、总结
我行核心业务系统的关键应用及数据库节点全部基于浪潮K1 Power E950、S924及AIX，共累计通过了5轮（耗时5月）的非功能性测试验证，主要包括高可用性测试、性能测试和极限业务压力测试，最终以稳定的产品性能、成熟的技术累积和丰富的解决方案支撑保障核心业务系统项目的顺利投产上线和长时间的安全稳定运行。

目前核心业务系统已进入运行维护阶段近6个月，通过持续不断的监控及维护，各项数据指标再次证明浪潮K1 Power硬件的稳定可靠性是其它硬件设备无法比拟的，核心业务系统作为银行最关键最重要的业务系统，在设备选型上一定要本着“安全稳定”优先的原则，这样才能保障系统长期健康平稳运行，才能进一步提升业务连续性能力。

Power power 9 高可用性分布式系统核心系统 Power服务器

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论4 条评论

zhangjian1119系统工程师在路上科技有限公司
2020-11-04 12:22

交易库”、“核算库”、“T+0报表库”、“OM参数库”及“OMS运维监控管理库,这些是做的分库分表还是PDB？

chenmingfu： @zhangjian1119 是分库，不同的数据库

2020-11-04 16:42

添加新回复

sunjuzhong技术经理齐商银行股份有限公司
2020-11-03 15:01

从整个逻辑架构来看，采用小机为主，统筹考虑了分布式的架构，应该是中小银行的经典架构。有几块架构描述不是很清楚：一是基于power架构的应用服务器是双活（多活）还是主备，将直接影响到以后的扩展和灾备；二是基于power架构的应用是独立的机器支撑还是采用了powervm的虚拟技术，还是LP实现。如果统筹考虑数据治理的话，是否再追加授信库，细分账户库、客户库等等。

chenmingfu： @sunjuzhong 加强沟通

2020-11-04 16:42

sunjuzhong： @chenmingfu 为你们点赞，以后多向您请教。

2020-11-03 16:57

chenmingfu： @sunjuzhong 暂时没有考虑切分那么细致数据库

2020-11-03 16:43

chenmingfu： @sunjuzhong 所有应用服务器都是采用lpar方式，且所有应用服务器节点都是活的

2020-11-03 16:42

添加新回复

chenmingfu

基础架构组长西部某城商银行
2020-10-29 22:04

应用程序采用分布式架构部署，所以感觉比以往传统负载均衡架构复杂，所有虚拟机都是采用VMware虚拟化技术部署的