作者｜刘伟光 陈威 任妍「阿里巴巴集团，刘伟光系副总裁兼阿里云新金融事业部总经理」
文章｜《中国金融》2020年第16期
为适应市场变化、支撑业务创新、实现运营降本增效，金融机构持续探索优化IT架构体系：从集中式到分布式，并逐步融入微服务、云原生、容器等新理念和新技术，核心系统不断优化。在此过程中，阿里巴巴作为国内主要的大型科技公司，密切关注金融机构IT架构迁移升级的步伐和趋势，凭借自身强大的研发力量和模式创新能力，不断提升赋能金融业务的能力。本文将结合阿里巴巴分布式架构发展历程，探讨以商业银行为代表的金融机构核心系统向全分布式体系架构迁移的有效路径。
阿里巴巴分布式架构系统的建设历程
架构转型的原动力来自于业务拉动、技术驱动以及企业发展的前瞻性布局。阿里巴巴成立20多年来，为支撑旗下各类业务板块（如天猫、聚划算、闲鱼等）持续创新发展，自身的IT架构也经历了五代转变：集中式架构，部分分布式架构，去IOE的自研平台单元化架构，云平台架构，共享中台化云原生架构。
业务发展不仅要求解决大规模数据存储与访问的线性可扩展问题，以应对像“双十一”这样的业务峰值压力，还要兼顾业务连续服务保障和版本快速升级迭代，在防范风险的同时实现升级过程与日常海量用户访问并行工作。此外，复杂的企业级互联网应用需要在运行时全程动态感知与管理，不仅要有弹性扩展能力，还要根据业务流量酌情进行业务降级，确保系统高可用，这对系统架构设计与运维提出了很高的要求。
为应对日益复杂的业务和技术需求，阿里巴巴对传统SOA（Service-Oriented Architecture，面向服务的架构）、ESB（Enterprise Service Bus企业服务总线）进行了革新，开启了分布式架构转型之路：自2009起独立研发阿里云；2010年启动去IOE项目；2012年开始预研单元化架构；2013年底，完成集团全部业务去Oracle数据库迁移，2015年实施中台化战略，2017年成立达摩院深化基础技术产品研发……可以看到，每两三年，阿里巴巴就会启动前沿技术领域的实践与研究，主动进行架构的升级与演进，承接不断刷新纪录的交易量和交易规模，在历次“双11”大考中经受住了每秒上千万次的峰值访问压力：2017年“双11”，OceanBase数据库支持支付宝100%的交易流和支付流量，支付峰值25.6万笔/秒，数据库处理峰值4200万次/秒。2019年“双11”，PolarDB数据库处理交易事件的峰值达到了8700万次/秒。
上述支持海量高并发计算的架构被称作“全分布式架构”，在事务处理和数据计算方面具有多方面优势。一是提升容量延展能力。可实现跨城市IDC（数据中心）级无限水平扩展、快速建站、弹性异构并行计算，具有处理十亿账户、百亿日流水的处理能力。二是提高容灾等级。通过构建多层次单元容灾，全分布式架构可达到RPO（Recovery Point Object，恢复点目标）为0、RTO（Recovery Time Objective，恢复时间目标）为分钟级的最高等级容灾标准。三是风险可控。全分布式架构能够进行多层次风险控制，对生产环境性能动态评估，实现应用快速迭代。四是降低成本。全分布式架构可以有效提高资源利用率，降低企业软硬件成本
阿里巴巴全分布式架构设计理念
从阿里巴巴旗下各经济体的运行状况来看，EB级（计算机信息存储单位，即100亿亿字节）海量数据的处理对IT架构的稳定性、可靠性、延展性和效率性都有很高的要求。全分布式架构从前端服务、应用服务到后台数据库各环节均无单节点，通过“业务单元化”打破网络传输速度的物理限制，真正实现了可横向弹性扩展的技术体系，契合了金融服务连续运行对“多地多中心多活”的技术体系要求。
“单元”是指一个能完成所有业务操作的自包含集合，包含了业务所需的所有服务以及分配给该单元的数据。以单元作为部署基本单位的架构可以有效解决单机房数据库连接限制，实现异地多活、容量预估和灰度发布。
商业银行分布式核心系统建设思路
长期以来，各商业银行多采用IOE架构支持核心业务系统，涵盖存款、贷款、汇款、支付、银行卡业务等功能，形成了“数据大集中”模式。集中式架构为金融业务提供了较好的处理性能和稳定性。2010年以来，为应对利率市场化、互联网金融新业态的冲击、传统IOE架构升级扩容成本过高等内外部挑战，各金融机构积极布局互联网，着力建设推动核心系统IT架构向“分布式平台+微服务化”方向转变。技术路线逐步从闭源向开源和自主可控转型。随着业务与管理实现全流程数字化运营，IT架构也将持续完善，核心系统的技术架构也将向云化、智能化的方向发展。
全分布式核心系统架构以“中台化+轻前台”的模式替换“瘦核心+大外围”的模式，将业务中台的原子能力按照业务域归纳、抽象，整合成符合业务语言的能力组件，可根据业务诉求快速组装出符合其要求的服务能力，降低试错成本，提供个性化服务（见图2）。
金融机构全分布式架构将核心系统的主要功能封装成三个服务平台，分别对上层提供服务。
首先，资金平台保障事务一致性。资金平台包括存款、贷款、理财、权益等多种核心业务。向上对业务产品层提供统一的资产处理服务以及内部封装账务、清算、核算等原子能力，通过资产交换发起分布式事务，保障各个资产在交换过程中的事务一致性。业务系统无需感知复杂的处理逻辑。
其次，客户平台统一管理全行客户资源。按照“以客户为中心”的理念统一定义和管理客户信息，统一身份识别和统一认证授权；具备360度客户视图信息模型，为基准客户洞察提供基础支撑。
最后，产品平台连接客户与产品。该平台对金融产品要素及其处理流程进行抽象，形成产品模型，支持产品灵活定义和配置组装，支持用户定制化服务，提供全局性的统一合约视图。
由此可见，全分布式架构不仅具有良好的弹性扩展能力，还能够快速响应业务变化，支持应用敏捷迭代。它通过标准化业务建模、标准化能力和服务设计，把金融服务的核心要素数字化并沉淀在中台，构建全行级中台能力地图和业务全图，形成敏捷、共享、开放、高效的企业级业务中台。以“厚平台”的全面服务提高研发效率、支持前台业务快速接入，降低创新的成本。
在支持业务连续性方面，全分布式架构将业务按单元分散在不同地域的多个数据中心，最大程度降低故障隔离域粒度。它支持数据进行水平拆分，采取自选举数据库，保证数据分片有同城和异地副本，灾难时支持自动切换主备节点的功能，可以实现RPO等于0，有效保障了业务连续性。
商业银行分布式核心系统实施策略
全面分析商业银行建设分布式核心系统的典型策略
一是先易后难，由外围向核心逐步实施。以分布式核心系统建设为最终目标，前期进行全局规划，做好分布式技术产品选型，选择外围系统构建原型进行验证。在技术验证过程中，逐步总结分布式系统的技术标准，验证技术选型的正确性，综合技术复杂度、业务重要性及影响容忍度等因素，按由低到高的难度顺序逐步替代，最终完成分布式核心系统的建设。大型商业银行因其核心系统过于庞大复杂，通常采用此类方式，其特点是实施过程循序渐进，风险可控，但周期相对长。
二是先难后易，集优势兵力攻克难关。选择典型的核心业务系统（如直销银行业务或者卡业务系统等）作为试点，与核心软件产品供应商（如分布式数据库服务商）建立共创合作模式，边实施边打磨产品，探索形成分布式核心的建设方法。鉴于核心系统对计算存储资源的要求较高，有些银行充分借鉴互联网银行在分布式架构转型中的经验，选择基于云的架构新建分布式核心系统，随核心系统上（专有）云完成大机下移，并逐步将分布式云平台推广到其他各业务系统。部分股份制银行、城市商业银行及农村信用合社系统已经采用此类方法。其特点是见效快，具备标杆效应，能够快速将架构与最佳实践推广至其他系统，但需整合内外部资源多管齐下共同控制实施风险。
在分布式核心系统的实施策略上，各银行机构采取了部分分布式和全分布式两种不同的架构，全分布式架构在弹性扩展能力，敏捷响应业务变化，隔离故障粒度、支持多地多活方案保障业务连续性等方面具有显著的优势，经POC测试（Proof of Concept，是针对客户具体应用的验证性测试）验证，获得银行机构的认可。下面将围绕全分布式核心系统建设进一步分析。
开展全分布式核心系统建设规划
核心系统是支持金融机构顺畅运营的至关重要的组成部分，权衡风险与收益是各机构在分布式转型之路上面临的重大抉择，必须做好路径选择。无论是由易到难，还是由难到易，都需要充分评估自身的实际，明确短期和中长期的目标，对投资、技术、业务、管理等风险进行综合评估。全面分析在全分布式和微服务架构下，核心业务系统改造的挑战与价值、路径与困难、风险与应对，并配套相应的组织架构和职责分工，共同支持核心系统分布式改造工程。
在这个VUCA（乌卡，指易变、不确定、复杂、模糊）时代，不确定的外部因素以及动态变化的内部因素都增加了风险分析和控制的难度。因此，商业银行银可借鉴互联网公司或同业机构的技术路线，选择经过实际落地验证的实施工艺，并做好前期的咨询规划和风险评估，从而找到适合自身的实施路径。
以控制整体风险为导向进行整体规划与技术选型。核心系统是一项复杂的项目工程，其风险分布在项目建设各阶段，包括技术选型、资金投入、组织管理、迁移切换、运行管理等。因此，在评估风险时，不仅考虑局部风险最低，更需要考虑整体风险可控。比如，各层次解耦在一定程度上能够降低技术路线更换的风险，但不同技术体系组合将提高产品适配和性能保障的风险。核心系统对外需要对接各类应用，外部对接复杂性不易控制，因此从降低总体风险度的角度，可尽量降低内部体系架构的复杂度，选择相对统一的、经过实际场景验证过的技术堆栈与路线，更有利于保证项目质量和进度。
此外，要关注多中心的异地多活单元化设计，以满足弹性扩展和容灾需求，结合各地数据中心的建设周期规划，对多地多中心的单元化改造进行规划设计，确保改造后的全分布式核心系统能够承接海量并发的互联网级别的访问需求。
抓住全分布式核心建设的关键点
一是着力构建统一的核心应用框架。该框架包含三个部分：支持开发、测试、运维一体化的DevOps平台（含配套的相关规范），汇聚关键技术组件与核心业务应用组件的组件集，以及中台化的运营管理平台。其中DevOps平台是核心系统高效建设和持续优化的基础，分布式架构包含的设备多、服务多、配置多，提高了运维的复杂性，其业务分层、服务调用、系统状态等都比集中式架构更为复杂，对设计实施和运行管理工作提出更多挑战，而统一的核心应用框架为用户提供开发、测试、运维相关一体化服务和工具，并将全分布式能力有机的融入框架之中，有助于降低对核心系统应用开发商的开发成本与能力要求，有效控制工程实施的风险和成本；能够强化实时监控与应急指挥的协同，降低客户运维管控大规模分布式架构的难度。同时，中台化的运营管理平台是全行核心系统管理与服务的基础，将有机的组织和运营融入核心应用系统与相关功能模块，可以帮助用户管控好庞大复杂的核心应用系统。
二是前瞻性做好分布式数据库的选型。金融业务要求分布式数据库在并行计算、并行存储、水平扩展、云化部署等方面应不低于传统集中式数据库。即在性能方面，不低于10万每秒的连接数和千万级以上的TPMC（每分钟内系统处理的新订单个数），并且具备支持自动切换的高可靠性容灾能力。因此，在分布式数据库选型方面，应关注经过实际场景压力检测、经过一定时间打磨，并具备良好管理工具的产品。在此基础上，配套建设一站式智能研发平台，实现研发与运行成产的联动。
三是构建分布式事务处理能力。金融业务对资金账务等关键数据的事务一致性要求非常严格，而分布式架构的数据计算分散在多个节点上，保持事务一致性是核心系统对分布式技术的巨大挑战。
构建全分布式核心业务系统基础框架需多项配套举措
全分布式核心系统在接入层、应用层和数据层都需要进行一定改造。比如，在接入层依托API网关实现访问控制和服务的安全管控；在应用层通过微服务架构实现弹性伸缩，使用消息中心解耦应用；在数据层进行分库分表、读写分离实现数据弹性伸缩，通过分布式缓存提升处理性能等，上述多个层次的改造往往需要重新划定核心业务与外围业务的边界，并优化相关信息交互和接口规范。
此外，分布式架构转型对于商业银行的技术团队是一项新的挑战，商业银行的技术团队需要跨越一定的技术壁垒，因此，选择兼具技术先进与长期发展的可靠的产品与服务供应商，有助于维护技术路线的相对稳定性，降低核心系统建设的潜在风险。在实施技术合作的同时，商业银行可借鉴金融科技公司的管理实践推动自身的数字化转型，优化组织架构，形成适应全分布式核心系统的运行管理流程，逐步培养具有自主运营能力的专业团队，为新一代全分布式核心系统长期稳定运行提供保障。■
（责任编辑 张林）
