于树文，郑皓广 2024-11-23 07:15 广东
通过光大银行核心系统主机下移、上云改造项目的开展，分析和总结在架构设计及测试验证阶段的应对方法。
随着金融科技的快速发展，银行核心系统面临着更高的处理能力、扩展能力及业务连续性的要求与挑战。为应对这些挑战，许多银行开始考虑对其核心系统进行单元化改造。本文首先分析了传统银行核心系统存在的问题以及单元化改造的必要性，然后详细阐述了单元化改造的设计思路、实施过程以及可能遇到的挑战，并通过光大银行核心系统主机下移、上云改造项目的开展，分析和总结在架构设计及测试验证阶段的应对方法，希望对金融系统架构转型工作的推广落地提供一定的借鉴意义。
引言
银行核心系统是商业银行运作的基础，承载着处理交易、管理资产、风险控制等重要职责。然而，随着业务量的不断增长、技术的持续迭代以及监管要求的提高，传统银行核心系统的弊端逐渐显现，如性能瓶颈、可扩展性差、灵活性不足等。这些问题不仅影响了银行业务的快速发展，还可能给银行的安全运营工作带来诸多风险。
单元化改造作为一种新兴的架构优化方法，通过将系统拆分为多个独立的单元，实现了系统的横向扩展和灵活性提升。每个单元负责处理特定的业务逻辑或业务范围，可以在单元局部进行独立的部署、升级和维护。这种改造方式不仅可以提高系统的处理能力，还可以降低系统的复杂性，提高系统的稳定性和可维护性。
本文旨在深入研究银行核心系统的单元化改造，分析改造的必要性、设计思路、实施过程以及可能遇到的挑战。并通过改造项目工作的实践总结，为商业银行提供有益的参考。
传统银行核心系统问题分析
传统的银行核心系统主要存在以下问题：
1、性能瓶颈问题
随着业务量的不断增长，传统银行核心系统的处理能力逐渐达到瓶颈，难以满足业务高峰期的需求。集中式架构下通常采用垂直扩展的方式以提升单台服务器的性能来应对业务增长。然而这种方式的可扩展性受于硬件资源的限制且无法有效解决热点资源争用问题，在系统长时间的运行过程中伴随着由于性能问题导致的交易延迟、系统崩溃等问题，在客户体验及客户满意度方面均存在一定影响。
2、灵活性问题
在传统核心系统的集中式部署架构下，业务逻辑和数据处理紧密耦合，导致系统灵活性差，升级维护困难。新业务需求引入的过程中可能需要对系统进行较大规模的改动，使得系统难以快速调整以适应业务变化并增加了系统的运行风险。
3、可靠性问题
集中式架构中系统的服务及数据均较为集中，对应的节点或组件出现故障时，整个系统都将受到影响，甚至可能导致系统完全不可用。这种单点故障问题的严重性在于它对整个系统的稳定性和可用性造成了威胁，而集中式架构下的灾备恢复体系已无法支撑客户对核心业务服务连续性的需要。
单元化改造的必要性
银行系统技术架构改造的需求主要源自业务的快速发展和流量爆发性增长，以及传统集中式架构存在的性能瓶颈、扩展性问题、单点故障以及安全风险等问题。上述问题通过标准的分布式架构可得到较好的解决，但分布式技术产品通常均由的多组件构成，在此特点下，仍有可能出现关键组件故障导致整体服务中断的情况出现，同时也无法避免可用区级别或数据中心级别故障时对系统可用性带来的整体影响。
在分布式技术的基础之上，单元化架构的核心思想是将复杂的系统划分为多个独立的单元，每个单元都能独立处理业务，实现业务的解耦和自治。这种架构模式使得系统能够在多个地理位置分散的数据中心进行部署和运行，每个数据中心可承担部分单元业务的处理任务，因此这种架构模式带来了以下几个方面的优势：
1、异地多活与故障容灾能力
单元化架构允许系统在多个数据中心同时运行，每个单元都能够处理真实的业务流量。当某个数据中心发生故障时，其他数据中心的单元可以迅速接管故障单元的流量和数据，保证了业务的连续性和高可用性。这种能力有效减少了故障对用户的打扰和业务的中断，即使无法完全切换流量，也能将故障的影响范围限制在部分用户，降低了故障的整体影响。
2、流量灵活调度
在单元化架构中，流量可以在不同的数据中心之间进行灵活切换和调度。这种灵活性使得系统能够根据实际需求调整资源分配，优化性能表现。例如，可以根据数据中心的负载情况动态调整流量分配，避免资源瓶颈和性能瓶颈的出现。
3、减少跨数据中心服务调用和数据库读写延迟
在单元化架构中，大部分的服务间调用和数据库读写操作都可在本地单元内完成，只有少数场景需要跨数据中心调用。这种设计减少了跨数据中心的网络延迟，提高了系统的响应速度和整体性能。
综上所述，单元化架构的优势使得系统更加健壮、可靠和高效，能够更好地满足金融业务稳定快速的发展需求。
单元化改造的所面临的挑战
单元化架构在为系统的高效稳定运行带来可观收益的同时，也面临以下几方面的挑战：
1、开发设计成本提升
单元化改造后，在联机交易的处理过程中无法完全避免跨单元事务的存在，因此需通过应用层的分布式事务控制来确保交易的完整性及数据的一致性，同时在交易异常的处理方面，需进行更为全面的考量与设计。对于批量处理，由于单元化系统与非单元化系统间存在数据传递、数据加载的任务流程，因此批量文件或批量数据拆分与聚合的过程与方法为批量服务调度的设计与实现带来了全新考验。
2、运维管理成本提升
在分布式架构中，数据处理过程流经多个组件和节点，导致数据复杂性及多样性增加，使得数据的采集、分析和可视化已变得较为困难，单元化改造则将进一步增加完整交易链路追踪的复杂度，如何高效的存储并分析链路数据将成为运维工作中的一个独立课题长期存在。同时对于运维过程中的投产变更实施、故障灾备切换工作，在涉及单元间的协同调度机制后，提升了在实施工艺控制及平台化管理方面的要求。
3、资源投入成本提升
最为直观的资源成本提升表现在设备数量方面，在单元化架构的设计与资源需求评估阶段，即可发现由一个大集群重构为单元化的多个小集群时，系统的可靠性与隔离性设计与硬件资源成本存在矛盾冲突，设备冗余量将随单元化设计被逐步放大，同时意味着整体资源利用率出现下降的情况。在部分应用场景上，也可能出现由于技术制约导致的资源部署增加的问题，其中较为典型的场景为数据统计维度无法与单元拆分维度保持一致时，数据需在单元外进行落库聚合处理。因此在单元化系统建设时，软硬件成本、人力成本、项目周期成本及后续维护成本均应纳入资源整体投入的评估范畴。
4、性能损耗提升
在系统资源无负载瓶颈的情况下，相比于传统的集中式架构，联机场景会普遍面临交易影响时间增加的问题。此问题也是分布式或单元化架构下获得了更高可靠性，更好扩展性的同时，引入复杂的服务调用关系及产品组件关系后所要付出的性能损耗成本，这部分成本单独从软硬件层面很难进行压缩控制，因此系统将面临业务流程、系统建模、代码逻辑上的全方位重构。
金融系统单元化架构面临的挑战涉及业务、技术、性能、安全、性能合规性等多个方面，需要统一的组织架构协同并综合考虑各种因素采取有效的措施来应对这些挑战。
单元化系统建设思考
银行核心系统在进行单元化改造的同时，除设计架构发生颠覆性变化外，通常还将伴随技术架构的全面国产化替代，应用程序、系统软件、硬件设备与金融企业私有云之间存在密切的适配关系，因此开发设计理念，测试验证方式，运营管理模式的转变与调整将贯穿系统改造建设的完整项目周期。
1、运营管理
1）平台建设
传统的管理平台早已无法跟上分布式技术的发展步伐，系统架构的复杂性及技术的多样性势必催生出新一代管理平台的建设需求，在建设过程中需确保三项关键能力的建设：
一为可观测性体系建设，通过整合现有的告警类服务、链路类服务、日志类服务并统一各类日志的格式标准从而实现观测路径在业务层、应用层、技术设施层的打通串联，将交易和服务的观测在复杂架构下进行白盒化转变。
二为持续发布能力建设，适配业务单元、公共单元、技术单元等不同类型单元特点，能够以自动化形式覆盖应用配置变更、应用程序变更以及数据库变更并通过灰度发布及滚动更新控制变更发布的影响及风险。
三为系统韧性建设，前期对网关、全局路由、注册中心、配置中心、消息中心、应用服务、数据库服务等关键技术组件的技术特点和部署架构进行梳理，明确自愈边界，边界内以自动检测并触发的形式完成故障自愈，标准化处置动作。边界外则通过任务预编排的形式经人工决策并处罚，尽可能降低人工干预风险及处置时长。
对于涵盖了“容器化”，“微服务”，“单元化”等技术架构的核心业务系统，上述三项关键能力的建设是实现运维管理支撑的基本要素。
2）资源可用率把控
多单元，多副本的分布式架构，设备数量相较于传统架构在数量级上存在显著增长，资源投入成本方面分为前期较易评估的设备采购成本及后期较难评估的持续运行成本。因此合理的部署架构是控制整个阶段成本的主要手段，业务规模、业务划分、数据规模、可用性需求影响着单元数量、分片数量以及副本数量，因此对于这些要素的评估决定了系统整体设备数量范围。在此基础上，系统内则应根据不同设备节点所承载的模块或组件的角色，进一步差异化设备规格控制成本投入。进一步的成本压缩可利用单元化架构特点，不同业务单元主备节点间允许以一定复用原则来充分利用相对空闲的备节点资源，此方式在常态运行的情况下既可确保故障半径，也可提升资源利用率，但需注意应在测试阶段评估好系统非常态运行时的容量使用情况。
2、可靠性建设
1）测试用例设计
单元化架构由于其复杂性及多样性，对传统的测试场景及测试方式造成了较大冲击，原有测例间的关联关系较为清晰，模拟方式无论从集群规模还是技术手段上均较易实现。但对于单元化改造项目，可靠性测试需分为三个阶段，首先对涉及的产品及系统架构设计有较为深入的理解，掌握技术架构中与可靠性相关的设计与配置。其次在架构不同层级建立独立的测例场景后识别架构上的潜在关联形成组合测例场景。最后实践运用新兴技术，以混沌工程的方式解决大规模集群下一定范围比例的资源占用、网络延迟、IO异常等故障模拟问题，实现自动化标准化测试并得到有效准确的测试结论。
2）监控预案验证
对于监控告警，将同样面临类型多、数量多、级联多的问题，对于告警阅读的感受为直观性的下降。因此借助测试过程对单元化架构的监控告警梳理也是系统上线后对于故障分析处置及时性的重要前置手段之一，通过甄别归纳的告警码组合才可及时有效的明确问题根因的排查范围与方向，与之呼应的即为预案的不断积累完善，其中复杂的处置动作还需向平台进行标准化转移屏蔽操作复杂度问题。
3）设备上架规划
需在IAAS层明确机柜、交换机、存储等底层基础设施部署方式及承载容量后，根据数据库产品的组件特点及部署架构，应用与数据库之间、单元与单元之间的关联关系，形成设备上架方案。方案设计的最主要目的为确保设备物理层不对系统逻辑层的故障爆炸半径预期产生破坏，否则单元化架构的可用性可能出现产生较大折损的情况发生。
3、系统效率
1）对象设计
由集中式架构向分布式架构改造的过程中，系统建模阶段数据库对象设计的重要性不言而喻，表的设计上通常会将分片表及复制表两类结合使用，其中分片表的设计关键在于分片规则及分片键的选择。业务场景、数据规模、数据特点等因素作为分片规则评估的参考依据影响着设计适配方向，对象间的模型关系及分片键的调整及使用影响着设计适配深度。两者共同决定了数据访问时跨分片操作的规避程度，即数据操作层面的执行效率。
2）程序运行
在PC服务器时代，程序的运行效率与NUMA架构特点关系密切，应用POD，数据进程均需根据设备的规格及NUMA数量进行绑核运行处理，尽量规避跨NUMA访问带来的额外性能损耗。与JVM相关的程序在处理器和内存使用也应通过测试明确ActiveProcessorCount、AlwaysPreTouch、LargePageSizeInBytes等参数的最佳实践。
3）交互调用
优化系统架构中的网络交互，维度可分为交互次数及交互时间两个方面。对于交互次数，集中在复杂交易处理过程中应用与数据库之间的调用，因此梳理并重检业务逻辑、代码逻辑，通过合理使用应用级缓存可在交互次数上产生较大幅度的收益。交互时间可考虑基于单元化架构优势，在单元级别按数据中心主备的模式设计部署架构，将各层级间的交互保持在同一中心内部，从而控制时延成本。
4）软硬件基线
服务器层面BIOS设置中的性能模式、CPU预取、内存刷新率；操作系统层面的内核版本选择；数据库层面与连接、buffer、IO相关的参数以及驱动中对于SQL预编译的设置；均对系统的运行效率存在一定影响，环境整体的软硬件基线确立是个复杂的测试过程，其中不乏会出现组合优化项产生负面效果的情况，因此需要较长的测试周期及严谨的测试流程控制才可确保达到最佳预期效果。
总结
商业银行核心系统单元化改造工作是一项复杂而艰巨的任务，其技术路线及解决方案需要持续探索、优化并改进，从而不断提升系统的稳定性和性能，提高故障的快速响应和处理能力。单元化改造过程也是大量新兴技术的应用实践过程，技术团队的建设与专业人才的培养也将促进技术业务间的融合创新转型，有效助力金融业务服务质量迈入新的阶段。
作者丨于树文、郑皓广 编辑丨肖琦
来源丨匠心独运维妙维效（ID：gh_54f52b20027d）
dbaplus社群欢迎广大技术人员投稿，投稿邮箱：editor@dbaplus.cn
