集中式与分布式相融合的银行核心系统架构转型策略分析

1、 集中式与分布式相融合的银行核心系统架构转型策略分析 目 录 TOC o 1-3 h z u HYPERLINK l _Toc65178511 1 概述 PAGEREF _Toc65178511 h 3 HYPERLINK l _Toc65178512 2 面向双速 IT 的银行核心系统融合架构 PAGEREF _Toc65178512 h 3 HYPERLINK l _Toc65178513 2.1 集中式核心系统与分布式核心系统 PAGEREF _Toc65178513 h 3 HYPERLINK l _Toc65178514 2.2 两种架构核心系统对比分析 PAGEREF _Toc65

2、178514 h 4 HYPERLINK l _Toc65178515 2.3 采用融合性架构的核心系统 PAGEREF _Toc65178515 h 7 HYPERLINK l _Toc65178516 3 银行核心系统融合 IT 架构设计 PAGEREF _Toc65178516 h 7 HYPERLINK l _Toc65178517 3.1 基于逻辑数据中心的应用双活架构 PAGEREF _Toc65178517 h 7 HYPERLINK l _Toc65178518 3.2 按需选择的商业与分布式数据库并存架构 PAGEREF _Toc65178518 h 9 HYPERLINK

3、l _Toc65178519 3.2.1 商业与分布式数据库按需并存 PAGEREF _Toc65178519 h 9 HYPERLINK l _Toc65178520 3.2.2 分布式数据库设计要点分析 PAGEREF _Toc65178520 h 10 HYPERLINK l _Toc65178521 3.3 多形态融合的私有云基础设施资源池 PAGEREF _Toc65178521 h 12 HYPERLINK l _Toc65178522 3.3.1 整合、迁移至多形态并存的私有云基础设施资源池，实现降本生效 PAGEREF _Toc65178522 h 12 HYPERLINK l

4、 _Toc65178523 3.3.2 统一的多云管理平台，高效应对运维管理挑战 PAGEREF _Toc65178523 h 13 HYPERLINK l _Toc65178524 4 总结与展望 PAGEREF _Toc65178524 h 141 概述中国金融业信息技术发展规划指出，金融机构主动探索系统架构完善升级，继续深入研究数据中心“双活”或“多活”模式应用。在巩固集中式架构安全稳定运行的基础上，综合成本、效率、资源等方面，以业务适用性为原则，研究分布式架构应用的可行性。核心系统作为银行信息系统的心脏，历来是 IT 系统建设的重点和难点。银行核心系统经历了从总分行数据分离，到全行数据

5、大集中架构，再到基于 SOA 架构的新核心系统，目前已经走到了基于云计算架构的转型阶段。在此转型过程中，保留面向“稳态”的银行传统核心、新建面向“敏态”的互联网核心，是大部分银行的普遍选择。“稳态”传统核心基于传统集中式架构，具备安全、稳定的特点，注重既有传统业务的连续性，例如存款一类账户、借记卡、传统贷款、支付等业务；“敏态”互联网核心采用分布式架构，可以支撑海量客户、海量账户和高并发，满足秒杀、抢购等互联网营销场景，适合管理二三类账户、直销银行等相关业务。本文首先对传统核心和互联网核心所分别采用的集中式和分布式两种不同架构进行简要介绍，全面分析两种架构的优缺点；在综合考虑投入产出和业务技术

6、风险、满足业务快速创新的前提下，介绍“集中式与分布式相融合”的核心系统转型实施策略。然后，基于应用架构、数据架构视角，对应用双活、数据库高可用、分布式数据存储与访问进行介绍。最后，从物理部署架构视角来看，传统核心与互联网核心并存的情况下，必然会面对多种类型基础设施（大型机、小型机、 x86 、虚拟机和容器云等）和多种存在形态应用（集中式、分布式和容器化等）带来的运维管理挑战；通过构建统一的多云管理平台，可以实现降本增效、高效运维。2 面向双速 IT 的银行核心系统融合架构2.1 集中式核心系统与分布式核心系统集中式架构核心系统现阶段，大部分传统商业银行都完成了整个银行系统的 SOA 化改造，但

7、核心系统都还是采用集中式架构，即核心系统作为一个整体应用，部署在传统的大型机、小型机集群中，数据库采用传统的商业数据库（如 DB2 、 Oracle 等），中间件也采用传统的商业中间件软件，采用成熟的集群和高可用方案保证业务连续性。但随着互联网 + 金融场景的兴起，集中式核心系统已经无法轻松应对海量用户、海量数据和高并发的业务场景；同时，集中式架构的核心系统是一个庞大的单体应用，系统升级迭代复杂，难以互联网时代业务快速创新的需求。分布式架构银行核心系统从目前来看，很多银行都把采用分布式架构建设银行核心提供提上了日程。从公开的新闻资料中可以看到，部分银行的分布式核心系统已经建设完成并投产，在降本

8、增效方面有不俗的表现。不同于集中式核心系统大量采用商用软件和高端硬件，在建设分布式核心系统时，通常会采用开源软件，运行在 x86 服务器、虚拟机或容器云环境中，这在很多程度上提高了银行对核心系统的自主掌控程度，同时大大降低了运行成本。2.2 两种架构核心系统对比分析集中式机构和分布式架构，都有各自的优缺点和适用场景，在进行架构选型时，需要充分论证、取长补短，有差别有针对性地予以采用。以下是针对这两种架构从不同的维度的分析对比：集中式架构分布式架构优势方系统容量与性能集中式系统的处理能力的提升主要是通过垂直扩展（即提升单机硬件处理能力），受限于硬件处理能力的天花板，在达到一定容量之后就无法再进行

9、处理能力的提升通过数据分布式存储、应用微服务化部署，系统容量可以实现无限扩容，满足海量数据存储和高并发请求的处理分布式运维复杂度无论是应用的数量上还是所需要的硬件基础设施上，相对于分布式架构在规模上很小，应用部署和维护都非常简单；同时，一个完整的服务请求会在一台应用服务器上完成，操作的数据库也只有一个集中式数据库，系统运维人员在进行故障排查时会很非常方便分布式架构下，需要运维成百上千的应用服务器，需要面对数据分布式存储之后的数据管理，需要处理微服务架构下服务相互调用带来的服务治理与故障排查，采用传统的运维方式已经无法满足需求，基于 DevOps 理念的新的运维工具必须同步建设集中式业务需求响应

10、速度一个业务需求的变更，往往涉及到复杂的影响分析和大量的系统测试，一次上线部署往往以月为单位微服务架构将庞大的核心系统解耦，业务需求的变更通常可以落到某个微服务应用上，单个微服务应用的升级迭代往往可以实现以周为单位进行发布部署分布式数据一致性数据的一致性直接可以通过数据库事务来保证。即使有复杂的业务场景处理大量的不同领域数据对象，数据库事务能够轻松应对数据一致性需求分布式事务不可避免：微服务和数据分布式存储必然会带来跨应用、跨数据库的分布式事务，每种类型的分布式场景需要有相应的应对措施集中式总拥有成本软硬件高昂的采购费用，通常每年还有相应大量的维保服务费等；同时，这些软硬件掌握在少数几家国外厂

11、商手里，议价空间很小由于采用 x86 服务器取代大型机、小型机，适用开源软件替代商业软件，系统的总拥有成本低分布式自主掌控程度技术封闭，金融企业无法做到完全自主掌控大量采用开源软件，可以摆脱关键技术对供应商的依赖，银行对系统的自主掌控能力更高，金融安全程度更高分布式人才队伍需求如果出现故障，厂商会有强大的专家支持团队，快速定位问题、解决问题，有效避免故障升级到监管层面大量采用开源软件，需要投入精英团队对所采用的关键开源软件实现源码级别掌控，避免出现生产故障时束手无策，影响业务连续性集中式2.3 采用融合性架构的核心系统虽然分布式架构已经成为发展趋势，但作为银行信息系统的心脏，传统核心系统下线升

12、级为分布式核心系统，需要充分考虑投入产出，平衡业务风险和技术风险。在当前阶段，采用集中式与分布式相融合的架构体系，可以扬长避短，在保证传统核心业务确保稳定、不受影响的前提下，满足互联网 + 业务场景、实现快速创新。（1）集中式架构核心系统： 功能相对稳定、与客户资金安全紧密相关、且无明显性能容量压力的业务，一段时期内人保留在集中式核心系统中。例如传统的存款业务、贷款业务等；（2）分布式架构核心系统：对于业务 新颖性强、创新速度较快、交易并发量大的业务，可以在分布式架构核心系统落地。例如面向互联网场景的直销银行电子账户、互联网贷款等业务。3 银行核心系统融合 IT 架构设计3.1 基于逻辑数据中

13、心的应用双活架构集中式架构高可用策略传统集中式银行核心系统通常都是按照两地三中心的架构进行部署，即同城双中心加异地灾备中心，这一方案兼具高可用性和灾难备份的能力。同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。依赖于高可靠、高可用小型机（如 Power 等）、高端存储的复制技术和商业数据库的高可用方案，

14、目前银行业已经有成熟的集中式核心系统高可用方案。采用逻辑数据中心的分布式应用同城双活架构采用分布式架构的银行核心系统，可以通过采用逻辑数据中心设计来实现系统容量的无线扩容，并同时保持恒定的交易响应时间。逻辑数据中心的含义是：对物理数据中心进行逻辑上的划分，每个逻辑数据中心相互独立；每个逻辑数据中心部署相同的应用，但应用数据库通过分库分表之后均匀分布在每个逻辑数据中心中；每个客户的交易请求只会在一个逻辑数据中心内处理。由于每个逻辑数据中心里可以稳定支撑固定数量的客户交易请求，当系统容量达到上限时，可以通过增加新的逻辑分区实现系统容量的提升，满足更大的数据量、更高的并发量。还以同城两个数据中心为例

15、，每个数据中心再在逻辑上划分为两个数据中心，这样我们就有 4 个逻辑数据中心，这样我们就得到一个典型的基于逻辑数据中心的同城双活架构图：从横向上来看，该架构主要包含了以下几层：服务接入层：该层横跨两个数据中心，部署路由应用，负责服务请求的分发。路由应用通过解析服务请求报文，根据路由规则确定该请求该路由至哪个逻辑数据中心；核心应用层：每个逻辑数据中心部署相同的核心应用集群，每个集群只连接本逻辑数据中心的数据库；数据存储层：对数据进行分库分表处理，平均分为 4 份；每个逻辑数据中心只存储其中的 1 份。最终在物理部署上，可以在逻辑数据中心之间进行跨机房热备，进行数据库层面高可用部署。从纵向来看，每

16、个分区单元都是独立自包含的，按照分区规则服务固定的客户；当某个分区出现故障时，只有该分区的客户交易会受到影响，其它分区可以正常工作，这也在一定程度上提高了系统的可用性和业务连续性。使用基于逻辑数据中心的架构，在进行系统设计时要尽量避免分区间应用的相互调用，如果无法避免跨逻辑数据中心的交易调用（例如核心系统中常见的转账交易），应该考虑在逻辑数据中心之前部署独立的服务集成类应用，来进行跨逻辑数据中心的交易处理（如转账交易在该应用中，发生转账交易时分别调用两个分区的扣款和入账交易）。3.2 按需选择的商业与分布式数据库并存架构3.2.1 商业与分布式数据库按需并存传统商业银行中，除了国有大行、股份制

17、银行和部分农商行联盟所管理的账户数和客户数能够上亿，大部分城商行、农商行核心系统中的账户数和客户数在千万级或更少。对于这部分银行，成熟的商业数据库已经可以满足传统核心系统处理能力需求，加之考虑系统的升级成本与风险，通常不会改造采用分布式数据库；而对于新增加的面向互联网金融场景的应用，可以考虑采用分布式数据库来应对快速增长的海量数据和高并发请求。在当前基础设施向云化发展的大环境下，两种架构数据库服务器也有着明显的不同：集中式架构数据库：传统核心业务系统作为金融行业中最为重要的系统，无论是应用和数据库都需要极致的可靠性和纵向扩展的弹性需求，适合最为稳健的裸机或逻辑分区部署方式，通过高端服务器的纵向

18、扩展和在线调整资源能力保障业务的弹性。从目前银行核心系统实际情况来看，目前 Power 系列凭借其稳定性和卓越性能，依旧是大部分银行核心系统的主流直选。分布式架构数据库：分布式数据库采用 SSD 存储部署在 x86 服务器集群上，可部署在基于 Open POWER 服务器整合 x86 和中低端小型机搭建的私有云资源池上。3.2.2 分布式数据库设计要点分析对于应对互联网 + 场景的业务系统，为了能够应对海量数据与高并发，势必采用满足无限扩容的分布式数据库。分布式数据库的实现主要分为两类：基于数据访问中间件的分布式数据库：数据通过分库分表策略存储在传统关系型数据库上，应用通过分布式数据访问中间件

19、操作数据库，数据访问中间件屏蔽具体的分库分表策略。典型的分库分表中间件有阿里的 DRDS 、 Sharding Sphere 等；新一代分布式关系型数据库：例如蚂蚁金服的 OceanBase 、 PingCap 出品的 TiDB 。该类数据库无需应用开发人员定义分库分表规则，数据库本身支持自分区，同时通过分布式一致性协议进行数据存储与备份，极大的简化了应用数据访问处理。数据分布式存储设计要点在目前的行业实践经验来看，基于数据访问中间件 + 传统关系型数据库进行分库分表存储还是业界主流，而新一代关系型数据库还是更多的被带有互联网基因的企业所采用。在进行分库分表设计时，需要遵循以下几方面的原则：考

20、虑后续扩容需求，避免进行级数据迁移，分表数量要有充分冗余：例如当前分表为 128 份，存储在 2 个数据库中，则每个数据库中有 64 份表；随着数据量的增加， 2 个数据库需要扩容为 4 个数据库，则只需从原先每个库中各迁移出 32 份表到新的数据库中，从而通过表迁移完成扩容，无需处理行级数据迁移；选择合适的分表维度，尽量避免带来复杂的分布式事务：分布式核心中，对外提供的大量交易都围绕着同一个客户，在进行分库分表设计时，可以考虑以客户为维度进行分表设计。这样应用的大部分交易都限定在单个数据库上，避免出现复杂的分布式事务。分布式事务应对策略数据进行分布式存储之后，基本上不太可能完全避免分布式事务

21、。对于分布式事务，业界有多种不同的应对方式，每种方式各有优缺点，以下是一个分析对比：方案方案特点适用场景XA事务通过数据库 XA 协议两阶段提交保证资源管理器支持 XA 协议，对并发性能要求不高SAGA 补偿多个参与者执行业务操作，若任一环节失败，参与者执行原始操作的反向操作支持反向操作，同时能确保反向操作无风险基于消息的最终一致性参与者在本地事务提交时，发送可靠消息给消息中心，下一参与者获取消息后，执行本地事务没有理由失败，一定可以成功的业务，并能接受一定的时延TCC业务层面实现两阶段提交（ Try/Confirm/Cancel ）强隔离性、严格一致性要求的业务活动，适用于执行时间较短的业务

22、3.3 多形态融合的私有云基础设施资源池3.3.1 整合、迁移至多形态并存的私有云基础设施资源池，实现降本生效在集中式核心与分布式核心并存的情况下，对基础设施也提出了新的要求，从而形成了多形态并存的私有云基础设施资源池，资源池里通常包括以下几类基础设施：传统的大型机、小型机：为传统集中式架构应用提供高可用、高可用和稳定性极高的物理基础设施，用于部署传统核心系统的应用、数据库和中间件；x86 服务器：主要面向对性能要求高、需要独立存储设备的系统，例如轻量级数据库（如 MySQL ）和有存储需求的中间件（例如 Zookeeper 、 Kafka 等）。以 MySQL 数据库的部署为例，通常采用 x

23、86 服务器按需配置足够的 CPU 和内存，采用 SSD 作为存储，配合 MySQL 高可用策略，在降低硬件成本的同时，也摆脱了对商业数据库的依赖；虚拟机：主要面向业务应用和无需独立存储设施的中间件（该类中间件通常将数据持久化到数据库和其它中间件）；容器云：需要实现快速弹性部署、面向采用容器技术部署的应用。现在 Docker 已经成为了容器界的标准，而 K8s 在多个容器编排系统中胜出，云原生理念已经越来越普及，在银行内部搭建自己的容器云环境已经是大多数银行的必然选择。对于分布式架构的应用，需要的是大规模集群、低成本的弹性基础设施，而通过对生产环境 x86 服务器和老旧小型机的整合搭建私有云资源池，可以有效提高已有硬件的使用率、降低运行成本。以 Power 云资源池为例，在下图中，某省农信用户即实施了私有云架构的迁移，采用构建更合理高效的私有云资源池的方式，在数月时间内完成了整合超过 200 台各类 PC 服务器和旧有小型机上的数据库及应用的任务，同时还保留有足够容量应对新增业务。从整合的效果上看，原有 PC 服务器和老旧小型机占用了大量的机房电力和空间，实际使用率不高，通过小型机虚拟化资源池整合节省了 75% 的机房空间电力，同时通过私有云方式大幅简化架构并统一管理，实现了成本的大幅降低，用一个全新的方式解决了长期以来困扰用户的难题。同时通过资源池