金融专家说 | 开放共生，云原生在金融领域的实践与展望

市场的变幻，政策的完善，技术的革新……种种因素让我们面对太多的挑战，这仍需我们不断探索、克服。

今年，我们将持续推出新栏目「金融专家说」「技术专家说」等，聚集数帆及合作伙伴的数字化转型专家天团，聚焦大数据、云原生、人工智能等科创领域，带来深度技术解读及其在各行业落地应用等一系列知识分享，为企业数字化转型成功提供有价值的参考。

今天是第1期，由网易数帆资深架构师朱剑峰围绕云原生技术作详细解读及前沿瞭望。

席卷全球的新冠肺炎疫情，对全球社会、经济、技术都造成了巨大影响。在常态化疫情防控的号召下，金融科技得到了更加广泛的重视和应用，实体企业面临“达尔文时刻”：疫情前没有做好数字化技术储备的企业，很多都黯然离场；已经在数字化转型道路上前行的企业，则加快了技术转型的步伐。正在进行转型的企业从实施中台化战略、统一技术底座、增强全方位的运营支撑体系入手，投入更创新、更标准、更低成本的产品与技术，来满足业务方以及客户不断变化的需求，以快速适应后疫情时代的新常态。

一、云原生技术概述

云原生源于云计算，其构建并部署在云中，能真正访问云基础设施的强大功能。云原生应用程序是以微服务架构实现的，微服务架构被设计为服务于特定目的的一个独立模块，以高内聚、低耦合的方式拆分，配合容器、服务网格等技术，可实现按业务模块快速迭代、独立开发部署等功能。

（一）国内云原生应用现状及相关标准

2019年8月，中国人民银行发布《金融科技（FinTech）发展规划（2019-2021年）》，此后，基于“金融与科技深度融合、协调发展”的顶层设计日趋成熟。规划明确指出建立“统一、全面、共享”的金融业综合统计体系，确保统计信息的完整性和权威性。随着云原生技术的发展和应用，金融领域对云原生的接纳程度越来越高，开始利用云计算、云原生、大数据等技术实现资源高度复用、灵活调度和有效供给，探索构建跨层级、跨区域的自动化与智能化业务处理中心，从而提升金融服务运营效率。当前，金融科技逐渐向服务平台化、数据集中标准化、数据价值在线化、场景智能化方向稳步推进。在顶层设计日趋成熟的情况下，具备资源弹性和服务化能力的云原生技术逐渐成为服务平台的基础。 

中国信息通信研究院发布的《云原生发展白皮书》明确，云原生是面向云应用设计的一种思想理念，能够充分挖掘发挥云效能的最佳实践路径，能够帮助企业构建弹性可靠、松耦合、易管理可观测的应用系统，提升交付效率，降低运维复杂度，其代表技术包括不可变基础设施，即容器、微服务、声明式API及服务网格等。

国内首个微服务标准由中国信息通信研究院主导并于2018年底完成。该标准指出，微服务架构能够将庞大的应用系统解耦合，以高内聚、低耦合的方式拆分，实现按业务单元快速迭代、独立开发部署等特性。在国外，主要由ITU标准组织发布有关微服务标准，其中，《Cloud Computing - Requirements for Containers and Micro-services》主要描述了容器和微服务的特性，适用于指导企业使用微服务架构及微服务平台的建设。

《中国云原生用户调查报告2020》显示，2019年中国云原生市场规模已超350亿元，除了互联网行业外，金融、制造企业更加关注云原生技术，近半数企业开始采用云原生容器技术支持生产环境业务。从数据看，云原生技术在提升资源利用效率和业务的敏捷弹性方面价值最为明显，但学习成本高以及与企业既有体系的整合、演进是用户非常关心的问题。

（二）云原生的颠覆性

云原生架构的应用已经成为金融行业创新的核心推动引擎，基于云原生架构的业务具有三大颠覆性特征：成本优化能力、业务扩展能力、生态演进能力。

1. 成本优化能力

随着IT投入越来越多，必须考验ROI指标。在尽量少用资源情况下，如何提高资源的利用率，保证业务的创新和稳定运行能力，是企业IT价值的体现。

云原生技术平台可以通过混合容器云对接企业多种IT基础设施，帮助业务从传统的固定IT资源申请模式转变为动态可变模式。业务方可以通过自助申请或释放池化资源来主动控制成本，也可以通过容器混合调度能力，根据时间范围将实时在线业务与离线跑批任务。

在传统的数据中心中，在线业务和离线业务分别运行在不同的集群中，这实属无奈之举。因为混部会带来底层共享资源（如CPU、内存、网络、磁盘I/O）的竞争问题，从而导致在线业务性能下降，而这种性能下降是不可预测的，因此只能采取在线业务和离线业务分开部署的方式，最终导致集群整体利用率不高。

2. 业务扩展能力

在互联网大潮下，无论是互联网企业还是传统企业，都存在业务变化快的情况，传统的商业模式被飞速打破，新的商业模式层出不穷，而新的模式需要技术的支持。

云原生微服务通过关注点分离（Seperation of Concern）来适应业务需求，这也是业务层敏捷的关键。这一方式源于人类思考问题的物理极限，当人们在思考问题时，如果把太多问题混在一起，所有人一起关注，会导致不清晰，管理混乱、效率低下等诸多问题，这时候需要拆分问题，分而治之。在服务架构中，就表现为一个大型“巨石”服务被不断拆分成子服务甚至微服务，最终每个服务聚焦解决一个子问题，其边界清晰、决策容易、开发速度快，使业务更加敏捷，从而为业务提供市场适应力。

3. 生态演进能力

云原生技术生态开放，社区活跃，在技术引领者、实践者们的参与下繁荣发展，加速构建技术生态版图，为企业云原生技术的持续演进与迭代提供了技术标准与背书。

二、云原生在金融行业的热点应用与分析

（一）互金电子商城业务场景

通过数字化能力发挥银行的金融优势，建设网上电子商城发展客户流量、培养优质客群，以此提升银行的金融产品服务触达率，达到交叉营销的效果，是银行在网联网时代重点发力的一个领域。面向ToC用户，各大行都在大力推进面向生活的场景化金融，打造场景平台，获得更多的金融消费数据，如电商“双11”低价促销抢购业务。

电子商城典型的抢购类业务需要在瞬间既保证抢换购的商品能正常下单支付，又要保证平台用户有良好的购物体验，TPS时常瞬间呈洪峰般拉升。在传统架构设计中，要支撑这么大的流量需要事前预留足够多的资源储备，还要充分预估活动的效果及活动后的资源利旧，种种技术原因导致业务层面错失许多开展促销活动的时机。

随着云计算生态的蓬勃发展，原有陈旧的应用架构微服务化，通过云原生技术标准化资源，轻量化弹性调度，更好地对资源进行弹性可伸缩，从而支撑金融零售事业部面向互联网开展换购场景活动，同时降本增效，让更多有用的资源发挥更大的价值，促进金融零售事业部向互联网零售消费金融转型。

因此，需要以支撑互联网高并发流量、支持团购秒杀等运营场景为目标进行设计开发。

为了满足性能要求，需要做好架构设计和技术平台的搭建。平台应该考虑技术文档完整性、接口成熟度、服务领域划分成熟度、高可用性、服务治理成熟度、秒杀及高并发、数据一致性、联合查询问题、监控运维等课题，并针对行方金融个性化业务需求进行增强拓展。

（二）代收付缴费生态

代收付缴费生态是面向互联网行业建设的一个典型应用场景，目前可承揽居民生活自来水费、居民电费、个人手机通信费及交警罚没款等涉及居民基本公共支出的各向费用代收付场景。

由于代收费特色缴费生态面向多渠道、多终端、多人群，各地代收缴费业务逻辑在各分行会形成差异，且客户数据、交易数据分散在各分行，不利于对全生态的管控，在扩展性、适配性、弹性伸缩、资源调度、开发运维等方面与云计算架构的优势不匹配，无法真正发挥云的价值。而云原生技术拟采用统一微服务开发框架，集成了注册中心、配置中心、日志中心、全链路中心、服务治理，对服务进行统一PaaS服务化编排治理，形成对全生态云化纳管，进一步释放云计算的能力，将安全、可靠、可伸缩等需求交由基础设施实现，使仅需关注业务逻辑而无需关注具体部署和运行，提高应用开发效率。

三、金融科技云原生实施规划

（一）第一阶段：平台能力基础建设，业务微服务化改造

第一阶段主要通过试点建设，落地整个微服务平台基础能力，结合目前的中间件现状，进行试点项目的适应性改造；在弹性扩容、分布式一致性、可观测性及全链路灰度等层面进行试点建设；针对应用运维能力展开基础调研、体系梳理和可行性论证，确定后续建设目标。

在统一服务治理方面，结合现有技术栈及云原生技术优势，统一技术栈标准，加强现有技术栈能力，共同规划核心技术能力建设。与现有技术栈对接共建，借助云平台功能服务加强现有能力，如高可用容灾、多租户、统一监控、应急管理等。

（二）第二阶段：提升应用管理运维体系并支持应用迁移/服务网格化

在第一阶段验证完成的基础上，第二阶段将主要存量应用迁移至云原生技术平台，通过服务网格将存量传统应用上微服务平台，并从服务管控维度统一管理存量微服务应用、异构技术栈系统及新建系统；对于关键的PaaS组件，实现多租户云化形式向业务方提供服务，按需申请、统一运维管控。

在云原生架构升级方面，对老旧、“稳态”的应用，通过服务网格化部署，实现异构系统服务治理，低成本云原生落地；针对关键PaaS组件完成云化部署和金融场景支撑（如分布式事务的金融级云原生化建设），在亿级用户的资金操作场景下保证数据准确性，可广泛应用于交易、转账、保险理财等核心资金链路，实现服务链路级事务、跨库事务、消息事务及各种场景的事务协调，解决由分布式微服务架构带来的数据一致性问题。

（三）第三阶段：规划应用多活/单元化架构体系

在第二阶段的基础上，第三阶段进一步进行能力升级和加强，通过单元化架构设计，统一企业技术栈，配合核心系统改造，实现多地多中心的统一应用发布运维管控，从同城双活向异地多活架构演进；在应用运维体系试点落地的基础上，具备常态化机房级容灾演练能力，建立成熟的应急响应体系。

四、金融科技与云原生的融合与展望

《Bank 4.0》展示了颠覆传统认知的未来银行体系，通过利用金融科技，实现无所不在的银行服务。传统银行面对如此快速的变化和激烈的竞争环境，应该更努力地拥抱科技，提供全新的客户体验，也可以考虑和金融科技公司合作以获得更快、更好的科技应用。

银行之所以迈向4.0，是因为客户的行为发生重大改变。大型非银竞争对手的规模已经超过世界上最大银行所能触及的范围。银行如果希望在未来10年能够挺过这场变革，就必须重新定义组织、重建核心服务交付的能力，同时发展团队，并根据全新的组织结构自我重建。

从Bank1.0到4.0的过程中，敏捷的服务供应能力帮助银行搭建金融科技平台，提供无摩擦交互体验。同时银行对实体网点无需求，不再有总分行的传统架构，而是专注于将银行的“存贷汇”等核心功能融入客户生活场景中，实现无感知的综合金融服务，而云原生技术正是金融科技平台最佳的基座。

在全面云原生微服务化改造之前，金融企业中现有的ESB与新建的微服务治理引擎将在中短期内共存。ESB与微服务治理引擎都是IT系统应用的服务集成平台，ESB是系统之间服务集成的枢纽，微服务治理引擎则分为在业务领域内部通信与治理的框架，以及用于外部通信的API网关两大部分，显得更为轻量。不论是ESB还是微服务治理引擎，从企业统一服务集成与治理层面来看，重点关注的内容包含统一技术栈纳管稳态、敏态多种形态的业务，以及兼容异构基础设施等。

（一）软件应用基础设施正加速全面容器化进程

在以Kubernetes为代表的容器资源编排成为业界公认标准的背景下，云原生技术的软件应用基础设施从物理机和虚拟机逐步转向容器集群成为大势所趋。根据CNCF《中国云原生调查2020》显示，容器持续迅猛增长，68%的机构在生产过程中使用容器，比2019年增长了39%，生产中使用Kubernetes的比例已从2019年的72%增长到了82%。越来越多的金融企业已经从选择部分业务试点容器，转变成业务容器常态化、规模化。在Kubernetes的编排对象扩展到物理机、虚拟机之后，软件应用基础设施的统一抽象在云原生场景下成为可能。业务在技术层面的聚焦也逐步从容器化改造、容器技术，转变成对规模化容器集群支撑的架构与解决方案。在诸多积极因素的加持下，软件应用基础设施全面容器化已经成为不可逆转的趋势。

（二）应用软件架构从集中式多层架构向微服务网格化架构演进

当前金融行业业务相较于传统金融业务更加多元、规模化，需要更灵活、敏捷的业务和技术架构支撑。传统的集中式单体和多层架构已经难以适应多元的业务变化和敏捷的业务需求。分布式微服务架构将集中式单体服务按模块进行拆分，不同的模块以“微服务”进行组织，不同“微服务”承载独立的业务，可以由独立的部门和研发者负责。分布式微服务架构带来的高灵活性、易维护性已经为越来越多的业务带来技术收益，推动微服务、服务网格技术的蓬勃发展。

1. 服务双引擎治理

微服务治理引擎是传统微服务技术的核心所在，提供无侵入、透明化的远程服务调用框架，一般采用SDK或Agent方式为应用提供服务容错、限流降级等高可用能力，保障服务高质量运行。

早期微服务技术中的服务注册、发现、调用、治理、观测都离不开服务框架，而这也带来了一些问题，比如业务研发者需要掌握非业务相关技术、框架版本升级困难、框架越来越重难于维护等问题。

服务网格（Service Mesh）是将无侵入服务治理定义得更为彻底的微服务架构方案。通过将微服务治理能力以独立数据代理组件（Sidecar）的方式整合并下沉到基础设施，服务网格可以实现应用业务逻辑与服务治理逻辑完全分离，这也使支持多语言、热升级等高阶特性变得顺理成章。

双引擎多模式服务治理能力可以充分利用已有的微服务平台能力，比较好地填补从服务框架到服务网格平滑演进过程的技术空白，提供更整体、更平台化的微服务架构演进支撑能力，如图1所示。

图1　微服务双引擎多模式治理体系

服务集成与治理相关技术的主要应用场景如下。

一是建设企业统一技术中台。通过云原生微服务化技术对传统应用进行改造，拆分为模块化、标准化、松耦合、可插拔、可扩展的微服务架构，可缩短产品面世周期，快速上架，抢占市场商机，既确保了客户服务的效率，又降低了运营成本，实现新敏态业务形态。

二是面对高并发业务可实现快速扩展。通过微服务产品开发互联网金融业务，可提高研发效率，更灵活地响应业务变化需求，快速迭代创新产品。针对热点模块可进行快速扩展以提高处理能力，轻松应对突发流量，同时提高用户体验，为更多小微客户提供个性化的金融产品和交易成本较低的便捷金融服务。

三是多数据中心异地多活。通过微服务产品可快速构建可扩展、高性能的金融级分布式核心系统，使其拥有弹性扩容和异地多活的能力。

2. 可观测性

采用容器、微服务、服务网格等技术，金融的整体业务系统复杂性大大增加，在基础设施层、容器性能层、应用性能层、用户业务层都需要提供可观测的技术手段或工具来实现业务的可控，通常会在日志、指标数据度量和链路跟踪3个方面入手，并采用基于日志采集检索、应用性能监控指标、全链路追踪等能力的完整方案。

（1）通过日志采集检索，展现的是应用运行而产生的、事件或者程序在执行过程中产生的一些日志。例如一笔转账，可以详细解释系统的运行状态，及转账过程中所经历的步骤。

（2）指标数据度量则是描述具体某个时间点某个对象的值，其是一种聚合数值，可以观察系统的状态和趋势，但对于问题的定位缺乏细节展示。例如统计一个服务的TBS的正确率、成功率、流量等。

（3）链路追踪面向的是请求，在单次请求的范围内处理信息，分析出请求中的异常点，任何的数据、元数据信息都被绑定到系统中的单个事务上，且一个Trace有一个唯一的Trace ID，并由多个Span组成。

《中国云原生调查2020》显示，可观察性工具在企业被广泛使用，95%的单位使用监控工具，94%使用日志，85%使用分布式追踪。

可观测性技术的主要功能应用场景如下。

一是问题的分析与快速定位。在分布式场景下，服务调用错综复杂，问题的分析与定位非常困难，而分布式链路跟踪系统能迅速定位有问题的服务，协助快速解决问题节点。借助完整的应用调用拓扑关系，自动发现该服务的历史调用情况，以及对所有中间件的调用，绘制整个系统调用关系的拓扑图，快速定位不健康应用。在调用关系拓扑中，对不健康应用进行显式标识，便于快速发现有问题的应用并进行分析。

二是应用性能优化。在调用关系拓扑中，可以对各个应用的调用次数以及耗时情况进行分析，找到负载较高以及负载较少的应用，从而对资源进行合理利用。通过对所有的调用信息进行聚合汇总，对各个应用的调用情况以及响应情况进行分析，可快速发现整个系统调用拓扑中关键应用的路径，及时发现某些不合理的调用并进行处理，如频繁进行数据库操作等。

3. 分布式事务

在金融级交易系统中，客户资金安全性的处理相当复杂，当服务和数据被分布后，对事务型的状态数据一致性处理的要求很高。传统技术中的事务一致性方案对资源加锁的时间长、粒度大，在很大程度上制约了系统的可伸缩性与高可用性，无法满足架构向单元化、异地多活的发展需要。

分布式事务需要通过业务低侵入性及良好的兼容模式，对跨平台、跨服务的交易进行事务协调，解决由分布式微服务架构带来的数据一致性问题。

需要保障数据一致性的应用场景包括以下3种。

（1）支付与转账。金融行业常见的支付、转账、账务等业务场景对吞吐量有很高的要求。

（2）财富理财。这类场景中往往涉及的金额较大，所以对于产品的稳定性要求非常高。

（3）金融产品申赎买卖。这类产品参与方多、类型繁杂，往往会伴随高可用高并发的需求，例如新股申购是该类业务的典型场景。

4. 容灾多活

容灾多活技术已经成为以银行为代表的金融行业的刚需。现阶段多数大行已实现异地灾备多活，头部大行已做到同城三中心异地灾备，即同城3AZ多活的基础上，在异地实施应用和数据备份。如北京Region的AZ1、AZ2、AZ3作为多活的3个AZ提供服务，异地灾备地区Region的一个AZ作为灾备，异步复制北京 Region中的数据。 

异地多活的实现，一般有两种形式：一种是应用部署在同城两地或多地，数据库通过高可用主从复制，或者多集群同步保证数据的一致性；另一种理想形态是单元化服务，就是把单元作为系统部署的基本单位，在所有机房中部署数个单元，每个单元可以承担部分流量（甚至是全部流量），每个单元都采用对等部署，以此解决弹性伸缩和灰度发布问题，实现单元灰度发布和单元级扩缩容，同时也可以打破单IDC的容量上限，提升应用可用性及多AZ容灾。

单元化是在最顶层（全局视角）的一种架构方式。单元是指一个能完成所有处理的集合，这个集合包含了所有业务所需的服务，以及分配给这个单元的数据。单元化的核心思想是把数据的分片提前到入口请求的分片，在机房的网络接入层将用户请求根据某个纬度（比如用户ID）进行Sharding，这就好比把每个机房当做了一个巨大的有状态的数据库分片，如图2所示。

图2　单元化容灾多活架构

（三）中间件从集中式向分布式转型已成共识

在目前的传统金融企业中，集中式架构被广泛使用，其中以IOE架构为代表。在传统集中式架构中，计算能力强大、单点可靠性高的小型机，配套稳定而昂贵的存储，结合集中式的数据库，形成集中式架构的“三架马车”。随着业务模式的变化和企业数字化转型的需求，传统集中式架构的不足逐渐浮现，无法快速扩展，导致不能满足业务量日益增长的需求，同时由于使用专用的高端设备，产生了高昂的运营成本。随着技术的发展，分布式架构的出现很好地解决了以上痛点，而中间件迈向分布式架构的方向已经被广泛认同。国内的互联网公司普遍已经使用了分布式架构技术，而且有大量成功案例。在金融行业，转型分布式已经成为共识——以工商银行为例，其早在2014年就启动IT架构转型，从传统以集中式为主的架构体系向集中式和分布式架构有机融合的架构体系转型。

五、总结

金融行业的技术颠覆将会持续下去，云原生应用架构为企业的数字转型奠定了坚实的基础，使企业更接近数字技术。不断变化的业务需求正在向定制的云应用程序转变，而有了可供使用的云原生架构，就可以更多地关注其战略需求，从而利用现有的商机实现业务的进一步增长和繁荣。

目前国内企业在云原生分布式技术领域仍大量处于“学习者”“跟随者”的阶段，金融领域部分头部企业通过对优秀人才的培养以及过硬的技术体系规划迈入了“优化者”的行业。随着国内企业在云原生领域的深耕与实践，良性的技术回哺与孵化将使伟大的“创新者”未来可期。

摘自 | 《金融科技时代》2022年第2期

参考文献：

[1]中国信通院. 云原生发展白皮书（2020年）[EB/OL]. http://www.caict.ac.cn/kxyj/qwfb/bps/202007/P020200729486643037787.pdf.

[2]中国信通院. 中国云原生用户调查报告（2020年）[EB/OL]. http://www.caict.ac.cn/kxyj/qwfb/ztbg/202010/P020201021543952384452.pdf.

[3]CNCF. Cloud Native Survey China 2020（2020年）[EB/OL]. https://www.cncf.io/blog/2021/04/28/cncf-cloud-native-survey-china-2020/.

来源：金融科技时代

作者：网易数帆  朱剑峰