兼顾敏捷交付和系统稳定运行，大型银行平台化落地实践

舒展 2022-08-10 09:12:41

本文根据舒展老师在〖2022 Gdevops全球敏捷运维峰会-广州站〗现场演讲内容整理而成。（点击上方【dbaplus社群】公众号，回复“220617”可获取完整PPT）

分享概要

一、行业背景

二、平台化整体策略及思路

三、金融科技落地实践

四、经验和教训

对于IT系统，系统安全稳定运行与快速的敏捷交互业务功能，似乎有一些矛盾，互联网公司落地实践证明，技术能力的平台化是应对稳定性和交付效率的有效手段。对于金融行业更加严格的监管要求，平台化落地又具有自身的特点。

本次分享希望从研发的视角看金融科技平台化落地的探索和实践，将通过行业背景、整体策略及思路、落地实践的回顾，总结平台化落地的经验。

一、行业背景

1、金融监管对系统研发的要求

金融监管对系统研发的要求包含业务要求和技术要求两方面。

1）业务要求

业务要求对于银行系统来说更多体现为一些功能性的需求，前些年税改费、自贸区等政策引起的相关需求涉及多个核心银行关键系统的变更，如果出错就是账务问题，同时时间紧，要求高，不能有任何的闪失，那么这种需求对于金融机构而言属于最高优先级的刚性需求。

2）技术要求

技术要求较多体现为非功能的需求，如目前正在推进的灾备体系建设、信创要求，这类要求也是必须完成的。

2、新场景、新技术、国产化带来的挑战

随着金融科技应用的快速发展，目前系统的稳定性也面临新场景、新技术、国产化等诸多变化因素带来的挑战。

1）新场景

对于当前账户出海、智慧政务、智慧社区等新场景，原先从事银行系统研发的人员相关领域经验不足，在特定场景下可能会出现业务架构设计和系统架构设计带来的一些不确定因素，最终导致业务流程设计、系统扩展性和非功能方面的考虑略显不足。

2）新技术

云计算、云原生、微服务、人工智能、大数据等新技术如何应用到应用场景中？

各技术领域的应用设计模式、最佳实践、底层技术的掌控能力不足，也会给系统的稳定运行和架构设计的合理性带来一些不确定因素。

3）国产化

由于国外技术的受限，国产化技术成为必然的选择，但是国产化技术普遍商用的时间较短，成熟度有待提升，国产化技术的适配性、供应能力也给应用研发带来了一定的挑战。

3、“平台化”是应对挑战的必然选择

根据国内外互联网公司的实践证明，技术平台化是应对以上挑战的可行之路。百度百科对于通用技术平台的定义提到，平台化能够带来提升效率、降低风险和降低成本多方面的红利。

大型金融企业一般都有复杂的企业级架构，从我们在日常工作中的实践证明，平台是承载效率、成本、质量的最佳选择，而我们更多关注能力的复用、团队的协作、领域的聚焦、研发框架的统一和技术资产的沉淀，以上都将成为降本增效和平台需要解决的关键性问题。

基于平台化的思路，也根据我们多年对金融行业应用研发的理解，我们对应用研发支撑能力进行了建模，理清了狭义的框架、平台与应用之间的关系，进一步明确了技术能力建设的方向，框架是承载应用研发和应用逻辑的核心。

应用开发人员使用IDE工具，基于框架编写应用逻辑，与框架共同组成了应用组件的运行版本包。平台主要提供运行版本包的管理功能，例如运营运维的支持，以及支撑应用运行的业务领域和技术领域的通用功能。

二、平台化整体策略及思路

1、金融企业系统平台化的典型历程

接下来我回顾一下银行在系统平台化建设的路径。

场景的拓展、架构复杂度的提升、应用规模的增加、新技术的引入和数据量的激增都会带来平台功能和形态的演进。从整体的时间线来看，典型银行在系统平台化建设的路径大概分为5个阶段。

1）2000年之前，由于系统规模不大，更多以单体应用为主，系统内的复用则更多以公共库的方式承载。

2）2000～2011年，随着系统数量的增加，系统间的协作需求也增加，但是此时系统内部的架构是相对异构的，通过应用集成总线实现异构系统的连接，即可满足应用之间衔接的需求。

3）2011～2017年，开始建设新一代核心银行系统，从业务的流程建模、数据建模和产品建模着手，技术上实现了统一的标准规范。应用采用企业级统一的标准框架进行研发，系统内部标准的同构也带来系统间交付的通讯协议报文规范的同构。应用之间的交付也不需要再通过统一的应用集成总线的中心化方式进行连接，我们建立了ESB的服务总线，它是一种服务注册发现的机制，能够实现直接的通讯进而提升效率。同时，因普通的应用研发人员和要求趋同，在应用研发上也实现了人员的互动，提高了效率。

4）2016～2020年，随着金融科技的出现，开始建设面向不同领域如微服务、大数据、人工智能等相关的金融科技平台，这些平台也承载了一些相关领域的通用经验。

5）直到2021年，随着专业领域的平台能力相对比较成熟，以及云原生、服务化、多租户能力的需求，我们开始将各方向的技术能力平台进行拉通，以技术中台的方式统一对外进行供给，降低应用研发人员的门槛，提升研发的效率。

2、平台化落地的整体思路

平台化落地来自于领导、架构、研发、运维、运营和支持人员的一些相关需求，他们各自有不同的关注点。

1）从方案入手

在落地的方面，我们更多结合各方的需求，从应用方案入手，拆解出对平台的需求、研发的规范，以保证我们平台落地的成果能够对接上应用研发的需求。

2）问题驱动

平台的落地也是问题的驱动，我们不断挖掘应用研发的痛点，将痛点落地到平台中，提升研发的效率，降低运行的风险。

3）三态合一

所谓三态就是开发态、测试态和运维态。因为金融行业开发和运维需要一定程度的隔离，这种隔离会给敏捷的交互带来一定的影响，所以在平台落地时我们要充分考虑这个特点，再结合运维合规性、稳定性的要求，在平台设计上实现开发态、测试态到运维版本交互流畅的衔接，以提升我们版本交付的效率。

4）流程闭环

所谓闭环更多是谈到类似于运营的一些能力，因为我们前期在平台建设时，更多考虑平台能力的建设，当平台能力相对成熟和完善时，就面临大规模平台能力的推广，那么就需要通过运营的手段，从运营平台上获取相关的运营数据，识别出应用研发的更多痛点，达到持续提升平台能力的目的。

三、金融科技落地实践

1、驱动平台演进的因素

1）新业态

从商业银行发展的阶段来看，新业态也是驱动平台演进非常重要的因素。银行从以银行网点为主的1.0状态，到经历电子化和电算化的以网点为主、网上银行为辅的2.0阶段，再经历银行业务移动化，客户在任何时间和地点都能享受到银行服务的3.0阶段。目前银行已经进入4.0阶段，主要特点就是银行的服务已经无处不在，嵌入到千行百业，融入到大众百姓的生活之中，进而导致一些新的需求产生，比如APP的安全和图片存储服务等方面的需求，我们也逐步在平台中丰富和完善这样的能力。

在原先APP和小程序不多的情况下，我们可能通过手机银行等比较集中的渠道，在应用层面即可解决一些安全性、数据埋点分析和文件服务的问题。但是随着APP的增多和小程序的出现，我们希望通过平台化将很多基础能力沉淀到平台中，以提升研发的效率和解决运维的安全问题。

2）企业架构

企业架构对平台的整体演进也产生了较大的影响。《软件架构模式》一书提到5种软件架构模式，分别是分层架构模式、基于事件的模式、微内核模式、微服务架构，以及基于空间的架构模式。在每一种架构模式上都有一些架构的关键要素，基于架构的治理和可视化方面，平台需要重点考虑这些要素，否则难以较好地承载该架构模式下的架构要素。

典型银行的平台化落地也离不开企业架构视角的变迁。在单体架构的模式下更多的是系统内部的公共库，而像异构的系统集成方面，更多需要提供EAI总线的能力，到了SOA的架构下，需要在平台层面提供统一的服务目录和注册发现的机制。到了微服务的阶段，随着银行系统规模的增大，我们采用一些分布式技术解决高并发大流量的问题，则出现了单元化等概念，单元化也需要在架构治理和可视化方面对架构予以承载。

到了云原生架构阶段，云原生随着容器、PaaS等技术的出现，带来了一些新的解决方案，如POD、Service，在架构层面也按照云化的方式，出现了控制面、数据面等概念，这些都会对平台的落地带来影响，主要体现在以下三方面：

一是应用架构流程、项目协作、系统架构设计变化；
二是架构规范、架构标准固化到框架平台；
三是新架构带来设计、开发、测试、运维等开发过程的影响。

3）云计算技术

云计算技术也驱动了平台的演进，从开始的云机房到云就绪，再到现在的云原生，云计算关注的重点逐步向应用靠拢，以应用为中心。我们在平台的建设上也重点落地了面向金融体的稳定应用模型、云原生的基础组件，以及针对金融级的稳定性要求，实现了容器网络的部分隔离以及跨机房综合部署的部分能力。随着架构和云计算的演进我们在平台上增强了以上功能。

4）敏捷研发技术