商业银行核心系统单元化改造的研究与思考

随着金融科技的快速发展，银行核心系统面临着更高的处理能力、扩展能力及业务连续性的要求与挑战。为应对这些挑战，许多银行开始考虑对其核心系统进行单元化改造。本文首先分析了传统银行核心系统存在的问题以及单元化改造的必要性，然后详细阐述了单元化改造的设计思路、实施过程以及可能遇到的挑战并通过光大银行核心系统主机下移、上云改造项目的开展，分析和总结在架构设计及测试验证阶段的应对方法，希望对金融系统架构转型工作的推广落地提供一定的借鉴意义。

引言

银行核心系统是商业银行运作的基础，承载着处理交易、管理资产、风险控制等重要职责。然而，随着业务量的不断增长、技术的持续迭代以及监管要求的提高，传统银行核心系统的弊端逐渐显现，如性能瓶颈、可扩展性差、灵活性不足等。这些问题不仅影响了银行业务的快速发展，还可能给银行的安全运营工作带来诸多风险。

单元化改造作为一种新兴的架构优化方法，通过将系统拆分为多个独立的单元，实现了系统的横向扩展和灵活性提升。每个单元负责处理特定的业务逻辑或业务范围，可以在单元局部进行独立的部署、升级和维护。这种改造方式不仅可以提高系统的处理能力，还可以降低系统的复杂性，提高系统的稳定性和可维护性。

本文旨在深入研究银行核心系统的单元化改造，分析改造的必要性、设计思路、实施过程以及可能遇到的挑战。并通过改造项目工作的实践总结，为商业银行提供有益的参考。

传统银行核心系统问题分析

传统的银行核心系统主要存在以下问题：

1.1 性能瓶颈问题

随着业务量的不断增长，传统银行核心系统的处理能力逐渐达到瓶颈，难以满足业务高峰期的需求。集中式架构下通常采用垂直扩展的方式以提升单台服务器的性能来应对业务增长。然而这种方式的可扩展性受于硬件资源的限制且无法有效解决热点资源争用问题，在系统长时间的运行过程中伴随着由于性能问题导致的交易延迟、系统崩溃等问题，在客户体验及客户满意度方面均存在一定影响。

1.2 灵活性问题

在传统核心系统的集中式部署架构下，业务逻辑和数据处理紧密耦合，导致系统灵活性差，升级维护困难。新业务需求引入的过程中可能需要对系统进行较大规模的改动，使得系统难以快速调整以适应业务变化并增加了系统的运行风险。

1.3 可靠性问题

集中式架构中系统的服务及数据均较为集中，对应的节点或组件出现故障时，整个系统都将受到影响，甚至可能导致系统完全不可用。这种单点故障问题的严重性在于它对整个系统的稳定性和可用性造成了威胁，而集中式架构下的灾备恢复体系已无法支撑客户对核心业务服务连续性的需要。

单元化改造的必要性

银行系统技术架构改造的需求主要源自业务的快速发展和流量爆发性增长，以及传统集中式架构存在的性能瓶颈、扩展性问题、单点故障以及安全风险等问题。上述问题通过标准的分布式架构可得到较好的解决，但分布式技术产品通常均由的多组件构成，在此特点下，仍有可能出现关键组件故障导致整体服务中断的情况出现，同时也无法避免可用区级别或数据中心级别故障时对系统可用性带来的整体影响。

在分布式技术的基础之上，单元化架构的核心思想是将复杂的系统划分为多个独立的单元，每个单元都能独立处理业务，实现业务的解耦和自治。这种架构模式使得系统能够在多个地理位置分散的数据中心进行部署和运行，每个数据中心可承担部分单元业务的处理任务，因此这种架构模式带来了以下几个方面的优势：

2.1 异地多活与故障容灾能力

单元化架构允许系统在多个数据中心同时运行，每个单元都能够处理真实的业务流量。当某个数据中心发生故障时，其他数据中心的单元可以迅速接管故障单元的流量和数据，保证了业务的连续性和高可用性。这种能力有效减少了故障对用户的打扰和业务的中断，即使无法完全切换流量，也能将故障的影响范围限制在部分用户，降低了故障的整体影响。

2.2 流量灵活调度

在单元化架构中，流量可以在不同的数据中心之间进行灵活切换和调度。这种灵活性使得系统能够根据实际需求调整资源分配，优化性能表现。例如，可以根据数据中心的负载情况动态调整流量分配，避免资源瓶颈和性能瓶颈的出现。

2.3减少跨数据中心服务调用

和数据库读写延迟

在单元化架构中，大部分的服务间调用和数据库读写操作都可在本地单元内完成，只有少数场景需要跨数据中心调用。这种设计减少了跨数据中心的网络延迟，提高了系统的响应速度和整体性能。

综上所述，单元化架构的优势使得系统更加健壮、可靠和高效，能够更好地满足金融业务稳定快速的发展需求。

单元化改造的所面临的挑战

单元化架构在为系统的高效稳定运行带来可观收益的同时，也面临以下几方面的挑战：

3.1 开发设计成本提升

单元化改造后，在联机交易的处理过程中无法完全避免跨单元事务的存在，因此需通过应用层的分布式事务控制来确保交易的完整性及数据的一致性，同时在交易异常的处理方面，需进行更为全面的考量与设计。对于批量处理，由于单元化系统与非单元化系统间存在数据传递、数据加载的任务流程，因此批量文件或批量数据拆分与聚合的过程与方法为批量服务调度的设计与实现带来了全新考验。

3.2 运维管理成本提升

在分布式架构中，数据处理过程流经多个组件和节点，导致数据复杂性及多样性增加，使得数据的采集、分析和可视化已变得较为困难，单元化改造则将进一步增加完整交易链路追踪的复杂度，如何高效的存储并分析链路数据将成为运维工作中的一个独立课题长期存在。同时对于运维过程中的投产变更实施、故障灾备切换工作，在涉及单元间的协同调度机制后，提升了在实施工艺控制及平台化管理方面的要求。

3.3 资源投入成本提升

最为直观的资源成本提升表现在设备数量方面，在单元化架构的设计与资源需求评估阶段，即可发现由一个大集群重构为单元化的多个小集群时，系统的可靠性与隔离性设计与硬件资源成本存在矛盾冲突，设备冗余量将随单元化设计被逐步放大，同时意味着整体资源利用率出现下降的情况。在部分应用场景上，也可能出现由于技术制约导致的资源部署增加的问题，其中较为典型的场景为数据统计维度无法与单元拆分维度保持一致时，数据需在单元外进行落库聚合处理。因此在单元化系统建设时，软硬件成本、人力成本、项目周期成本及后续维护成本均应纳入资源整体投入的评估范畴。

3.4 性能损耗提升

在系统资源无负载瓶颈的情况下，相比于传统的集中式架构，联机场景会普遍面临交易影响时间增加的问题。此问题也是分布式或单元化架构下获得了更高可靠性，更好扩展性的同时，引入复杂的服务调用关系及产品组件关系后所要付出的性能损耗成本，这部分成本单独从软硬件层面很难进行压缩控制，因此系统将面临业务流程、系统建模、代码逻辑上的全方位重构。

金融系统单元化架构面临的挑战涉及业务、技术、性能、安全、性能合规性等多个方面，需要统一的组织架构协同并综合考虑各种因素采取有效的措施来应对这些挑战。

单元化系统建设思考

银行核心系统在进行单元化改造的同时，除设计架构发生颠覆性变化外，通常还将伴随技术架构的全面国产化替代，应用程序、系统软件、硬件设备与金融企业私有云之间存在密切的适配关系，因此开发设计理念，测试验证方式，运营管理模式的转变与调整将贯穿系统改造建设的完整项目周期。

4.1 运营管理

1.平台建设

传统的管理平台早已无法跟上分布式技术的发展步伐，系统架构的复杂性及技术的多样性势必催生出新一代管理平台的建设需求，在建设过程中需确保三项关键能力的建设：一为可观测性体系建设，通过整合现有的告警类服务、链路类服务、日志类服务并统一各类日志的格式标准从而实现观测路径在业务层、应用层、技术设施层的打通串联，将交易和服务的观测在复杂架构下进行白盒化转变。二为持续发布能力建设，适配业务单元、公共单元、技术单元等不同类型单元特点，能够以自动化形式覆盖应用配置变更、应用程序变更以及数据库变更并通过灰度发布及滚动更新控制变更发布的影响及风险。三为系统韧性建设，前期对网关、全局路由、注册中心、配置中心、消息中心、应用服务、数据库服务等关键技术组件的技术特点和部署架构进行梳理，明确自愈边界，边界内以自动检测并触发的形式完成故障自愈，标准化处置动作。边界外则通过任务预编排的形式经人工决策并处罚，尽可能降低人工干预风险及处置时长。对于涵盖了“容器化”，“微服务”，“单元化”等技术架构的核心业务系统，上述三项关键能力的建设是实现运维管理支撑的基本要素。

2.资源可用率把控

多单元，多副本的分布式架构，设备数量相较于传统架构在数量级上存在显著增长，资源投入成本方面分为前期较易评估的设备采购成本及后期较难评估的持续运行成本。因此合理的部署架构是控制整个阶段成本的主要手段，业务规模、业务划分、数据规模、可用性需求影响着单元数量、分片数量以及副本数量，因此对于这些要素的评估决定了系统整体设备数量范围。在此基础上，系统内则应根据不同设备节点所承载的模块或组件的角色，进一步差异化设备规格控制成本投入。进一步的成本压缩可利用单元化架构特点，不同业务单元主备节点间允许以一定复用原则来充分利用相对空闲的备节点资源，此方式在常态运行的情况下既可确保故障半径，也可提升资源利用率，但需注意应在测试阶段评估好系统非常态运行时的容量使用情况。

4.2 可靠性建设

1.测试用例设计

单元化架构由于其复杂性及多样性，对传统的测试场景及测试方式造成了较大冲击，原有测例间的关联关系较为清晰，模拟方式无论从集群规模还是技术手段上均较易实现。但对于单元化改造项目，可靠性测试需分为三个阶段，首先对涉及的产品及系统架构设计有较为深入的理解，掌握技术架构中与可靠性相关的设计与配置。其次在架构不同层级建立独立的测例场景后识别架构上的潜在关联形成组合测例场景。最后实践运用新兴技术，以混沌工程的方式解决大规模集群下一定范围比例的资源占用、网络延迟、IO异常等故障模拟问题，实现自动化标准化测试并得到有效准确的测试结论。

2.监控预案验证

对于监控告警，将同样面临类型多、数量多、级联多的问题，对于告警阅读的感受为直观性的下降。因此借助测试过程对单元化架构的监控告警梳理也是系统上线后对于故障分析处置及时性的重要前置手段之一，通过甄别归纳的告警码组合才可及时有效的明确问题根因的排查范围与方向，与之呼应的即为预案的不断积累完善，其中复杂的处置动作还需向平台进行标准化转移屏蔽操作复杂度问题。

3.设备上架规划

需在IAAS层明确机柜、交换机、存储等底层基础设施部署方式及承载容量后，根据数据库产品的组件特点及部署架构，应用与数据库之间、单元与单元之间的关联关系，形成设备上架方案。方案设计的最主要目的为确保设备物理层不对系统逻辑层的故障爆炸半径预期产生破坏，否则单元化架构的可用性可能出现产生较大折损的情况发生。

4.3 系统效率

1.对象设计

由集中式架构向分布式架构改造的过程中，系统建模阶段数据库对象设计的重要性不言而喻，表的设计上通常会将分片表及复制表两类结合使用，其中分片表的设计关键在于分片规则及分片键的选择。业务场景、数据规模、数据特点等因素作为分片规则评估的参考依据影响着设计适配方向，对象间的模型关系及分片键的调整及使用影响着设计适配深度。两者共同决定了数据访问时跨分片操作的规避程度，即数据操作层面的执行效率。

2.程序运行

在PC服务器时代，程序的运行效率与NUMA架构特点关系密切，应用POD，数据进程均需根据设备的规格及NUMA数量进行绑核运行处理，尽量规避跨NUMA访问带来的额外性能损耗。与JVM相关的程序在处理器和内存使用也应通过测试明确ActiveProcessorCount、AlwaysPreTouch、LargePageSizeInBytes等参数的最佳实践。

3.交互调用

优化系统架构中的网络交互，维度可分为交互次数及交互时间两个方面。对于交互次数，集中在复杂交易处理过程中应用与数据库之间的调用，因此梳理并重检业务逻辑、代码逻辑，通过合理使用应用级缓存可在交互次数上产生较大幅度的收益。交互时间可考虑基于单元化架构优势，在单元级别按数据中心主备的模式设计部署架构，将各层级间的交互保持在同一中心内部，从而控制时延成本。

4.软硬件基线

服务器层面BIOS设置中的性能模式、CPU预取、内存刷新率；操作系统层面的内核版本选择；数据库层面与连接、buffer、IO相关的参数以及驱动中对于SQL预编译的设置；均对系统的运行效率存在一定影响，环境整体的软硬件基线确立是个复杂的测试过程，其中不乏会出现组合优化项产生负面效果的情况，因此需要较长的测试周期及严谨的测试流程控制才可确保达到最佳预期效果。

总结

商业银行核心系统单元化改造工作是一项复杂而艰巨的任务，其技术路线及解决方案需要持续探索、优化并改进，从而不断提升系统的稳定性和性能，提高故障的快速响应和处理能力。单元化改造过程也是大量新兴技术的应用实践过程，技术团队的建设与专业人才的培养也将促进技术业务间的融合创新转型，有效助力金融业务服务质量迈入新的阶段。

行业常见分布式架构

行业常见的分布式架构主要包含单活架构、双活架构和冷备架构。从容灾能力角度来看，双活架构和冷备架构均能做到应用级跨机房容灾，但是数据库因为使用了异步复制的技术，无法做到机房级RPO=0的容灾。再看灰度发布的能力，冷备架构和双活架构都只能做到机房级灰度发布，无法做到更细粒度的灰度发布。

蚂蚁单元化架构介绍

在介绍完行业常见的分布式架构后，我们来看一下蚂蚁的分布式架构发展历程，和单元化架构的详细介绍。

这是蚂蚁分布式架构发展历程。蚂蚁也经历了单活、同城双活、两地三中心，三个阶段。其中两地三中心是同城双活加一个冷备。随着蚂蚁业务和业务量复杂度的越来越高，业务对于基础架构的要求也越来越高，即扩展能力、容灾能力、灰度能力要求越来越高。最终蚂蚁发展到了单元化架构，将主要业务拆分单元即分片，装入不同的逻辑单元内，每个分片的数据库实现三地五中心部署即三地五中心的单元化架构。

首先我们来看一下蚂蚁单元化架构的整体架构设计，整体架构包含RZone、GZone和CZone。其中GZone部署的是无法拆分的数据和业务，GZone的数据和业务被RZone依赖，GZone全局只部署一份，而RZone部署的是可拆分的业务和对应的数据。每个RZone内的数据分片如图所示有五副本，实现三地五中心部署，每个分片内只有一个可写入的主副本，其余副本按照Paxos协议做数据强一致。每个RZone内实现业务单元封闭，独立完成自己的所有业务。而CZone的出现是因为GZone全局只有一份，不同城市的RZone可能依赖GZone服务和数据的时候需要远距离调用，延迟比较大，所以在每个城市部署一个CZone作为GZone的只读副本，为本城市的RZone提供服务。

绍完单元化架构的整体设计之后，我们从容灾、灰度发布、弹性三个方面详细看一下该架构的能力。

首先看容灾能力，容灾能力分为同城容灾和异地容灾，以图中所示为例，RZone1出现故障先看同城容灾能力，我们目标将RZone1切换至同城容灾RZone2。先做数据库分片切换，RZone1对应的分片为分片1，把分片1在RZone2的副本提升为主副本，数据库副本提升完毕后将RZone1的流量切换至RZone2，实现同城容灾RPO=0、RTO<1min。

再看异地容灾，同样以RZone1故障为例。目标切换至RZone3，先做数据库切换，分片1在RZone3的副本切换成主副本，完成后将RZone1的流量切换至RZone3，实现异地容灾，该过程RPO=0、RTO<1min。

接下来我们看弹性。弹性的背景是业务在大促、节假日等流量出现大幅上涨的过程，我们可以短期租借新的城市和新的IDC。如图所示，我们租借城市X的IDCX作为RZoneX，将RZone5的部分流量弹出至RZoneX，对应流量的数据也弹出至RZoneX内。在节假日大促结束之后，将RZoneX内的流量和数据弹回至RZone5，然后回收RzoneX，这样大幅节约了机房成本。

介绍完弹性之后，我们来看灰度能力。如图所示，我们将四个RZone（RZone1、RZone2、RZone3、RZone4）的业务和应用分为A、B组，日常A组和B组各承担50%的应用流量。在应用新版本发布时，我们将A组的流量全部切换至B组，此时在A组上部署新版本，部署完毕后将B组的流量按粒度切换至A组上，切换粒度等于数据分片的粒度。在切换的过程中可以做A组和B组的服务对比，如果发现A组的服务异常，可以快速将流量切换回B组。在A组服务一段时间后无异常发生，最终可以将B组的流量全部切换至A组，把B组的版本更新为新的版本，在整个切换的过程中实现了可灰度、可回滚、可监控。

我们再深入到架构内部，来阐释一下架构内关键模块是如何支撑该架构的。

首先我们看流量路由模块。流量路由模块的核心是将用户的uid信息和对应的Zone信息植入到cookie中，供流量路由模块做精准路由。我们以用户uid=68、RZone=RZ03为例来看流量路由模块是如何工作的，首次用户接入时cookie内无zone信息，流量接入模块会随即将该请求发到一个RZone内，如发到RZone1内，RZone1通过zoneClinet会准确计算该请求应发至RZone3，即通过RouteClinet将该请求发送。发送过程中将计算出的uid信息和对应的zone信息植入cookie内转发至RZone3，RZone3完成本次业务请求后将结果返回给用户，其后用户同意session内的其它请求，因为在cookie内已经有了准确的路由信息，会被流量路由模块准确的发至RZone3完成业务请求。

接着我们再看一下服务路由，服务路由分为本机房服务路由和跨机房服务路由调用。先看本机房服务路由，服务调用端向本机房服务注册中心订阅服务，发现服务地址后做本机房服务路由调用。再看跨机房服务路由调用，服务调用端向其他IDC的注册中心订阅服务地址，发现服务地址后做跨机房服务调用。

最后我们看数据是如何实现高可靠的。蚂蚁使用自研的分布式关系数据库OceanBase，每个分片的数据库做5副本部署，部署地域实现三地五中心部署，5副本中有3副本实现强一致，如图所示可以实现同城、IDC容灾和异地容灾。

单元化架构实践场景

介绍完蚂蚁单元化架构的主要概念即关键模块信息之后，我们看一下单元化架构在外部客户实施的一些案例。

第一个案例是一家城商行，它的业务系统、IT系统历史比较长，无法一步跨越到单元化架构，我们为其推荐了大GZone的模式，即把城商行的所有服务和数据不做拆分，直接装入一个GZone内，在GZone的基础上实现同城双活即应用同城双中心部署，数据库同城三中心部署，从而实现同城容灾能力，RPO=0、RTO<1min，但无法实现异地容灾能力，其可灰度能力和弹性能力都无法做到更细力度。

再看第二个区域银行的案例。我们为这家区域银行实现了同城单元化，即将这家区域银行的主要业务拆分成两个逻辑业务单元两个分片，将其装入一个城市的两个IDC内，在另外一个城市建设冷备，其数据库每个分片实现5副本部署，其中4副本在主城市两个中心内部署，1副本部署在了本机房内。该架构实现了同城容灾能力，同时也实现了细粒度的灰度能力和弹性能力，但同样无法实现异地容灾能力。

最后我们看一下蚂蚁网商银行的案例。网商银行实现了异地多活单元化完整的架构，网商银行的主要业务拆分成了4个分片，装入4个RZone内，这4个RZone分别部署在了两个城市内，各承担25%的流量，而数据库实现5副本三个城市部署。其中提供服务的两个地域两个城市部署4副本，远端部署1副本。该架构实现了同城容灾、异地容灾，同时也实现更细粒度的灰度能力和弹性伸缩能力。