民生科技副总经理蔡膺红：银行核心系统的分布式转型和应用

来源 | 未央网

为了传播金融创新典范，推进金融供给侧结构性改革，推动金融业服务实体经济，以及促进实现经济高质量、发展的目的，由北京市地方金融监督管理局指导，清华大学五道口金融学院、清华大学金融科技研究院主办，未央网承办推出“首都金融创新与发展”公开课，邀请金融行业嘉宾分享金融项目的创新模式，以及对行业未来发展前景的深度思考。

本期分享嘉宾是民生科技副总经理蔡膺红，带来《银行核心系统的分布式转型和应用》主题分享。

以下整理来自嘉宾分享实录：

分布式架构的建设背景与目标

在外部原因方面，首先是市场环境，包括互联网金融的快速发展、亿级客户规模、快速交付等背景；第二是国家战略因素；第三是在行业背景方面，互联网公司大规模应用该技术，而同业局限于边缘性应用。在内部原因方面，由于传统核心系统是集中式系统，存在技术瓶颈，其架构不易扩展，此外还有系统成本高昂、产品把控能力弱等因素。而与传统的集中式架构相比，分布式架构在海量支撑、自主可控、低成本、弹性伸缩方面有很大优势。

民生银行的分布式系统架构建设主要考虑两个目标，一个是打造基于分布式架构的银行核心系统，满足高可靠、高性能和弹性伸缩等要求。第二是基于分布式架构的能力建设，包括团队、运维体系等能力建设。

分布式设计原则

一方面是业务架构的设计原则，要以用户为中心、以产品为主线、以数据为驱动进行组件化设计，全面支持业务快速创新与发展。具体包括基于SAGA模型的分层设计，负责保持业务数据的一致性和事务完整性；还包括建立客户全景视图，进行合约化管理；第三是通用账户模板，用以灵活支持各类资产类和负债类的客户；第四是遵循单边记账原则，也是为了保证整个事务的完整性；第五是交易与核算分离；此外也包括灵活的产品工厂，通过业务条件与组件等动态管理完成基础产品配置。

另一方面是技术架构的设计原则，要支持应用平台国产化、易适配，可裁剪，技术栈简易，运维复杂度低。具体来讲，应用应该容易适配，同时可以比较方便地进行模块化拆分和踩点；技术栈要简易易上手，支持敏捷业务应用开发；并且要保证业务完整性和强一致；数据应该高可用；此外还有低于集中式系统的运维复杂度以及支持灰度发布和全链路压测。

通用业务架构设计

下图是分布式核心应用架构，其中左侧是业务部分，右侧部分是贯穿始终的运维和管理体系。

详细来讲，在业务架构上有四个特点。

第一是以客户为中心的管理与分析，核心系统与客户信息系统、大数据系统联动，支持建立以客户为中心的业务框架。具体地，会提供面向客户的产品，提供千人千面的系统界面、个性化的利率和关系定价等。同时在客户维度进行合约管理，把客户与银行之间的所有服务关系统一在一个事务中。关于客户的行为分析，包括数据实时分析反馈，全交易操作行为记录和用户行为审计。其中，全交易操作行为记录是指所有查询记录会被精确记录，方便客户看到自己的账户或者客户信息在什么时候在什么场景下被查询了，是自己查询的还是他人查询的，这类似于人民银行的征信系统，对每一次查询都有记录。

在产品工厂和账户体系方面，分布式架构提供了一套灵活、有层级、有协议关系的账户体系。整个体系是一层层的迭代组装，最底层是参数设计，上面是产品组件和账户模板，在模板之上，银行会形成实实在在的基础账户，包括活期、定期、虚拟、非金融账户，然后再通过协议形式构建有层级关系的账户层次。

第三个特点是以事件驱动全行业务，是指交易业务发生时生成事件并发布到事件中心，相关业务通过事件订阅，触发后续业务处理。事件驱动能够实现业务的解耦，降低业务复杂度，实现交易与核算的分离，解决了系统运行的性能问题；并且适应互联网金融发展趋势，实时决策，精准营销。

第四点是业务分层体系，其原则是保证业务的一致性，因为用到分布式技术实际上把数据从集中存储变成分布式存储，可能一个业务场景需要操纵不同的数据库。民生银行采取了TCC模型和 SAGA模型相结合，在不同场景下选择不同模型。比如在代付场景下，可能是一借多贷或一贷多借，为了保证代收代付业务的完整性，会使用TCC模型；对于普通的银行内部的汇款，会使用SAGA模型。

轻量化技术平台设计

下图是技术平台整体的功能架构，核心体系是左半部分的开发态、测试态和部署态，由开发态提供技术支撑；右边是运维体系。

拆解上图的技术架构进行具体解释，分为五个方面。首先是整体的服务治理体系，它保证了业务的完整性，也是动态扩容的基础。服务治理体系实现了单元化多活架构，能够完成分区单元同服务、数据的有机整合，使得应用模块可以天然融入，无需再对整个体系进行分层区分。其过程是服务提供在方案启动时进行服务的注册，消费方服务调用时，先通过配置中心获取全量的服务配置信息，再进行服务通用处理，然后进行分区单元信息处理，判断目的方分区单元，最后调用服务并返回。在实际运行过程中，只有严格按照该程序，才能够支持服务级、应用级、分区单元级、机房级的流量调拨和容灾切换。同时服务治理体系也提供统一通用的服务治理SDK，对应用几乎透明无感知。

第二个是事件驱动中心，提供了分布式可靠消息幂等服务，保证重复发送和接受信息，支持消息路由转发和全链路跟踪。下图左边是消息管理台，中间是通信协议和中间件的接入，右边是应用开发，将消息进行分类。这种架构可以降低应用的侵入性，保持无感，同时也满足了不同场景的的消息需求，并且降低运维难度。此外，通过事件驱动中心，并基于服务治理体系与“计算与存储分离”的架构，民生银行实现了与应用一体化的单元化设计与自动容灾切换能力。比如同城中心都是同时运行的，但如果某个物理机房出现异常，系统能够把流量切换到另外一个没有发生异常的机房。

第三是数据访问层，除了基于JDBC或者ODBC传统的连接数据库的方式，民生银行还通过数据库通信协议的proxy的方式，使运维工作与单库无差异。因此数据访问层实际上发挥了屏蔽应用层和数据库的读写层的作用，其中的技术包括SQL解析、规则引擎、SQL路由等。在底层使用传统方式，通过数据访问层的隔离，使应用无感知，同时能够解决做分库分表过程中数据不同的索引要求。并且，数据层提供了高可用的运维体系，通过完备的数据库管控与治理体系提供了问题的分钟级定位和数据库的高可用保障能力，可视化的操作界面也降低了运维门槛，将复杂的运维工作简单化。

第四是多活架构，除上文所述以外，还包括数据同步和异步相结合的复制机制。系统对数据分层后仍然需要有全局共享的部分和机房共享区，这能够使同城RTO≈0、RPO=0，异地RTO≈0，RPO≈0，符合银行对连续运营能力的要求。

第五是DevOps平台，是开发和运营拼起来的概念，这里指运维监控平台。在分布式情况下，数量众多的服务器和机房对监控的要求很高，因此民生银行运用体系化、可视化、自恢复的软、硬件监控与全链路跟踪分析智能挖掘运维平台，大大降低运维复杂度。这里可视化是指为了运维在数据存储的时候进行了分库分表，但当出现异常需要查询时，可以做到集中查询，而不是上千张表，达到和看一个数据库一样的效果。DevOps平台一体化的设计和可视化的操作，降低开发运维门槛，统一了全生命周期流程。

具体举例来说，DevOps平台支撑服务链路跟踪。一方面是从整个服务链外部看完成一个完整的业务场景需要调动的节点以及服务之间的关系，这可以通过链路跟踪配上监控平台实现一目了然的查看。另一方面，在每一个服务内，也运用服务内调用链路追踪，可视化快速精准抓住小辫子。此外，DevOps平台也支持日志检索，它分布在若干台设备上进行日志收集，然后汇总统一于“一眼清”日志管理平台，实现主动地对海量分布式日志的存储和分析，而不只是被动地发现问题后查询日志。

应用效果

第一点是管理效益。民生银行引领金融业IT架构转型方向，开创了核心账务金融云的行业先河。而且，相比SAP核心系统，分布式架构的亿级客户支撑成本至少节约2亿，单账户成本降低了30倍以上。对于技术管理和风险管理，也完全自主掌控技术架构及业务设计，技术风险高度可控；在流程管理上，也形成了DevOps平台。最重要的是形成了人才和团队的积累。

第二点是项目效益。形成了分布式金融云平台和分布式金融云架构规范和技术标准，包括在业务方面，突破核心系统瓶颈，实现十亿级的客户规模支持，能够应对爆发性场景，比如BAT的抢红包的业务。

第三点是社会效益。民生银行的分布式架构等技术实际上也是响应人民银行和国家的号召，贯彻落实中国人民银行有关《金融科技（FinTech）发展规划（2019—2021年）》规划的若干要求，不断来加大研发力度，坚持“守正创新、安全可控、普惠民生、开放共赢”的原则。