【专家说】云端核心重塑：银行亿级账户核心转型全解密

云端核心重塑：银行亿级账户核心转型全解密 导语 本文系统梳理了腾讯在银行核心系统领域的建设经验。以中国人民银行《金融科技发展规划（2022-2025年）》政策为指引，重点围绕银行核心系统分布式转型的实施背景、面临挑战和架构设计展开深入探讨，并详细论述核心系统与云计算技术的融合路径及上云策略。期待在金融核心系统大规模转型的关键时期，为读者提供新一代核心系统的建设思路，助力金融科技自主创新实践。 1.核心转型的机遇与挑战 在当前全球产业向数字化升级的关键时期，我国科技核心技术受制于人，这种现状对我国经济持续高质量发展提出了严峻考验。未来几年，我国IT产业都将在基础硬件、基础软件、行业应用软件、信息安全等诸多领域迎来新的机遇与挑战。金融行业作为国家重点行业，实现IT基础设施的自主创新势在必行。核心系统作为银行最重要的业务系统，首当其冲成为实现国产自主创新的关键指标。 银行的核心系统包含了一个银行最为重要的核心业务：存款、贷款、汇款，以及围绕这三项业务开展所需的一系列支撑服务，如：产品、定价、会计核算等等。与互联网业务有所不同，银行核心系统迭代周期非常长，大部分情况下不会动核心系统。因为银行是受监管强管控的行业，通常这类系统都承担着监管指标，其必须保障极高的稳定性与性能。此外，核心系统对于技术选型也是格外谨慎，传统的银行核心系统大多基于IBM主机运行，以DB2或Oracle作为数据库。应用层大多基于Cobol+Tuxedo中间件来开发，标准的集中式技术栈。整体架构软硬件耦合较深，技术体系相对封闭，系统迭代速度也慢，优点是稳定。但在当今业态下，系统的灵活性与性能容量均面临挑战。这两年来金融行业核心系统面临大面积转型，规模之大，涉及范围之广可谓史无前例，对于上下游的科技企业带来了巨大的挑战与机遇。 2.核心系统架构转型与设计 腾讯依托多年自身业务经验，沉淀了名为“海量服务之道”的架构设计方法，随后扩大到财付通、微信支付、红包等场景中。并在2015年成功帮助微众银行分布式核心系统上线，在银行业率先实现了“DCN数据中心单元化”的架构理念。如图1所示，微众银行的核心系统创新地将核心账务应用与数据打包计算，业务流量经GNS路由转发至各DCN单元处理。这是当时国内银行的核心系统中首个单元化案例。 2.1 银行核心系统架构蓝图 2018年CSIG成立，正式开启助力各行业数字化转型升级。在金融赛道，腾讯云联合众多合作伙伴，从大量银行传统核心系统中提炼关键技术能力，结合专家经验经过多轮迭代，最终形成新核心在分布式架构下应具备的技术要求。并遵循高内聚低耦合设计思想，结合拆分、编排、摒合等设计理念，形成支撑分布式核心系统的各大技术组件，进而演变成银行分布式系统架构蓝图。 如图2.1所示，自上而下分为SaaS核心应用层、PaaS云原生平台和IaaS云平台。左侧为研效体系与测试体系，右侧为运维体系和安全体系。它们共同形成新核心所需的整体能力框架。 1.SaaS层包括了银行核心系统的应用域，如：存贷、支付结算、银行卡、核算及公共服务等。以及为支持上述领域所需的能力中心和7*24等公共机制。 2.PaaS层呈现三级能力分化，其中APaaS聚焦通用业务场景封装，构建交易框架、参数管理等标准化模块并抽象云产品接口，但部分组件与云厂商原生能力存在重合需边界厘清；IPaaS强化全链路集成治理，应对云上云下交错环境中的协议冗杂难题，通过异构系统协同形成一体化底座；GPaaS作为技术基座，专注云原生中间件供给，为分布式架构提供容器化、微服务等基础支撑。这三层架构中，上层应用开发依赖底层技术赋能，在生态合作时，需突破产品间的能力重叠与协议互通等实施难点，形成既解耦又协同的技术支撑体系。 3.IaaS层则主要包括了云平台的计算、存储、网络、资源编排、多云管理等底座能力，以及基础安全能力。 4.传统的研发工艺已经很难满足大规模复杂项目的协同管理。在研发效能体系中，不仅要包含DevOps，同时还需集成项目管理和质量管控体系。并以需求为抓手，贯穿设计、开发、测试、安全、发布、投产全生命周期。每个环节形成有效的反馈机制，确保每一轮迭代都能有效量化生产数据，实现精益化管理。 5.从传统集中式架构向分布式架构演进过程中，"面向弹性容错"的设计思想贯穿始终。测试体系需融入混沌工程能力，针对分布式架构下故障率偏高的基础设施和不稳定网络因素进行预验证，来提升应用系统整体的容错和自恢复能力，倒逼应用实现"弹性"。 6.分布式下的运维体系，从传统的“快速发现->快速定位->快速修复”转变为“快速发现->快速隔离->快速恢复”。在大规模集群中，标准服务器的硬件故障和网络抖动频发，优先需要保障业务连续性，自动化的运维能力是核心。同时结合数据分析来实现故障提前感知和预防是未来的主要目标。 2.2 三维六阶模型 银行核心系统的转型一般都是一把手挂帅的重点工程，是需要经过行业调研、现状分析、技术论证来论证可行性。腾讯在经过多家银行核心系统的建设之后，总结归纳了三个维度：业务分析维度、技术架构维度、建设模式维度。每个维度下可分为两个演进阶段： 1.业务分析两个阶段：“需求分析”和“业务建模”； 2.技术架构两个阶段：“微服务架构”与“单元化架构”； 3.建设模式两个阶段：“敏捷模式”与“IT工艺”。 首先在需求侧，传统垂直模式存在业务与技术沟通壁垒，亟需通过"业技融合"打通全行视角，实现需求精准传递与技术合理承接；其次架构层面，微服务体系虽解构了单体系统，但在处理分布式事务、跨区性能优化等企业级场景时仍需增强健壮性；最后在实施维度，敏捷开发需突破超大规模协作治理困境，同时在服务拆分粒度与生产稳定性间寻求平衡，既要践行解耦理念又要保障系统安全。三者共同指向大型银行在超大规模交易场景中，核心系统重构所面临的理论标准与实践落地的适配难题。 银行核心系统实施呈现两级路径分化：中小银行以产品倒推的自下而上模式为主，约70%需求基于厂商标准化方案，而30%进行定制，依托厂商固化产品能力降低研发成本和交付压力，匹配投入有限的银行，而大型银行则坚持顶层设计的自驱动路径，要求厂商完全定制开发，追求2.0高阶架构及工程工艺的革新。目前六大行已全面实现业务建模、单元化架构和先进工艺的三角突破，头部股份行也普遍具备单元化能力，部分正在迁移高阶模式。行业格局由此裂变为标准化产品驱动与科技引领双轨并行。 新核心系统的规划本质上就是基于银行现状，围绕三维六阶进行逐步论证、确定新核心在业务、技术、工艺三个方面的决策过程。这个组合决定了未来新核心的业务架构和技术架构的不同呈现。 2.3 六大设计要点 围绕三维六阶的模型，咨询公司会更多侧重在业务维度，核心系统的供应商侧重技术和工艺两个维度，云厂商侧重技术维度。所以，在新核心架构蓝图(图2.1)中，APaaS、IPaaS、GPaaS三个领域，云厂商与ISV会有一定重叠，需错位协同，探索生态互补的合作模式。 2.3.1 数据切分策略 第一步是要确定分布式系统的数据切分策略，这里就包括了切分维度、分布规则、扩容策略、容量评估四个重要方面。 1.切分维度：决定了某一维度的数据会存放在同一数据分片中，比如客户维度、机构或省市维度等。 2.分布规则：决定了数据存放到各个分片时采用的规则，比如按范围段存放，或者按Hash散列存放。 3.扩容策略：决定了当数据库或数据分片到达容量或性能瓶颈时，采取何种方式来扩容。业界有两种常见的做法：一种是通过自研工具来扩容，另一种是通过数据库产品的能力来实现扩容，具体取决于技术架构和产品选型。如果数据库采用了多个独立的集中式数据库，那么就更适合采用自研的扩容工具。而如果采用了一个分布式数据库实例，并且内部划分了多个不同的数据分片，那么就可以通过数据库自身的能力来实现扩容。因此，在确定扩容策略时，需要仔细考虑数据库的结构和特性，以便选择最合适的扩容方案。 4.容量评估：容量评估的目的是基于当前整体业务量，并预测未来两年到五年的增长量。在此基础上，结合数据库产品自身的容量参数，确定数据分片数量及分片配置规格。对核心这类稳态系统而言，评估时应尽量做好冗余规划，以减少扩容场景的出现。 2.3.2 技术架构策略 其次，需要确认的是分布式系统的技术架构策略，包括：交易处理策略、分布式事务处理策略、应用侧扩容策略、聚合查询策略、灰度发布策略。 1.交易处理策略：指的是一次交易从网关进入到内部应用集群时，应用集群之间服务调用的机制和故障处理策略。这包括点对点直达调用还是通过消息传递调用，对应的负载均衡策略，以及应用实例故障时的恢复或降级策略等。 2.分布式事务策略：指的是采用分布式架构后，由于应用或数据拆分带来的交易一致性问题。由于分布式架构下的场景较为复杂，要先判断不同场景应是由应用侧来保障事务，还是交由分布式数据库来保障。需要注意的是，任何一种事务处理机制都会存在损耗和一定的场景限制。在指定分布式事务策略时，需要结合实际情况进行综合考虑和评估。 3.应用侧扩容策略：指针对分布式集群中的应用扩容升级。对于运行在云平台上的核心应用，可以通过云平台的自动扩缩容能力来实现，但前提是应用均为无状态实例且对调度友好。对于有状态的应用实例，可通过预先设置脚本的方式来实现扩缩容。就银行核心场景而言，指定统一的、标准的扩容模式，对于银行核心系统的长期稳定运行非常重要。 4.聚合查询策略：在策略1中数据被拆分之后，如何承接聚合查询的需求，需要在这个阶段明确。当底层数据被分散到多个数据分片之后，原本在单一数据源上进行的聚合查询，在新架构下则需要被下推到多个不同的数据分片上进行。最后再将这些分片的结果传回进行汇总计算和排序。考虑到核心系统的RT标准，这个过程会对网络和聚合计算节点性能的要求非常高。 5.灰度发布策略：本质上是希望控制指定的流量到指定的集群中计算，以便用于验证新版本功能，也可以验证新的中间件、数据库或其它国产基础设施等。那么，对各类资源也要求能按照标签隔离开，流量也能按照标签进行路由，再通过管控面来进行相应的展示和控制管理。 2.3.3 服务模型策略 •服务粒度：微服务的粒度是业内经常争议的话题。若粒度过大，将无法充分体现微服务的低耦合与自治性；若粒度太细，则可能对性能、稳定性、链路监控和运维产生不良影响，甚至导致大量分布式事务的出现，需要基于应用设计的实际情况，结合成本与收益综合判断。 •落地工艺：从应用设计到研发测试上线的整个生命周期，需要具备全方位的实施方法论。其中包括对需求产出的业务组件到微服务组件的映射与转化方法，从流程到实体模型的识别、定义、分解等工序，以及应用架构的组件和构件从定义、组装到发布的端到端方法论。 •技术组件：在分布式核心系统中，需具备一系列技术组件，用于隔离底层分布式技术的复杂度，并对底层技术产品进行隔离。此层需要具备良好的南北向接口，帮助核心系统通过分层隔离机制来实现自主可控与灵活性。 2.3.4 业务连续性 •弹性故障恢复：“面向弹性容错”是分布式系统设计时常被采用的设计思想，即在面对高故障率和不稳定的基础设施时，业务连续性的保障需要从整体性视角考虑。应用系统为此需要考虑多种故障场景，进而做出故障自动隔离、自动扩缩容等自恢复机制。 •多中心多活：银行机构越来越重视核心系统的高可用性。目前生产运行的分布式核心中，两地三中心是最常见的架构，即在同一城市的两个机房同时接入并处理业务交易，一旦某一机房发生故障，另一个机房将接手这部分的交易。当前也有部分银行客户在开始规划异地多活的架构，即在多地多个机房同时接入并处理业务交易。然而，即使在单元化架构下，银行核心业务中也总有一些场景会出现跨地域交易的情况，例如两个客户跨异地转账，不同地域间的服务目录同步的时效性、异地间分布式事务协调等诸多问题都极具挑战。 •异地容灾：根据监管要求，银行的核心业务需要建设容灾体系以应对不可抗力的灾害情况。在分布式系统中，银行通过定期的灾备切换演练、将灰度单元或只读交易放至灾备机房运行等方案