1 概述

《中国金融业信息技术“十三五”发展规划》指出，金融机构主动探索系统架构完善升级，继续深入研究数据中心“双活”或“多活”模式应用。在巩固集中式架构安全稳定运行的基础上，综合成本、效率、资源等方面，以业务适用性为原则，研究分布式架构应用的可行性。

核心系统作为银行信息系统的心脏，历来是 IT 系统建设的重点和难点。银行核心系统经历了从总分行数据分离，到全行数据大集中架构，再到基于 SOA 架构的新核心系统，目前已经走到了基于云计算架构的转型阶段。

在此转型过程中，保留面向“稳态”的银行传统核心、新建面向“敏态”的互联网核心，是大部分银行的普遍选择。“稳态”传统核心基于传统集中式架构，具备安全、稳定的特点，注重既有传统业务的连续性，例如存款一类账户、借记卡、传统贷款、支付等业务；“敏态”互联网核心采用分布式架构，可以支撑海量客户、海量账户和高并发，满足秒杀、抢购等互联网营销场景，适合管理二三类账户、直销银行等相关业务。

本文首先对传统核心和互联网核心所分别采用的集中式和分布式两种不同架构进行简要介绍，全面分析两种架构的优缺点；在综合考虑投入产出和业务技术风险、满足业务快速创新的前提下，介绍“集中式与分布式相融合”的核心系统转型实施策略。然后，基于应用架构、数据架构视角，对应用双活、数据库高可用、分布式数据存储与访问进行介绍。最后，从物理部署架构视角来看，传统核心与互联网核心并存的情况下，必然会面对多种类型基础设施（大型机、小型机、 x86 、虚拟机和容器云等）和多种存在形态应用（集中式、分布式和容器化等）带来的运维管理挑战；通过构建统一的多云管理平台，可以实现降本增效、高效运维。

2 面向双速 IT 的银行核心系统融合架构

2.1 集中式核心系统与分布式核心系统

集中式架构核心系统

现阶段，大部分传统商业银行都完成了整个银行系统的 SOA 化改造，但核心系统都还是采用集中式架构，即核心系统作为一个整体应用，部署在传统的大型机、小型机集群中，数据库采用传统的商业数据库（如 DB2 、 Oracle 等），中间件也采用传统的商业中间件软件，采用成熟的集群和高可用方案保证业务连续性。

但随着互联网 + 金融场景的兴起，集中式核心系统已经无法轻松应对海量用户、海量数据和高并发的业务场景；同时，集中式架构的核心系统是一个庞大的单体应用，系统升级迭代复杂，难以互联网时代业务快速创新的需求。

分布式架构银行核心系统

从目前来看，很多银行都把采用分布式架构建设银行核心提供提上了日程。从公开的新闻资料中可以看到，部分银行的分布式核心系统已经建设完成并投产，在降本增效方面有不俗的表现。

不同于集中式核心系统大量采用商用软件和高端硬件，在建设分布式核心系统时，通常会采用开源软件，运行在 x86 服务器、虚拟机或容器云环境中，这在很多程度上提高了银行对核心系统的自主掌控程度，同时大大降低了运行成本。

2.2 两种架构核心系统对比分析

集中式机构和分布式架构，都有各自的优缺点和适用场景，在进行架构选型时，需要充分论证、取长补短，有差别有针对性地予以采用。以下是针对这两种架构从不同的维度的分析对比：

2.3 采用融合性架构的核心系统

虽然分布式架构已经成为发展趋势，但作为银行信息系统的心脏，传统核心系统下线升级为分布式核心系统，需要充分考虑投入产出，平衡业务风险和技术风险。

在当前阶段，采用集中式与分布式相融合的架构体系，可以扬长避短，在保证传统核心业务确保稳定、不受影响的前提下，满足互联网 + 业务场景、实现快速创新。

（1）集中式架构核心系统： 功能相对稳定、与客户资金安全紧密相关、且无明显性能容量压力的业务，一段时期内人保留在集中式核心系统中。例如传统的存款业务、贷款业务等；

（2）分布式架构核心系统：对于业务 新颖性强、创新速度较快、交易并发量大的业务，可以在分布式架构核心系统落地。例如面向互联网场景的直销银行电子账户、互联网贷款等业务。

3 银行核心系统融合 IT 架构设计

3.1 基于逻辑数据中心的应用双活架构

集中式架构高可用策略

传统集中式银行核心系统通常都是按照两地三中心的架构进行部署，即同城双中心加异地灾备中心，这一方案兼具高可用性和灾难备份的能力。

同城双中心是指在同城或邻近城市建立两个可独立承担关键系统运行的数据中心，双中心具备基本等同的业务处理能力并通过高速链路实时同步数据，日常情况下可同时分担业务及管理系统的运行，并可切换运行；异地灾备中心是指在异地的城市建立一个备份的灾备中心，用于双中心的数据备份，当双中心出现自然灾害等原因而发生故障时，异地灾备中心可以用备份数据进行业务的恢复。

依赖于高可靠、高可用小型机（如 Power 等）、高端存储的复制技术和商业数据库的高可用方案，目前银行业已经有成熟的集中式核心系统高可用方案。

采用逻辑数据中心的分布式应用同城双活架构

采用分布式架构的银行核心系统，可以通过采用逻辑数据中心设计来实现系统容量的无线扩容，并同时保持恒定的交易响应时间。

逻辑数据中心的含义是：对物理数据中心进行逻辑上的划分，每个逻辑数据中心相互独立；每个逻辑数据中心部署相同的应用，但应用数据库通过分库分表之后均匀分布在每个逻辑数据中心中；每个客户的交易请求只会在一个逻辑数据中心内处理。由于每个逻辑数据中心里可以稳定支撑固定数量的客户交易请求，当系统容量达到上限时，可以通过增加新的逻辑分区实现系统容量的提升，满足更大的数据量、更高的并发量。

还以同城两个数据中心为例，每个数据中心再在逻辑上划分为两个数据中心，这样我们就有 4 个逻辑数据中心，这样我们就得到一个典型的基于逻辑数据中心的同城双活架构图：

从横向上来看，该架构主要包含了以下几层：

• 服务接入层：该层横跨两个数据中心，部署路由应用，负责服务请求的分发。路由应用通过解析服务请求报文，根据路由规则确定该请求该路由至哪个逻辑数据中心；
• 核心应用层：每个逻辑数据中心部署相同的核心应用集群，每个集群只连接本逻辑数据中心的数据库；
• 数据存储层：对数据进行分库分表处理，平均分为 4 份；每个逻辑数据中心只存储其中的 1 份。最终在物理部署上，可以在逻辑数据中心之间进行跨机房热备，进行数据库层面高可用部署。

从纵向来看，每个分区单元都是独立自包含的，按照分区规则服务固定的客户；当某个分区出现故障时，只有该分区的客户交易会受到影响，其它分区可以正常工作，这也在一定程度上提高了系统的可用性和业务连续性。

使用基于逻辑数据中心的架构，在进行系统设计时要尽量避免分区间应用的相互调用，如果无法避免跨逻辑数据中心的交易调用（例如核心系统中常见的转账交易），应该考虑在逻辑数据中心之前部署独立的服务集成类应用，来进行跨逻辑数据中心的交易处理（如转账交易在该应用中，发生转账交易时分别调用两个分区的扣款和入账交易）。

3.2 按需选择的商业与分布式数据库并存架构

3.2.1 商业与分布式数据库按需并存

传统商业银行中，除了国有大行、股份制银行和部分农商行联盟所管理的账户数和客户数能够上亿，大部分城商行、农商行核心系统中的账户数和客户数在千万级或更少。对于这部分银行，成熟的商业数据库已经可以满足传统核心系统处理能力需求，加之考虑系统的升级成本与风险，通常不会改造采用分布式数据库；而对于新增加的面向互联网金融场景的应用，可以考虑采用分布式数据库来应对快速增长的海量数据和高并发请求。

在当前基础设施向云化发展的大环境下，两种架构数据库服务器也有着明显的不同：

集中式架构数据库：传统核心业务系统作为金融行业中最为重要的系统，无论是应用和数据库都需要极致的可靠性和纵向扩展的弹性需求，适合最为稳健的裸机或逻辑分区部署方式，通过高端服务器的纵向扩展和在线调整资源能力保障业务的弹性。从目前银行核心系统实际情况来看，目前 Power 系列凭借其稳定性和卓越性能，依旧是大部分银行核心系统的主流直选。

分布式架构数据库：分布式数据库采用 SSD 存储部署在 x86 服务器集群上，可部署在基于 Open POWER 服务器整合 x86 和中低端小型机搭建的私有云资源池上。

3.2.2 分布式数据库设计要点分析

对于应对互联网 + 场景的业务系统，为了能够应对海量数据与高并发，势必采用满足无限扩容的分布式数据库。分布式数据库的实现主要分为两类：

基于数据访问中间件的分布式数据库：数据通过分库分表策略存储在传统关系型数据库上，应用通过分布式数据访问中间件操作数据库，数据访问中间件屏蔽具体的分库分表策略。典型的分库分表中间件有阿里的 DRDS 、 Sharding Sphere 等；

新一代分布式关系型数据库：例如蚂蚁金服的 OceanBase 、 PingCap 出品的 TiDB 。该类数据库无需应用开发人员定义分库分表规则，数据库本身支持自分区，同时通过分布式一致性协议进行数据存储与备份，极大的简化了应用数据访问处理。

数据分布式存储设计要点

在目前的行业实践经验来看，基于数据访问中间件 + 传统关系型数据库进行分库分表存储还是业界主流，而新一代关系型数据库还是更多的被带有互联网基因的企业所采用。在进行分库分表设计时，需要遵循以下几方面的原则：

考虑后续扩容需求，避免进行级数据迁移，分表数量要有充分冗余：例如当前分表为 128 份，存储在 2 个数据库中，则每个数据库中有 64 份表；随着数据量的增加， 2 个数据库需要扩容为 4 个数据库，则只需从原先每个库中各迁移出 32 份表到新的数据库中，从而通过表迁移完成扩容，无需处理行级数据迁移；

选择合适的分表维度，尽量避免带来复杂的分布式事务：分布式核心中，对外提供的大量交易都围绕着同一个客户，在进行分库分表设计时，可以考虑以客户为维度进行分表设计。这样应用的大部分交易都限定在单个数据库上，避免出现复杂的分布式事务。

分布式事务应对策略

数据进行分布式存储之后，基本上不太可能完全避免分布式事务。对于分布式事务，业界有多种不同的应对方式，每种方式各有优缺点，以下是一个分析对比：

3.3 多形态融合的私有云基础设施资源池

3.3.1 整合、迁移至多形态并存的私有云基础设施资源池，实现降本生效

在集中式核心与分布式核心并存的情况下，对基础设施也提出了新的要求，从而形成了多形态并存的私有云基础设施资源池，资源池里通常包括以下几类基础设施：

传统的大型机、小型机：为传统集中式架构应用提供高可用、高可用和稳定性极高的物理基础设施，用于部署传统核心系统的应用、数据库和中间件；

x86 服务器：主要面向对性能要求高、需要独立存储设备的系统，例如轻量级数据库（如 MySQL ）和有存储需求的中间件（例如 Zookeeper 、 Kafka 等）。以 MySQL 数据库的部署为例，通常采用 x86 服务器按需配置足够的 CPU 和内存，采用 SSD 作为存储，配合 MySQL 高可用策略，在降低硬件成本的同时，也摆脱了对商业数据库的依赖；

虚拟机：主要面向业务应用和无需独立存储设施的中间件（该类中间件通常将数据持久化到数据库和其它中间件）；

容器云：需要实现快速弹性部署、面向采用容器技术部署的应用。现在 Docker 已经成为了容器界的标准，而 K8s 在多个容器编排系统中胜出，云原生理念已经越来越普及，在银行内部搭建自己的容器云环境已经是大多数银行的必然选择。

对于分布式架构的应用，需要的是大规模集群、低成本的弹性基础设施，而通过对生产环境 x86 服务器和老旧小型机的整合搭建私有云资源池，可以有效提高已有硬件的使用率、降低运行成本。

以 Power 云资源池为例，在下图中，某省农信用户即实施了私有云架构的迁移，采用构建更合理高效的私有云资源池的方式，在数月时间内完成了整合超过 200 台各类 PC 服务器和旧有小型机上的数据库及应用的任务，同时还保留有足够容量应对新增业务。

从整合的效果上看，原有 PC 服务器和老旧小型机占用了大量的机房电力和空间，实际使用率不高，通过小型机虚拟化资源池整合节省了 75% 的机房空间电力，同时通过私有云方式大幅简化架构并统一管理，实现了成本的大幅降低，用一个全新的方式解决了长期以来困扰用户的难题。同时通过资源池方式大幅简化架构并统一管理，顺利完成异地双中心资源池建设并成功主备切换。

3.3.2 统一的多云管理平台，高效应对运维管理挑战

面对复杂的基础设施层，势必需要一个多云管理平台，能够对基础设施进行高效管理，同时提升发布部署效率和稳定性，提高业务连续性。

通过采用统一的多云管理平台，可以在以下几方面有效提高运维的效率：

快速提供应用运行软硬件环境：基于私有云基础设施资源池和软件目录，可以为开发团队和运维团队快速提供开发运行环境，避免漫长的运行环境交付流程；

全面、实时的监控体系：对物理基础设施、中间件、应用提供全面的监控，对故障实时预警；同时支持全链路监控以应对 SOA 、分布式架构下跨应用节点的服务调用，便于运维团队快速排查问题；

高效的应用发布部署：在采用分布式架构之后，不管是采用虚拟机还是容器进行应用部署，应用集群规模会成百上千。云管平台的大规模、快速部署能力，将大大提升应用的升级分布速度。

一个典型的统一多云管理平台示意图：

4 总结与展望

面对日新月异的信息技术变革，银行 IT 架构也在持续优化、不断转型。从银行核心系统转型现状来看，越来越多的银行采用分布式架构建设互联网核心，用于管理面向互联网场景的二三类账户，以适应互联网场景下快速的业务创新和高频交易；而考虑到投入产出、业务和技术风险，传统的集中式架构核心将进行保留沿用。

未来，随着云计算技术的成熟，目前基于中间件技术的分布式架构，势必会向对应用更简单易用的云架构方向发展，采用如 K8s 、 ServiceMesh 等云原生技术；而伴随像蚂蚁金服 OceanBase 等分布式数据库的成熟，分布式数据存储与访问、数据一致性问题将大大简化，数据库层面的容量、性能和高可用也会有本质上的突破。

与此同时，采用集中式架构的传统银行核心系统也需要与时俱进，结合当前大数据营销、个性化金融产品等业务需求，持续进行 IT 基础设施升级和业务功能优化。