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

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

某银行核心系统架构升级改造相关推荐

最全银行核心系统架构解读（165页PPT）
银行IT研究要点
支付业务与技术架构学习总结（9）——银行核心系统之清算体系
支付清算系统是经济金融活动的基础性支撑.支付.清算体系建设是金融理论与实践的重点课题.本文主要描述了支付系统建设的发展历程及构成,分析了银行内部清算体系设计,有利于快速建立起金融服务体系思路.希望略尽 ...
linux服务器可用处理核心,linuxOne是采用什么架构或者技术来保障银行核心系统对于可靠性极高要求？...
LinuxONE依托主机三大战略设计核心理念,全面继承主机成熟和先进的技术:可靠性,可用性和可维护性(RAS): 业务连续可用:安全性,最大程度保障银行核心系统的可靠稳定,LinuxONE硬件平台已连 ...
银行核心系统服务器,银行核心系统之技术架构(一).pdf
银行核心系统之技术架构目录前言 3 1.此文适合人群: 3 2.此文解决问题: 3 3.此文分为三部分: 3 1.主机时代 3 (1)单体架构4 (2)操作系统(z/OS) 4 (3)命令输入处理 ...
银行核心系统如何选型分布式数据库（含6大落地要点验证）
本文根据洪烨老师在[deeplus直播:金融业数据库转型与国产化改造]线上分享演讲内容整理而成.(文末有回放的方式,不要错过) 洪烨光大银行数据库专家具有多年银行业系统架构设计及DBA实战经验, ...
腾讯云发布金融国产化战略、《腾讯云银行核心系统分布式转型白皮书》
5月11日,在腾讯金融云国产化战略峰会上,腾讯云发布金融国产化战略:腾讯云将持续加大技术投入打造新一代国产化精品产品,并依托产品构建全栈领先的国产数字化基座.同时,腾讯云还将携手伙伴,共同构建国产数字 ...
tickcount()修改成小时分钟_银行核心系统24小时机制实现总结
本文共2268字 | 建议阅读时间:5分钟作者:张广在核心系统的设计实现中,24小时机制向来是一个重点难点.早期的银行只有柜面一个业务办理渠道,因此当时的综合业务系统,跟随网点的营业时间,分为日起 ...
银行核心系统之应用集成
银行核心系统之应用集成云技术 10月8日以下文章来源于小代嘚吧嘚 ,作者代堂鸣小代嘚吧嘚欢迎加入银行核心系统大本营,用讲故事的方式给银行业务加点料,用项目管理的方法来改进工作和生活! 本文共7 ...
goldendb与mysql_GoldenDB ，一个已经全面支撑银行核心系统的国产数据库
摘要:沿用.并存还是替代,一直是银行核心系统数据库转型重点思考的问题.四大行目前主要采用的是沿用与并存的数据库产品战略,在确保稳定的大前提下对新兴数据库技术进行探索研究和实践.相对而言,股份制银行在这 ...

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

某银行核心系统架构升级改造相关推荐

最新文章

热门文章