阿里云刘伟光：2 万字解读金融级云原生

作者：刘伟光，阿里云智能新金融&互联网行业总裁、中国金融四十人论坛常务理事，毕业于清华大学电子工程系

01 前言

2015年云原生理念提出的时候，彼时全球金融百年发展形成的信息化到数字化的背后，金融级的技术服务水准经过长时间的打磨已经形成行业共识的标准。8年前的云原生经典理念是聚焦在容器化、DevOps、持续开发持续集成、微服务架构这些软件开发层面的新范式。而金融级要求诸如高可用、高性能、业务连续性、系统安全稳定等等这些要求跟云原生架构的理念仿佛处在两个相距遥远的范畴。随着技术层面的不断演进，在新型的应用系统的开发方面，金融机构开始逐步引入容器化等云原生部署架构，但是始终发现聚焦在开发态层面的云原生能力是不能触达金融的系统建设的各个层面。云计算技术日新月异的变化反过来推动了云原生的发展从狭义到广义，今天的云已经变成了更为普适性的标准基础设施，更是新技术新业务创新的平台；因此诸如云原生大数据，和云原生存储以及云原生网络技术等技术让云的原生能力从软件开发走向数据平台进而延展到底层物理部署架构。今天的云计算无论是公共云还是专有云，其技术体系带来的先进性以及对开源的拥抱和支持确实在改变着行业面向未来的规划。

经过长时间的探索实践，我们提出一个全新的概念：金融级云原生，其核心思想就是让云原生从狭义变成广义，让云原生的先进思想从只覆盖应用开发扩展到系统物理部署架构这样的完整技术链路，从单纯的开发态转向设计态+研发态+运行态+运维态+容灾态，同时在每个范畴中都结合金融级的高可用、高性能、业务连续性等特征，总结和定义成金融级的全栈式的云原生架构的范式。这样的架构范式将把最先进的技术架构理念和最严苛的金融级SLA高度结合，旨在刻画出一套全栈云原生能力升级的技术体系，完整替换传统架构，在数字金融高速发展的今天，在人工智能的云时代中能够提供最强有力的支撑。

02 金融 IT 架构的发展

如果银行是钢铁侠，那IT系统就是他的战衣。

在过去40多年里，随着以银行为代表的金融行业的业务发展和转型，IT系统整体架构也同样经历过多轮的迭代演化，银行的信息化发展进程可概括为四个主要阶段：单机时代、联网联机时代、数据大集中时代、分布式云原生时代。

1）单机时代：以计算机取代手工，但没有信息互联，每个网点即一个单独的“电子账本”，成为信息孤岛。

2）联网联机时代：依托网络基础设施的完备，银行依托区域中型城市，以省市级主机为中心，将各网点业务联系起来，实现省市级互联。

3）数据大集中时代：各银行依据自身发展，不同程度的集中处理数据和业务，实现系统基础架构、物理服务器、数据和应用的大集中。

在数据大集中时代，也是银行IT信息化发展最快、对业务推动最大一个时期，其中整个IT系统建设的重中之重是“核心系统”。核心系统：Core Banking System，其中CORE是Centralized Online Real-time Exchange的意思，也就是“集中式在线实时交易”的缩写，并非字面的“核心”这么简单，突出一个“实时在线”信息交互，以转账支付为例，从原来最早的半个月缩短到“实时秒到”，正是通过数据大集中和核心系统的实时在线交易能力的建设，让中国金融服务大幅提升了服务能力和交易效率。银行的业务丰富度、业务交易量、数据量等也在不断屡创新高，与此同时，作为银行基石作用的核心系统对IT系统的处理性能、稳定性、安全性提出了极高的挑战和要求。而彼时的国内IT企业仍然无法承担起这样极高的要求，银行IT架构的唯一选择就是集中式架构。

4）分布式云原生时代：随着金融业务形态的不断扩充，集中式架构的扩展性不足、互联网式高并发应对能力不足、成本高、自主研发要求等缺陷不断凸显出来，同时分布式云原生技术也正在从银行的互联网服务平台逐渐走向核心系统的技术架构，逐渐成为银行新一代全行级主流技术架构。

集中式架构的特点： 集中式架构也指由IBM、Oracle、EMC三家厂商主导的系统架构范式，IBM的大/小型机、Oracle的数据库、EMC的存储器一直都是国产供应的短板，高度依赖集中式架构为核心的架构体系。集中式架构最大的特点就是部署结构简单，底层硬件一般采用从IBM、HP、Oracle等厂商购买到的昂贵的主机、小型机、一体机等，无需考虑如何对服务进行多节点的部署，也不用考虑各节点之间的“分布式协作问题”。一般采用“纵向垂直扩展”的方式，通过增加单机的资源配置来提升系统的处理能力，并通过增加硬件设备和基础软件的集群机制来提升系统的可用性。

分布式架构的特点： 系统由多个部署在不同的网络计算机上的模块构成，彼此之间通过网络进行消息传递进行通信和协调的系统。分布式系统采用“横向水平扩展”的方式，通过增加服务器的数量来提升系统的运行能力，理论上可以无限扩张运行能力。分布式系统采用集群化部署，集群中每个节点都是一个独立的运行单元，可以根据任务的大小随时增加或减小节点的数量。单个节点失效时也不会影响整体的可用性。

03 金融企业拥抱云原生的问题与冲突

“设计不是为了让东西变得漂亮，而是为了让东西更好地工作” 。同样云原生不是为了时髦，而是要解决问题。

阿里巴巴在2009年提出去集中式架构，在2013年基本完成去集中式架构。

硬件上，用标准化的X86服务器替代IBM的小型机和EMC的存储设备，解决性能扩张的压力。

软件上，用开源的OceanBase、MySQL替代Oracle数据库。

系统上，运用分布式云原生架构思路构建了新的体系。

阿里在去集中式架构过程中，不但通过用廉价、相对可控的PC服务器解决海量规模的计算问题，也推动云原生技术的成熟和广泛应用。随着金融行业的业务与技术不断迭代与发展，分布式云原生技术不但要解决高性能、高可靠、高弹性、高标准的要求，同时还需要围绕安全、风险、效能、容量成本等多个方面进行全公司级的架构设计考量，也就不得不面对如下8大问题。

问题1：何为云原生？何为金融级云原生？

CNCF最初对云原生定义是一个狭义的理念，更多是聚焦在软件开发层面的新的范式，定义为容器化部署+微服务架构+持续开发持续集成+DevOps这四大特征的“狭义云原生”，核心是面向应用开发者层面。但是随着云计算的不断演进，云原生存储、云原生网络、云原生数据库、云原生大数据、云原生AI、云原生业务中台等等都走向云原生的统一范畴，所以概念逐渐扩大化，说明“狭义云原生”还是聚焦在开发层面，还是不能完全解决客户的整体架构升级问题，所以形成了“广义云原生”。

而面对金融行业更加严苛的要求，需要解决不止是开发敏捷的问题，还需要解决架构先进性，将金融对安全合规、交易强一致性、单元化扩展、容灾多活、全链路业务风险管理、运维管理等各方面行业要求与云原生技术进行深度融合，实现对传统集中架构的整体架构升级，发展为一套既符合金融行业标准和要求、同时兼具原生技术架构优势，形成了“金融级云原生架构”。

问题2：云原生对IT运维管理的变化何在？

“车同轨、书同文、行同伦”

从IT架构演进来看，传统集中式架构虽然部署简单，但存在纵向烟囱割裂、横向管理分散的情况，每个层面和每个技术产品都独立分散管理运维。在虚拟化技术成熟后，实现了从底层服务器、存储、网络、虚拟机等层面的集中式统一管理，大幅提升了运维人员的管理半径。而云原生的核心理念是一切资源技术都以池化和服务的方式提供，不再是传统割裂烟囱式的资源供给关系。云原生架构更进一步实现了对IaaS资源、PaaS资源、分布式数据库、分布式中间件、容器、研发工艺等各类技术服务的标准化和统一管理，真正实现了科技层的“车同轨、书同文”，大幅降低了运维复杂性，提高了人均管理对象规模化。

问题3：云原生体系如何进行开源治理？

以前金融企业想使用云原生的技术或产品，需要花费大量的精力研究一些开源项目，自己做运维和管理，还需要考虑集成、稳定性保障等问题，这样才能建立一个云原生平台。金融机构开始意识到开源软件只能解决水面之上的、显性的、功能性的需求，大量的水面之下的、隐性的、非功能性的需求，开源软件并不具备，但却是金融机构在构建云原生应用时真正需要考虑的。

为了方便开发人员、运维人员更容易地使用云原生技术产品，越来越多的金融机构建立起了一套企业级云原生技术中台和技术标准，从产品集成、运行、监控、运维等多维度进行产品和架构治理，实现有SLA保障、有成熟案例、有技术规范、可灰度的云原生技术适配落地。

问题4：云原生如何与信息技术应用创新结合，实现1+1>2？

自顶向下的完整云原生技术栈代表着今天最先进的技术体系，因此在“信息技术应用创新”的技术方案选择中不能只是单纯的硬件思路或者单纯的点对点替换思路，更多应该是用最先进的云原生技术架构利用“信息技术应用创新”改造的机会实现全面能力的升级。

“信息技术应用创新”成为金融机构IT体系建设中不可忽略的重要因素，在构建云原生体系时，需要考虑这些方面的需求带来的挑战，例如“信息技术应用创新”软硬件供应链稳定性和国产芯片可靠性问题。

“信息技术应用创新”势必会导致金融机构面临不同芯片服务器的“碎片化问题”（造成管理复杂性增加、成本增加），如果将每一种类型的芯片集群都单独建云管理，这种多云的资源池割裂和分化，很难被云原生应用进行统一资源调度和使用，无法充分地利用到不同业务的峰值和低谷来进行弹性。除此之外，多朵云还会导致运维复杂，包括部署、升级和扩容等需要单独管理，运维管理成本高，操作体验差。

所以，“一云多芯+云原生” 成为了碎片化问题的最优解，“一云多芯”从根本上解决不同类型芯片共存所带来的多云管理问题（碎片化统一管理，将“多芯”的差异转变为“一云”的标准化服务）、云原生解决了资源整合问题（碎片化资源的小合大）。最大限度利用云上资源池的强大算力，实现多个芯片集群能力的算力资源整合，真正形成1+1>2的一朵云。

问题5：云原生架构对业务安全生产如何应对？ 

根据“墨菲定律”——“怀疑一切、任何节点失败都会发生！” （“Anything that can go wrong will go wrong”）。云原生应用架构设计原则是，将影响安全生产的潜在“黑天鹅”风险作为“常态”。

云原生架构的建议是：允许失败发生，确保每个服务器，每个组件都能够在不影响系统的情况下发生故障并且具备自愈和可替代能力。立即失效（Fail fast and Fail small）是云原生系统一个重要的设计原则，它背后的哲学是既然故障无法避免，问题越及早暴露、应用越容易恢复，进入生产环境的问题就越少。Fail small 的本质在于控制故障的影响范围——爆炸半径，关注点将从如何穷尽系统中的问题转移到如何快速地发现和优雅处理失败。

金融级云原生架构来说技术风险亦是重中之重。 任何一笔交易处理的差错背后都有可能导致不可预计的资金损失。需要建立一套专业的技术风险体系（SRE，Site Risk Engineering），确保从系统架构平台到风险文化机制，在架构设计、产品开发、变更上线、稳定性评估到故障定位恢复等等环节，都能全生命周期地确保风险质量控制，对任何系统变更作兜底保障。

问题6：云原生架构对业务连续性如何保证？ 

对金融机构而言，当业务上线后，最不能接受的就是业务不可用。

云原生的韧性能力代表了当系统所依赖的软硬件组件出现各种异常时，整个系统表现出来的抵御能力，这些异常通常包括硬件故障、硬件资源瓶颈（如 CPU/网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等对业务不可用带来致命影响的因素。韧性从多个维度诠释了系统持续提供业务服务的能力，核心是从云原生架构设计上，整体提升系统的业务连续性，提升系统韧性。金融级云原生的韧性能力包括：服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ内的高可用、单元化、跨Region容灾、异地多活容灾等。

问题7：云原生架构对交易一致性如何应对？ 

人们希望像使用单机系统一样使用分布式系统，因此不可避免的需要面对 “分布式一致性” 问题。

云原生中微服务中“微”代表了服务颗粒度变小，而金融交易的复杂性又相对较大。 所以在云原生系统的数据一致性是一个相对复杂的问题，不同微服务中独立的数据存储，使得维护数据的一致性变得困难。由于分布式微服务系统中的网络错误不可避免，基于CAP定理，当出现网络分区时，就需要云原生架构能够在一致性和可用性之间进行平衡。

所以金融级云原生架构规划时，也会遇到金融业务对一致性的挑战，这种一致性不仅体现在业务逻辑上（TCC、SAGA、XA事务、消息队列等），也更多地需要在数据层面上一致性保障（多节点一致性、多中心一致性）。

问题8：云原生架构与应用设计与研发有哪些挑战？

使人疲惫的不是远方的高山，而是鞋里的一粒沙子。

虽然云原生技术有诸多好处，金融机构往往拥有大量的存量系统，这些存量系统的技术体系往往与云原生技术存在差异，如何对存量系统与新的云原生应用进行集成、治理？微服务的拆分策略如何制定，如何衡量拆分的维度、拆分的标准和拆分的颗粒度？如何建立云原生的可观测体系，实施有效的监控、日志管理和告警，实时监控应用性能、资源使用情况，问题发生时快速定位并解决问题？

这些问题挑战深层次解决，很多金融机构意识到需要云原生技术中台在设计态、研发态、运行态、运维态、容灾态这5态进行统一技术规范，能够实现标准贯穿和设计前置，将运维、容灾、安全等后端能力和要求，在设计和研发阶段就进行考虑、设计、前置，用云原生技术来解决后端人力工作量和管理复杂性。

04 金融级云原生的“新标准和新蓝图”

金融级云原生的发展过程

Kevin Kelly在《失控：全人类的最终命运和结局》中对现代科技预言的准确性，让作者成为诸多科技从业者心中的预言帝，本书亦成为圣典。书中描述中强调了两个关键点：

1、复杂系统由大量独立自治的简单系统分层组合而成。

2、复杂动作是简单动作组装而成，不是修改而成。

整个体系由不同层次的多个职责单一的“微系统”构成（微服务），并且系统本身具备容错性和迭代自由度，可在整体上达到一个动态容错能力。最重要的是，整个体系中没有 “集中式的上帝之手”的存在。这与云原生所倡导的系统架构设计不谋而合，甚至云原生诞生也受此启发。

正所谓 “一鲸落、万物生”，随着传统集中式架构的衰落和退潮，云原生技术正在全面成长和涌现。

云原生，本质上就是因云而生的软件、硬件、架构。云原生也是不断发展演进的过程，云原生（Cloud Native）概念在2015年被提出，后经CNCF进一步发展和提炼形成了包括容器、持续交付、持续集成、服务网格、微服务、不可变基础设施和声明式API的“狭义云原生”概念。

今天，当我们讨论“数字化”时候 ，事实上有两个概念 ，一个叫原生、一个叫转型。 狭义云原生技术主要面对的是互联网类的“数字化原生”企业的敏捷创新新型要求，多以互联网类的无状态的应用为主，对数据一致性要求以最终一致性为主。而对传统金融类“数字化转型”企业的已有的技术标准和技术资产（包袱）往往有较大的阻碍。

随着云计算技术的不断深化普及，越来越多的新技术 “因云而生” ，这些 “ 生于云、长于云” 的产品、技术、软件、硬件、架构都逐渐成熟，并构成了“广义云原”生概念。未来“生于云、长于云”的“云原生”型产品将会不断涌现：新一代数据库、人工智能、存储、芯片、网络和健康码。云原生极致的弹性、服务自治、大规模可复制等能力，更容易实现异构资源标准化、加速数字生产力释放、加快业务应用的迭代速度、推动业务创新。它是数字化时代中众多不确定性中“最大的确定性”，它强大的包容性代表了未来数字化企业的整体技术架构方向。广义云原生技术除了对“数字化原生企业”的技术架构敏捷创新要求之外，也兼顾了传统“数字转型化企业”的技术标准和架构兼容需求，所以具备更加广泛的技术架构适用度、更好的企业级服务能力。

今天，随着云原生逐渐从社区走向金融机构、越来越深入人心，金融机构开始研究如何结合金融场景要求的云原生落地 -- 将金融对安全合规、交易强一致性、单元化扩展、容灾多活、全链路业务风险管理、运维管理等各方面行业要求与云原生技术进行深度融合，发展为一套既符合金融行业标准和要求、又具备云原生技术优势的“金融级云原生架构”。能够更好地满足金融级对IT环境严苛地挑战和要求，为金融机构的传统“稳态应用”（数字化转型）和 “敏态应用” （数字化原生）应用提供统一的技术架构支持。

如果把过去金融的集中式架构（中央大脑）的统一控制作为“左”，完全的开源式的分布式云原生作为“右”。在金融云原生架构下，金融机构所需要的技术架构就是在左和右之间寻求一个平衡点，做到：既具备金融级的安全、强一致性、可靠性，又具备容错、扩展和快速响应的能力。提出“强局部自治、弱中心控制”架构来并屏蔽应用复杂性（例如：GRC架构，G-Global全局系统、R-Region 区域系统、C-City 局部系统)，仅将需要综合多方因素判断的复杂逻辑交由全局系统（中央大脑）完成，减轻中心系统的负担，而对于大量的日常简单判断和执行动作放在局部系统内闭环完成，提升容错能力，进而提高整体系统的鲁棒。

定义金融云原生的10大新要素

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全性、可观测性、灰度等)，在没有非功能性业务中断困扰的同时，使业务具备轻量、敏捷、高度自动化的特点。在传统架构中，应用层有较多的非业务代码；而在云原生架构下，理想情况是不再有非功能性代码在应用代码逻辑中体现，而让其下沉到基础设施中去，业务运维人员也只需专注于与业务代码相关的部分。我们将金融级云原生的核心总结为如下10大架构要素。

要素1：平台工程 & 不可变基础设施

面对云原生技术大规模使用，降低金融机构在研发和运维层面的复杂性，是制约云原生技术落地的一个很大阻碍。目前从研发管理和运维管理角度， “平台工程”和“不可变基础设施”是两个可以大幅降低复杂性的云原生关键能力。

DevOps理念是“谁构建，谁运行”，开发人员应该能够端到端地开发、部署和运行他们的应用。但对于大多数金融机构而言，这实际上并不容易实现。而原来被证明有效的劳动分工（Ops 和 Dev）对人才要求相对更低，但随着DevOps范式的推崇，研发人员必须对所有事情都了如指掌，大大增加了“认知负担”。这对金融机构的研发团队提出了很高的要求，不利于普适型人才建设，也会很大程度地阻碍金融机构在云原生应用的全面引入。如果说改进最可能的一个方向，那么非平台工程（Platform Engineering）莫属了，平台工程是DevOps和业务程序员之间桥梁。让开发人员更快更好交付业务软件的自助服务平台。通过简单页面化的操作，就能完成这个环节的串联配置，让研发无需关注诸多运维工具的细节，专注在应用功能研发上即可。Gartner对平台工程的描述 “平台汇集的工具、能力和流程均由领域专家精心挑选，并经过封装，以方便端用户使用。其最终的目标，是打造无摩擦的自助服务体验，为用户提供正确的能力，帮助其以最少的成本完成重要工作，提高终端用户的生产力，并减少他们的认知负担。”

传统的可变基础设施是指应用服务基于物理机或虚拟服务器进行部署，运行环境的构建依赖很多变量，诸如一些服务器上的配置、基础软件等，在不同环境之间可以通过动态配置下发或实时访问外部服务更新应用的状态，整个应用服务所依赖的基础设施一直处于变化之中，当出现需要进行应急回滚的场景时，运维人员处理流程往往会比较复杂，容易出错。

云原生不可变基础设施是指基于云原生的镜像化方案将应用依赖的基础设施（操作系统、安全脚本、运维 Agent 、开发框架、运行环境等）打包成不可变的镜像，应用发布时只需依赖镜像将容器拉起即可，极大地降低了应用的部署和运维成本，使得应用部署及运维变得更简单、更可预测，同时应用运行环境也获得了更高的一致性和可靠性。此外，基于镜像还可以实现自动轮转替换、自动回滚等运维功能，大幅提升了应用运维的自动化水平。一方面通过镜像分层可以提升镜像的管理水平，另一方面根据容器加载镜像的原理镜像分层可以一定程度上提升镜像加载效率，从而提升应用启动速度。

要素2：弹性混合云

随着云架构成为金融机构的平台和基础设施主流，按照业务单元具备按需弹性伸缩的能力，在面临流量高峰时可以快速弹性扩展以提升资源和应用处理能力，当应用流量高峰过后可以快速释放资源，以达到最大程度的资源利用率，因此需要构建一个灵活、可低成本复制的弹性架构。弹性架构本质是单元化架构的扩展，提供了一种以单元化架构中业务单元为最小粒度进行弹性伸缩的能力，主要包含弹出和弹回两个动作。弹出是以业务单元为基础的计算资源、网络、应用、数据层面的全面弹出，是一个从底层资源到上层流量的整体弹性手段，弹出的单元称之为弹性业务单元。区别于普通业务单元，弹性业务单元具备以下几个特征：

局部性： 常规模式下扩展出的每个业务单元需要包含全量应用和全量数据，而弹性架构下弹出的弹性业务单元只需要包含单元内的部分应用和部分数据即可，通常是高流量链路涉及的相关应用。

临时性： 区别于普通业务单元生命周期较长的特点，弹性业务单元的生命周期比较短，在支持“双十一”等大促支付高峰后，弹性业务单元的业务请求会弹回到常规业务单元，随后会对弹性业务单元进行释放，以节省成本。

跨云： 弹性业务单元通常会处于另外一朵或几朵云之中，弹性架构运用的场景所面对的流量峰值是日常的数倍，日常所在的云计算底座很难提供充足的资源，这时就需要其他云计算底座提供大量的资源支持。

弹性架构充分发挥了混合云的优势，海量的云资源让应用可以无限扩展以应对极高的流量峰值，在达到流量峰值后可以进行资源的快速释放，真正做到资源按需弹性伸缩。

要素3：资源混合部署

在日常生产中，在线服务应用为了确保较高的服务质量，往往会长期运行并且独占CPU资源，但CPU利用率却很低;而离线计算任务正好相反，通常是短生命周期且对资源服务质量要求不高，但运行期CPU利用率很高。随着业务规模的扩大，在线业务集群和离线集群资源池逐步变大，由于存在业务低峰期，会遇到资源利用率的问题，一个比较明显的现象就是集群的资源分配率很高但是实际利用率偏低。

金融机构在云原生架构建设过程中进行在线和离线集群混合部署，除了通过CPU弹性共享和优先级抢占、离/在线应用错峰编排、应用QoS等级划分、内存分级管理等核心能力，以资源隔离和动态调整为基础，将不同属性类型的在线服务和离线计算类服务进行精确组合，解决资源错峰高效利用的问题外。对应到金融级的复杂性，需要建设如下混部能力标准：

大规模化、多场景的混部，将混部技术打造为业务运行的基础设施及环境，完善混部技术能力输出，便于推广到其他资源环境；

打通混部管控与运维体系一致性。统一资源接入流程，确保基础软件、配等置全局一致性维护与管理；

资源调度的灵活、高效、精细流程，在线-离线业务快速资源切换、一体化资源调度；

混部稳定性，达到和非混部同等量级的稳定性指标。依赖精细化地服务度量制定，以及资源隔离与业务运行适配度提升；

混部监控体系，提高运行时监控、异常发现与诊断能力；

混部异常应急机制，针对稳定性风险提前识别场景，并制定流程化应急机制，打造异常快速恢复能力。

要素4：多技术栈异构集成

服务网格可看作基础设施层，用于处理服务间的通信。现代云原生应用有着复杂的服务拓扑，服务网格负责在这些拓扑中实现请求的可靠传递。实践中，服务网格通常是一组轻量级网络代理，与应用程序部署在一起，可以将其比作应用程序或微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。

在服务网格技术应用之前，微服务体系的实现方式往往由中间件团队为业务应用提供一个SDK，在SDK中会集成各种服务治理能力，如服务发现、负载均衡、熔断限流、服务路由等。在运行时，SDK和业务应用的代码混合在一个进程中运行，耦合度非常高，这就带来了一系列问题：

一升级成本高。每次升级SDK都需要业务应用修改SDK版本号，再重新发布应用。在业务快速发展的时候，这类升级会影响到研发效率。

二是版本碎片化严重。由于SDK升级成本高，且中间件不断向前发展，久而久之，就会导致SDK版本各不统一、能力参差不齐等问题，给统一治理带来巨大的工作量。

三是中间件演进困难。由于SDK版本碎片化严重，导致中间件向前演进时需要在代码中兼容各种各样的老版本逻辑，如同戴着枷锁前行，无法实现快速迭代。

金融机构的服务网格把原来通过SDK集成的一些网络通信能力下沉到Sidecar中，包括基本的RPC、消息、DB访问能力，以及在此基础上的服务发现、熔断、限流、流量管控、数据库分库分表的能力，以此给业务系统带来较为透明的通信基础设施，将基础设施的迭代演进与业务系统解耦，让业务研发专注于业务逻辑，减轻业务系统的负担，提升业务系统及基础设施的迭代效率。

要素5：基础架构连续性（公专一体）

当越来越多的核心系统也在走向全面云原生化，大规模资源的调度编排对于金融基础架构连续性成为必不可少的能力。如何为金融机构内不同业务部门成千上万个应用提供服务，如何让不同应用使用好云，满足不同应用对资源诉求的差异并充分利用好云的能力支撑业务增长，基础架构连续性需要具备像公共云一样的统一资源的管理能力，这不仅仅包括传统的泛交易类和数据类场景，也包括以GPU为代表的新型异构计算硬件在大规模计算中的采用比例越来越高，如分布式深度学习训练任务，在线推理任务，流媒体编解码任务等，所需要的更丰富的资源计算场景。

统一的基础架构连续性进行底层资源的统一运营与管理，可以从供应链、容量预测、容量规划、资源池弹性等多个维度，通过云原生的丰富技术手段来优化成本提升效率，针对租户Quota的管控能够做到实时且准确，底层资源实现零泄露，以扁平易管理，灵活可配置，弹性可借调的方式同时支持所有的场景。

要素6：全链路技术风险防控

金融业务系统生产故障有较多都源于变更，变更管控对技术风险防控而言至关重要。特别是在微服务分布式架构下，服务规模巨大，变更来源广泛，如变更没有很强的管控、追踪能力，一旦线上发生问题，依赖人工追根溯源很难第一时间快速找到对应的变更，变更本身的质量也很难有效控制，这就需要有一套基于云原生架构的“技术风险防控体系”，来进行全链路的风险和变更管控。

技术风险防控的核心指导原则是“变更三板斧”：可观测、可灰度、可应急。任何变更都需要在执行前部署好可观测能力，用于评判预期内的效果，识别预期外的问题，用于指导进一步扩大变更范围和决策应急处置动作。“可灰度”强调的是变更需要逐步扩大范围，从地域、数据中心、环境、服务器、用户、时间等多个维度去设计灰度过程。“可应急”强调的是变更方案要优先保障可回退能力，一些变更由于情况特殊，不一定具备可回退能力或者回退代价无法接受，这就需要通过追加其他变更来处置，比如数据订正、新版本上线等。“变更三板斧”也是金融云原生架构下变更风控的核心能力，金融级云原生架构需要在变更流程设计和运维平台执行过程中强制约束了可“灰度”的落地，同时通过可观测能力的整合，在变更过程中建设一些熔断、自愈能力。

“全链路风险防控体系”的核心职责是通过整合所有变更信息，使变更可见、更可追溯。同时，提供变更编排、变更灰度检查、变更预检、变更结果监控预警等能力，当出现问题时通过提供变更关联来加快线上问题处理速度。

此外，全链路风险防控体系还需要能够产出资损风险点分析，制订防控措施，明确预案细节；在质量测试分析阶段要进行资金验证的测试分析。发布前要再次评估风险，检查资损防控措施是否实施完成，包括实时核对、 T + M 分钟级核对、 T + H 小时级核对、 T +1隔日核对等多维度布防，并“责任到人”订阅核对预警，同时业务方对资金流要进行完整的验收。通过证证、证账、账账、账实等核对模式进行资金流操作。

要素7：云原生安全可信

当前，互联网环境下的外部威胁趋于多样化、新型化，传统的防御手段对于已知的漏洞利用和威胁攻击手法具有较好的应对效果，但是无法很好地应对APT攻击、0Day漏洞攻击等新型威胁。然而，这些已知的和新型的威胁存在着共同的特点：均是业务预期外的行为。基于此特点，云原生技术需要对所有的服务请求及资源加载行为进行可信度量，建立起基于可信行为的安全纵深防御体系，确保只有预期内的行为可以访问执行成功，对预期外的行为进行阻断拦截来达到抵御已知和未知威胁的效果。

同时，金融行业为保障业务主体之间的安全隔离，基础设施等技术服务也要从业务主体中构建隔离的环境，具备独立隔离的网络环境和更高等级的安全保障。云原生平台技术服务按照可信原生服务标准进行相关的多租户隔离、统一管控、可信通道收敛等相关改造，升级为可信原生服务。针对应用运行时所处的环境，云原生安全可信架构在基础设施中内置身份、认证、鉴权、全链路访问控制、全链路加密等安全可信能力，并尽可能实现基础设施与应用的解耦，以可信原生的方式减少对业务的打扰，提供可信的应用运行环境。

要素8：金融级一致性

云原生应用以分布式系统为主，应用会被切分到多个分布式的微服务系统下，拆分一般分为水平拆分和垂直拆分，这并不仅仅单指对数据库或者缓存的拆分，主要是表达一种分而治之的思想和逻辑。

分布式系统的底层无法逃离 “CAP的不可能三角” （C: Consistency，一致性；A: Availability，可用性；P: Partition tolerance，分区容忍性）。CAP原理证明，任何分布式系统只可同时满足以上两点，无法三者兼顾。而分布式的服务化系统都需要满足分区容忍性，那么必须在一致性和可用性之间进行权衡。 如果网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，可能会导致分布式系统出现网络分区。复制操作可能会被延后，如果这时我们的使用方等待复制完成再返回，则可能导致在有限时间内无法返回，就失去了可用性；而如果使用方不等待复制完成，而在主分片写完后直接返回，则具有了可用性，但是失去了一致性。

对金融机构而言，架构层面的高可用和业务层面的强一致性，几乎同样重要。这就需要金融级云原生能够很好地平衡“CAP的不可能三角”，需要尽可能兼顾业务强一致与系统高可用。

但是“一致性挑战”在分布式系统中绝不仅仅是一个数据库问题，而是一个大的话题，涵盖分布式系统的各个层面：事务一致性、节点一致性、系统间业务一致性、消息幂等一致性、缓存一致性、跨IDC一致性等等。所以也需要云原生架构有一系列技术能够应对金融级对一致性的严苛挑战。

事务级： 需要根据不同的金融场景选择合适的分布式事务模式，在平衡成本和性能后，SAGA和TCC是目前金融机构比较常用的两种分布式事务模式。SAGA模式对应用实现侵入性更小，但基于补偿事务来保障一致性的设计、前后步骤执行过程中不保证事务隔离性；而TCC模式能做到比较好的事务隔离性，但需要应用层感知更多的复杂度。对于事务流程中部分不需要同步返回结果的节点，为提高执行效率可采用异步消息队列实现，对于一些事务流程较长的场景可明显降低事务实现复杂度、削峰填谷。典型场景如客户购买理财场景简化分为存款账户扣款和理财账户入账两个步骤，如选用SAGA模式，存款账户成功扣款后、理财账户入账失败，客户会看到“钱已付、货没到”的中间异常状态，需要系统进行冲正存款账户扣款来保障事务一致性。若选用TCC模式，先后完成存款账户扣款、理财账户入账的逻辑处理，各自需要存款系统和理财系统记录逻辑处理的状态，二者均成功后再发起统一提交。

数据库级： 金融场景下对于数据不丢有着极致的要求，一方面需要在同城、异地多个机房保存多个副本，另一方面需要在多个副本之间实现数据同步，保障同城RPO为零、异地RPO接近零。Paxos算法是基于消息传递的实现分布式系统数据一致性的算法，是至今为止公认的实现一致性的最有效的算法之一，分布式数据库通过对Paxos的支持来实现跨多服务器，甚至跨多中心的数据一致性保证。

机房级： 跨机房的路由能力、异常事务的跨机房恢复能力。发生机房故障时，数据库需要能够切到同城/异地的副本、并保障RPO为零，配合应用层的交易路由切换，完成机房级容灾切换、恢复业务。期间因机房故障导致的部分交易事务流程中断，分布式事务组件需要具备自动恢复能力，重新启动中断的事务流程按事先设定的业务规则向前完成或向后冲正。

要素9：单元化多地多活

随着数字金融业务的快速发展，传统集中式生产环境已经很难满足需求。当前演化方向是“异地多活”的单元化架构，以单元化机房（后面简称为LDC）为基础运行单元，以满足快速发展的数字金融业务对基础设施扩展和容灾的高时效性、金融级安全性要求。

金融机构普遍采用的“两地三中心”架构有几个典型的不足，一是该架构要求同城双中心具备接近的机房容量以满足全量切换，二是该架构模式下异地容灾系统平时一般是“冷”的，并不真正承载业务流量，且灾难发生时很难接管全量业务。随着新建数据中心普遍集中在内蒙、贵州等远离传统数据中心的地域，新老数据中心容量配比很不均衡等客观条件限制下，要求金融机构在运行架构上突破“两地三中心”的传统模式，向N+1“多活”的灾备方案演进，进一步提升故障恢复的体系性能力。

“异地多活架构”是指基于LDC单元化架构的扩展能力，在不同地域的IDC中部署LDC单元，并且每个LDC单元都是“活”的，是真正承接线上真实业务流量的，在发生故障时，可以进行LDC单元之间的快速切换。 异地多活单元化架构解决了以下四个关键问题：

由于尽量减少了跨单元交互和使用异步化，使得异地部署成为可能。整个系统的水平可伸缩性大大提高，不再依赖同城IDC；

可以实现N+1的异地灾备策略，大大缩减灾备成本，同时确保灾备设施真实可用；

整个系统已无单点存在，大大提升了整体的高可用性；同城和异地部署的多个单元可用作互备的容灾设施，通过运维管控平台进行快速切换，有机会实现100%的持续可用率；

该架构下业务级别的流量入口和出口形成了统一的可管控、可路由的控制点，整体系统的可管控能力得到很大提升。基于该架构，线上压测、流量管控、灰度发布等以前难以实现的运维管控模式，现在能够十分轻松地实现。

要素10：业务连续性和数智化运维

在云原生环境下需要对多个容器、多个虚拟机、多个主机、多个可用区、甚至多个地域上的信息进行关联，才可能回答清楚服务为什么宕机、为什么没有实现定义的SLO、故障影响了哪些用户和业务等这一系列问题，才可能基于运维数据和AI智能实现高效的“监控、变更、应急、容量、容灾、演练”数智化运维管理。

云原生数智化运维主要包括七方面能力：

监控发现能力：指标、日志、链路全方位可观测性，全面覆盖业务、中间件和基础设施，并且可层层下钻。

故障应急处置能力：异常全面发现，快速定位和恢复的能力，确保业务SLA。

变更风险防控能力：业务全方位变更管控，严守“可灰度、可观测，可回滚”三板斧。

容量管理能力：从业务到基础设施提供全链路容量精准评估和风险提前识别能力，达到稳定与成本的平衡。

容灾管理能力：平台化可编排容灾，支撑机房容灾，单元化容灾等场景，覆盖演练，切换和大屏等能力。

演练评测能力：通过混沌工程、红蓝攻防等方式，对业务风险保障能力进行探测和检验。

资金安全保障能力：基于资金安全核对规则，通过离线、实时、文件等方式对业务系统的资金流进行监测。

云原生数智化运维主要具备三方面特征：

高效 : 通过运维工作的平台化来提高运维效率。如系统监控平台、变更管控平台、动态资源管控平台、调度中心、注册中心等。

安全：基于自动业务验证平台和大数据运算规则，保障系统运行的稳定性与正确性。如数据核对中心、依赖管控平台、容量检测管控平台等。

智能：基于大数据的分析和规则计算，进行智能化的运维管控。如自动故障分析处理系统、容量自动探测扩容系统等。

构建金融云原生的新蓝图

金融级云原生应用架构 

《架构即未来》一书提出了分布式应用设计的十四条基本原则，而这正是最为重要的云原生应用架构的核心要素。

N+1设计：要确保任何你所开发的系统在发生故障时，至少有一个冗余的实例。回滚设计：确保系统可以回滚到以前发布过的任何版本。

开关禁用设计：能够关闭任何发布的功能。监控设计：在设计阶段就必须要考虑监控，而不是在实施完成之后补充。

设计多活数据中心：设计时就考虑多活部署，不要被一个数据中心的解决方案把自己限制住。

异步设计：异步适合并发，只有在绝对必要的时候才进行同步调用。

无状态系统：无状态的系统更利于扩展，更利于做负载均衡。只有当业务确实需要的时候，才使用状态。

水平扩展非垂直升级：永远不要依赖更大、更快的系统。微服务核心思想是水平扩展，不要把所有的功能都集中在一个系统里面。必要的时候把需求分为多个系统，而不是升级原有的系统。

设计的前瞻性：提前考虑影响下一阶段系统扩展性问题的方案，不断提炼公共共享服务，以减少重构的次数。

非核心则购买：如果不是你最擅长的，也提供不了差异化的竞争优势则直接购买。数据库、云服务这种的就购买好了。

小构建，小发布，快试错：全部研发要小构建，不断迭代，让系统不断地成长。小版本的失败率较低，因为失败率与解决方案中的变更数量直接相关。

隔离故障：实现隔离故障设计，通过断路保护避免故障传播和交叉影响。避免多系统之间的互相影响，这个很重要。

自动化：“自动化是智慧之源”，在云原生架构中，快速部署和自动化管理是核心。设计开始就需要尽可能通过架构和设计实现自动化的过程。如果机器可以做，就不要依赖于人。

使用成熟的技术：如果某技术故障率比较高，就绝不能使用。

金融级云原生平台架构

金融云原生平台架构整体可分为：设计域、研发域、运行域、运维域、灾备域 5大领域。

设计态：采用领域驱动设计等与微服务架构体系天然亲和的设计方法，并在设计过程中，关注数据一致性、服务颗粒度等问题，贯彻分布式架构设计的设计原则和规范。

研发态：面向研发人员，提供一站式的研发生产力工具，屏蔽分布式技术的复杂性，提升研发人员体验和生产率。达成广泛共识的工程模板，降低组织认知成本。

运行态：面向应用，分布式应用运行的基础设施，覆盖应用全生命周期，包括创建、部署、监控、变配，支持多种形态的应用交互方式和数据存储形态。底层支持多种形态的计算方式以及其上的调度方式。

运维态：面向运维人员，解决分布式架构的先天复杂性，广泛使用工程手段，保证系统整体可用性水平。

灾备态：面向灾难，提供对节点级、机房级、城市级灾难的容忍能力。

金融级云原生数据架构 

云原生框架天生具备快速交付、弹性伸缩、标准化、自动化、隔离性等诸多优势，与新一代数据技术不断融合，形成了具备如下几个特点的云原生数据架构体系。

1、可扩展的多种计算模式融合

云原生数据架构可统一支持批、流、交互式、多模、图等不同计算模式的融合，例如：湖仓一体、流批一体、流式机器学习，使多种计算系统进行深度整合，在功能、生态上形成互补，用户能够在一套系统内完成更多种类型计算,提升平台运行效率，降低使用成本。

2、多层智能化的分布式存储层

存储计算分离会在两三年内成为标准，数据平台向托管化和云原生的方向发展。存储内部精细化的分层成为平衡性能和成本的关键手段，基于分布式存储系统上的多层存储(热存储/标准存储/冷存储等)与存储利用相结合实现存储降本。AI在分层算法上将发挥更大的作用，编码和压缩在通用处理器上的优化空间有限的情况下，未来更大的突破和技术换代将取决于软硬一体化的技术发展及应用情况。

3、统一调度和弹性伸缩的资源池管理

随着数据湖存算分离不断深入, 围绕基于云原生架构下来建立统一容器化资源调度系统成为数据湖存算分离发展的必要组件，为大数据与AI一体化架构提供统一资源池化与在离线混部的基础支撑；通过统一算力资源池实现资源统筹调度，优化资源细粒度的管理与调度，可以将离线计算与其它在线计算任务进行资源混部达到峰谷互补的效果，有助于提升服务器资源利用率；同时，也可以根据业务优先级分配计算任务资源，确保资源调度期间不发生争抢，实现在业务高峰期，以弹性扩缩容模式调用算力资源，充分发挥资源算力，提升响应效率。

4、大数据SRE智能运维能力

大数据技术多样性和数据平台架构的复杂性，为大数据平台的运维带来挑战。新一代大数据平台可支持在线滚动升级，缩短升级时长；提供统一运行各类异构工作负载流程，统一管理作业生命周期，统一调度任务工作流，为任务的规模和性能提供保证；通过作业日志，性能指标，资源利用率等数据，结合历史记录和实时负载情况，使用机器学习方式进行分析、检测和调优，在查询计划、数据模型、资源管理自适应，以及系统异常检测和自愈等方面不断优化，形成大规模数据平台的智能化运维能力。

金融级云原生基础架构 

金融级云原生基础设施需要满足5大总体要求和13项管理要求。

（一） 5大总体要求为：

一是采用成熟云平台产品，打造IaaS、PaaS一体化云计算平台，实现租户端和运维端的完整服务目录，与软件开发体系和生产运维体系无缝对接；

二是实现全公司级基础资源弹性供给，按照分布式技术框架，支撑全公司业务系统实现高可用容灾架构，满足安全生产要求；

三是全面满足信息技术应用创新要求，从云平台底座到软件服务具有全链路信息技术应用创新运行的能力，同时保障分布式应用高性能稳定运行；

四是具备提供大规模应用上云的基础，提供完善的应用框架，对应用系统提供稳定、持续、高性能的支撑；

五是云平台产品有成熟生态圈，与业界公有云技术发展保持基本同步，适配最新开源技术演进。

（二）  13项管理能力要求为：

统一资源管理：采用统一的物理资源类型和架构实现基础硬件资源的统一管理，如服务器、交换机、操作系统等；云管平台通过统一管理方式（控制台、API等）实现两地三中心的计算、存储、网络等云资源进行管理，降低开发和运维使用复杂度。

统一数据管理：对同城双活、异地多活架构通过数据存储、迁移、同步等方式，保障分布式云节点数据一致性，提供一体化容灾及联动切换能力，最大限度满足业务连续性要求。如提供统一的镜像方案、对象存储的容灾、数据库跨地域备份和同步等。

统一服务管理：支持两地三中心节点通过统一的API、SDK、控制台等管理云服务，如统一控制面进行服务的部署、更新等，大幅降低云服务管理复杂度，提升用云效率。

统一运维管理：通过云管实现对两地三中心不同节点采用相同的运维体系进行管理，提供一致的运营、监控、可靠性SLA等服务，减少运维管理人员工作量，提升运维效率，大幅降低系统故障，缩短故障时间。

统一安全管理：一方面通过物理基础设施、网络安全、数据面/控制面隔离等实现平台侧安全，另一方面通过主机安全、访问控制、防火墙、态势感知等实现安全服务，保障一体化安全。

统一资源调度：通过云管实现对两地三中心算力资源的统一调度，提供多种调度策略支持。基于位置调度满足对时延和带宽敏感的业务（如手机银行音视频应用）；基于算力需求调度满足对AI、大数据等大计算量的业务（如潮汐调度、混部等场景）；基于工作负载调度满足多维异构的场景（如理财抢购、积分兑换、双11等应用场景）。

统一监控管理：完成云上和云下各类型监控指标的接入和统一展现；完成云上和云下分布式链路追踪能力，实现从业务监控、到应用服务监控、到资源监控的逐层下钻和多维分析，完善故障定位分析能力；通过统一告警中心的对接和优化完成动态阈值，提升业务整体事件感知能力、快速定位能力和智能化分析决策能力。

支撑多元算力：云资源池兼容CPU、GPU等多种算力，为人工智能、深度学习、科学计算等多领域场景的金融科技类新应用产品提供高效的云算力服务。

支撑全栈信息技术应用创新：通过一套体系兼容多产品服务能力，支撑一云多芯、全栈XC云平台服务能力，推动信息技术应用创新战略落地。

支撑精细化管理：通过平台的计量计费能力以及与行内各系统打通，实现计算、存储、网络、安全等多类资源的计量计费能力。逐步实现IT成本精细化管理，实现业务IT投入与业务产出可度量、可评价，实现成本与效率的兼顾，实现IT资源的高效利用。

支撑裸机管理：满足裸金属交付从服务器上架、自动化装机、系统设置和软件编排的流程自动化和批量化，提升交付效率，降低人工工作量；满足裸金属统一纳管要求，实现裸机的统一监控和告警。

支撑服务质量：通过自服务能力提升，基础设施管理平台的建设将能够提供高效稳定运行精细化管理提供更好的服务，根据平台对于数据的收集及分析，将有效的改进管理方向和内容，能有效增强服务品质。

支撑架构发展：采用行业领先的专有云架构，搭建与公有云同源、满足金融行业容灾要求的云平台，通过一套体系支撑所有产品，支撑全行线上线下一体化运维体系建设，通过有机统一的体系结构设计，满足未来全栈云平台能力建设。

05 金融级云原生实现路径

金融级云原生能力评估

“投资未来的最好方法是改善现在”。

金融级云原生极大的释放了数字化时代的红利，云原生充分继承云的设计思想，未来应用将更多基于云上进行应用开发，即云原生应用更加适合云的架构，而云计算也为云原生应用提供较好的基础支撑，如资源隔离机制、分布式部署、高可用架构等方面，通过新的架构、技术保障应用系统变得更加健壮，可以说云原生最大程度发挥了云的优势。

某银行基于IaaS/PaaS 一体化云平台，运用分布式微服务框架、云中间件、容器、DevOps 等云原生技术，搭建了可提供横向扩展、秒级伸缩、智能运维、适应快速开发持续交付的 PaaS 级云平台，推动该银行从传统架构向互联网架构演进。该平台基于容器进行应用部署、运行、调度资源，利用容器的轻量级特性，在服务数量激增的情况下节省更多应用部署和运行资源，可以轻松应对波动的业务流量。同时，应用的镜像交付形式实现了“一次构建，多次部署”，避免传统部署过程带来的操作复杂度与操作风险。通过该平台，应用交付周期缩短了 80%，业务需求响应速度提高 50%。

然而，在金融机构开始大量采购采纳云原生技术时，却存在云原生技术产品体系过于庞杂、开源生态缺乏治理、产品之间兼容适配困难等诸多问题。局部技术特性往往给金融机构选择造成很大干扰，并产生较高的试错成本。

“抛开整体来看局部细节都是耍流氓”。

越是平台型技术，越需要从整体角度来考量。所以，迫切需要一套结合行业特性的统一标准，为金融机构提供一个能力参照模型，以便金融机构定位自身云原生技术转型的发展阶段，对比分析发现云原生能力建设的不足，制定未来技术和能力建设方向。我们结合一些金融行业实践，为金融机构采纳云原生技术提供一套完整的技术能力框架，和九大维度的成熟度评估模型，可以参考如下指标进行展开：

微服务架构程度、应用云化程度、可观测性、高可用管理、配置自动化、DevOps、云平台能力、云原生安全、容器及K8s能力。

金融级云原生演进路径 

好的架构是进化来的，我们既需要一套完整的架构规划，来确保完整性和建设规范，但也需要架构能够持续演进，确保整体稳妥可控，所以我们归纳总结了两种云原生架构演进路径作为参考。

参考路径一：全局宏观尺度来看（从上向下），根据云原生能力评估来寻找技术短板和演进路径。 如下示例是一个云原生架构三阶段演进路径，帮助金融机构逐步实现应用架构从单体微服务改造，走向单元化，实现同城双活再到异地多活的变迁。寻求最平衡的架构发展路径以满足业务发展和严苛场景考验。

参考路径二：从问题出发（从下向上），架构演进的目的一定是解决某一类问题。 不妨从“问题”的角度出发，来设计整体云原生架构演进。如下示例使一个以解决技术问题来不断进行云原生架构演进的实践。

步骤1：为了让整个应用架构有“更好的底层支撑”，将应用架构运行在云平台上

步骤2：为了解决单体架构“复杂度问题”，使用微服务架构

步骤3：为了解决微服务间“通讯异常问题”，使用治理框架 + 监控 

步骤4：为了解决微服务架构下大量应用“部署问题”，使用容器

步骤5：为了解决容器的“编排和调度问题”，使用 Kubernetes

步骤6：为了解决微服务框架的“侵入性问题”，使用 Service Mesh

06 结语

本文将广义云原生的技术理念和金融级的技术标准进行了映射和结合，定义了金融级云原生的蓝图和十大要素，旨在让云原生的先进技术理念能够扩展到企业机构全方位技术栈，给金融行业的面向信息技术应用创新的架构规划提出了全新的参考架构，让我们一起坚持探索和实践，为金融级的架构创新提速。

作者简介：

刘伟光，阿里云智能新金融&互联网行业总裁、中国金融四十人论坛常务理事，毕业于清华大学电子工程系。 加入阿里云之前，在蚂蚁金服负责金融科技的商业推广和生态建设工作以及蚂蚁区块链的商业拓展工作；在企业软件市场深耕多年，曾经创建Pivotal软件大中华区分公司，开创了企业级大数据以及企业级云计算PaaS平台的市场先河。在创建Pivotal中国软件公司之前，刘伟光曾经担任EMC大中国区数据计算事业部总经理，并在甲骨文中国公司工作多年，曾经创建了Exadata大中国区的产品事业部并担任事业部总监。