王敏强：迎难而上，打造业务发展新引擎——回顾福建海峡银行新一代核心系统建设之路

福建海峡银行于2021年2月开始新一代核心系统建设，开展业务和技术架构双升级。在业务上，以金融服务场景为驱动，重塑交易流程，采用“步进式”串联传统单独交易，整合对客渠道，实现线上线下协同；在技术上，以分布式架构为支撑，构建自动故障转移与恢复、多中心多活等能力，支持弹性伸缩和快速扩展。

该系统集国内多家优秀厂商之所长，从架构规划到底层设计，从项目组织到客户体验，无不体现了科技飞速发展时代一家中小银行的工匠精神。从架构规划领域来看，系统采用“新一代分布式核心+分布式数据库”框架，融合业内领先的业务和技术架构，在保障系统高可用、高扩展、高性能的同时，满足银行海量客户数据与业务爆发式增长要求，解决了集中式架构的性能瓶颈，以灵活的产品、定价及营销抢占市场先机。从底层设计角度出发，系统在应用层采用微服务架构，以领域建模理论为基础，将系统按照业务领域与组织架构颗粒度解耦，划分为功能相对独立且互不影响的组织单元，如账务、公共、历史等微服务群，每个微服务群由一系列职责单一、高内聚的业务服务组成，可根据业务架构和组织架构要求灵活调整，支持独立、组合部署及升级，实现快速研发迭代。从项目建设范围来看，项目关联系统分为渠道平台、前台应用、中台服务、后台应用、企业服务等五大类，涉及新建或重构的系统包括核心、柜面、会计核算、企业服务总线等，由于核心和柜面系统重构，相关业务流程优化，对外提供的交易服务和业务数据发生变化，近百套交易类和数据类系统需同步改造。从数据迁移方式来看，迁移操作对象是系统存量数据，迁移时间控制以及数据准确性至关重要，为确保新、旧系统数据迁移成功，需要综合考虑迁移逻辑、数据一致性、迁移性能和回退方案这四个关键要素，迁移主要难点在于旧系统表梳理、中间表映射、利息补计提、迁移规则确认、新旧参数映射、数据清理补录等方面。

我们曾调研过城商行新一代核心系统的实施周期，普遍在16到18个月左右，而海峡银行仅用时14个月，项目建设过程的顺畅，与监管单位的大力支持、金融同业的慷慨帮助、本行党委的高度重视密不可分。此外，攻克三大难关是该项目成功的关键之匙。

其一：分布式数据库的选型设计

中国人民银行《金融科技（FinTech）发展规划（2019—2021年）》提出“加强分布式数据库研发应用”的发展目标，要求落实数字化架构转型和新基建战略。伴随云计算、大数据、人工智能等新兴技术涌现，银行业务量、数据量也呈现爆发式增长，对应用系统的数据库容量、并发能力、容灾能力提出了更高的要求。基于IOE的传统集中式数据库架构难以满足移动互联网时代数据量剧增、高并发业务和高客户量要求，在系统性能和扩展能力等方面力不从心，同时数据处理所面对的数据类型、数据规模、计算速度愈发严苛，而云计算通过存算分离、资源弹性动态分配打破了传统计算场景瓶颈，符合当前数据处理需求，也推动了分布式数据库的发展前景。以前银行核心业务主要采用“大/小型机+集中式数据库”方案，随着业务从传统集中式结构向服务化、分散化体系演进，利用分布式计算、内存计算等新技术的分布式数据库能够很好地解决性能扩展问题，采用多种模式实现数据分散存储，将压力分散到不同服务器，支持通过持续增加存储或计算节点来实现弹性升级，克服了集中式数据库的诸多缺陷。

为满足安全可控的国家战略要求，顺应银行IT架构转型升级趋势，缓解IT成本控制压力，海峡银行早在2019年就启动了金融级分布式数据库应用研究。对于首次应用分布式数据库而言，客观上存在一定的风险点和技术难点，此前出于安全考虑，分布式数据库大多被应用在互联网核心和外围系统，在业务种类繁多、流程相对复杂的传统核心中案例较少，需要慎重考虑如何妥善解决分布式数据一致性、事务一致性、高可用容灾验证等，同时保证在高并发、高交易量场景下的弹性扩容能力，以及如何构建新型运维体系等方面问题。为此，我们采取了“小步快跑、逐步推广”的策略，2020年选择了客户量多、并发值大、场景丰富、响应时效要求高的手机银行和个人网银作为首批试点应用，历时4个月完成分布式数据库基本功能测试、高可用容灾验证和性能测试，充分掌握分布式数据库的应用要点，通过梳理业务流程，合理分散数据，初步构建分布式数据库应用维护体系，为后续核心系统应用奠定基础。相比手机银行和个人网银系统，核心重构的重要性和复杂度不言而喻，因此，在核心系统应用分布式数据库需要考虑以下问题。

1.如何多层次保障核心系统的数据一致性。数据库层面，基于信创数据库TDSQL具备MySQL Binlog严格有序性，结合Raft协议设计思想实现强同步复制机制，保障数据的一致性；应用设计方面，在分布式数据库容灾运行机制的基础上，采用应用日志应急补偿方式，保障数据的一致性。

2.如何保障业务连续，实现自动故障转移与恢复。数据库层面，TDSQL高可用基于多个数据库服务协同机制，当数据库节点发生故障时，剩余节点可立即接管；TDSQL还支持故障自动恢复，当承载分片的物理节点出现故障时，调度系统自动尝试恢复，若无法恢复，将在30分钟内自动申请新资源，通过备份重建节点并自动加入集群，确保实例保持完整的高可用架构；海峡银行核心系统采用两地三中心集群部署方式，实例的主机和从机分处不同机房，数据通过专线网络实时复制，本地为主机，远程为从机，优先访问本地节点，若本地实例发生故障或访问不可达，则访问远程从机。此外，中心级别的故障，可实现自动切换，极端情况下可手工切换至异地灾备机房，从而在极短时间内恢复数据库。应用层面，采取“双中心对等部署、交易链路单中心贯穿到底”的策略，避免跨中心交易带来的流量风暴，应用与数据库的通讯在驱动层具有连接失败转移和自动重连机制，数据库接入层采用双中心负载均衡模式，实现同中心内优先访问、中心异常时跨中心访问。

3.如何确保数据迁移一次性完成，数据完整时间可控。数据迁移不只是简单的数据平移和业务平移，需要制定数据清理和补录的原则，在整个迁移测试验证过程中持续对迁移数据源存在的非法或例外数据进行清理，补录缺失数据，提升数据质量。在数据库迁移过程中，采用“数据少落地、多表并行处理”的工作机制缩短整体迁移时长。

4.如何保障高并发场景下的数据库性能。分布式数据库保证性能的主要手段是将数据处理要求分散到多个处理节点，对核心系统进行分层解耦，确定应用层、服务层及数据层的边界，以适应系统弹性扩展需求；同时对数据进行分区，按照业务访问逻辑，结合时间做Range分区或某个特征值做Hash分区，保持每个分区的大小适中，才能更好地实现系统负载均衡、合理调度以及快速扩展，确保每一次的数据库交互快而精确。

5.如何识别热点账户并加以处置。数据库层面，识别热点账户信息，并独立存储热点账户表，同步应用TDSQL的热点更新功能。应用层面，主要采用两个手段：首先是参数管理，将热点账户信息纳入账户参数表统一管理；其次是建立异步处理机制，判定热点账户后先处理明细数据插入，异步进行汇总明细入账操作。

其二：微服务应用的全面落地

在系统架构方面，微服务增加了设计、研发和运维难度；服务能力方面，核心系统对业务连续性和事务一致性有极高的要求，需支持海量高并发场景；关联影响方面，核心与外围系统存在紧密交互关系，内外部关联极其复杂，需要重点对系统设计、性能优化等方面技术攻坚。

1.如何确定分布式核心选型。面对“微服务”与“微服务+单元化”两种主流分布式架构，需要深入分析扩展性、灰度发布、故障隔离等多维度因素以确定选型方向。我们选择微服务架构的原因是：能够更好地实现应用解耦与灵活部署，同时系统具备很强的灵活性，服务间的访问模式可通过参数动态调整，组成多种部署架构，支持从“微服务”到“微服务+单元化”模式的快速切换。此外，除了从业务维度拆分微服务，还兼顾了组织维度的拆分原则，应用开发团队可以尽可能地实现自闭环研发活动，大大降低组织协同成本并提高开发效率。

2.如何实现分布式事务一致性。由于网络延迟、节点故障、数据并发等因素，事务的实时一致性难以保证，需要应用和数据库在设计层面充分考虑容错性，另外还可适当考虑在应用方面牺牲部分性能，采用传统集中式For update方式进行唯一性控制。

3.如何保证数据高效访问。针对微服务架构下多节点部署的特点，我们设计了数据库与缓存同步、信息发布同步等机制，确保数据的高效访问与实时更新。

4.如何降低性能调优难度。分布式平台提高了系统的吞吐量，但也增加了交易链路，对系统性能调优提出了新的课题。核心系统集成性能统计日志工具，直观展示各交易耗时分布情况，性能堵点一目了然，在一定程度上可以降低调优难度。

其三：能力储备和观念改变

1.技术能力的提前储备。分布式架构方兴未艾，市场上相关技术栈的人员储备情况存在明显短板，尤其是经验丰富、技术能力突出的DBA非常欠缺，为此一方面要“内部挖潜”，加强自有队伍建设，补充高素质新人，引进关键领域人才，同时通过原厂培养、实验室培训、重大项目实践等多措并举，加快人员专业能力提升；另一方面，借助“外部协作”，加强对外沟通交流，在重大系统架构设计、关键节点调优、重要保障期间与原厂密切协作。此外，我们非常注意同步深化与原厂的合作机制，共同孵化分布式数据库生态体系，推动区域服务能力提升。

2.思想观念的全面重塑。长期以来，为保证系统和客户资金安全，银行以稳为主，通常选用业内较为成熟、稳定的技术手段（以IOE为代表的经典商用软件和集中式架构）来保证系统交易的实时一致性，同步培养了大批熟悉相关应用和传统架构的技术人员，也造就了一些根深蒂固的观念。分布式架构与传统架构相比，在设计、开发、运维、管理等方面都需要具备焕然一新的思维，这对技术人员的思想理念产生了巨大的冲击。以运维为例，核心系统进行微服务拆分后，运维管理应用数量大幅增加，交易链路需要跨多个微服务应用完成，对业务监控和定位提出了挑战；以往核心系统采用被动运维方式，随着业务不断发展，系统面临互联网流量冲高、业务快速上线的要求，为应对多方冲击需要从被动运维转向主动运维；技术进步驱动核心系统灾备升级，同城灾备切换RPO=0成为系统建设目标之一。这些都需要一个“脱胎换骨”的转变过程，来打破此前固有思维惯性和工作方式，才能有效应对新技术带来的新挑战。

从实践效果来看，我们已经实现核心系统的同城双活部署（RTO分钟级），具备7×24小时不间断服务、双中心独立运营能力，支持弹性扩容和产品快速发布。后续我们将在应用技术和架构设计等方面持续探索，进一步提升系统先进性。

首先是全栈信创的深入实施。信创是国家重大战略，目前我们完成了核心部分节点的自主芯片服务器替换，实现应用层面信创服务器和X86服务器双轨并行，未来的着力点主要在于确保核心系统具备全面替换自主芯片服务器的能力。

其次是单元化模式的逐步落地。当客户数据量接近数据库所能承载的上限时，单元化架构将成为后续核心系统建设的重要方向之一。通过单元化模式，将核心系统拆分成若干单元，在单元内实行闭环处理，互不影响，降低无效的横向流程，提升性能和稳定性。核心系统整体架构包含RZone、GZone和CZone，大大提高单元的可靠性，并降低东西向数据同步和服务外调几率。我们期待着单元化模式能够全面落地，并在实践中持续完善。

时至今日，分布式、微服务等技术正不断被金融同业广泛运用，集中式架构逐步被分布式架构取而代之，这也是银行金融科技能力发展的必然趋势。福建海峡银行作为城商行分布式核心系统的先行者之一，也希望能够借此机会为广大同业提供借鉴和参考。

（此文刊发于《金融电子化》2024年6月下半月刊）