数字金融时代的云原生架构转型的关键挑战和应对思路

小蚂蚁说：

近年来各项层出不穷的新技术推动着广大金融机构数字化业务能力的不断提升。用户可以通过互联网、移动端，甚至物联网设备等渠道获取金融产品和服务，全新的用户体验也为渠道触达和业务营销活动提供了非常大的想象空间，同时亦给金融 IT 系统的架构变革带来新的驱动力 – 地理位置、时间作息、淡季旺季等因素不再是决定获客营销的关键因素，计划中的大促活动和计划外的热点事件，时刻都会为 IT 系统的业务响应处理能力带来巨大挑战 。

我们希望本文能作为分享的开端，在未来我们将就金融级云原生架构转型的相关实践经验，持续和大家进行积极开发的交流分享。

在产品需求日渐丰富、迭代速度不断加快的背景下，金融机构数字化转型需要有成熟的 IT 架构、敏捷交付流程和技术风险保障机制支撑，缩短新业务产品的研发与投产时间，快速响应细分客户需求，还要保证在更新和维护应用及软硬件系统时不对用户体验产生负面影响，即使在极端严苛的业务压力下也须始终保持顺畅的产品服务体验，保证业务连续性和数据安全。

近几年来，“云原生架构”的相关话题讨论比较热烈，我们也相信这也将是金融 IT 架构的关键发展趋势之一。IT 架构转型绝不是一蹴而就的，积极探索和应用以“云原生”为代表的新兴技术的同时，还需考虑与传统模式和技术融合并存，沿着一条稳妥的可落地路径进行创新变革，确保架构转型的价值交付能够稳妥支撑甚至积极引领业务创新。

在蚂蚁金服内部架构变迁和对外金融科技开放的过程中，我们一直在持续探索，并在不断巩固总结出一套金融级云原生的架构落地路径，顺应广大金融机构分布式改造和 IT 架构稳妥创新升级的需求。我们希望本文能作为分享的开端，在未来我们将就相关实践经验，持续和大家进行积极开放的交流分享。

云原生架构的缘起和发展

许多行业的领导者和新兴创业机构，其技术架构都有普遍的共同点：以移动为核心增强用户体验、快速敏捷创新、服务持续可用、基础架构可扩展。这也是以金融为代表的传统机构 IT 数字化转型的目标，恰好也是当前非常火热的“云原生（Cloud Native）”架构所希望带来的真正价值。

云原生（Cloud Native）这个概念名词最初于 2013 年在技术社区中诞生，代表着一套先进架构理念的思想集合，包括了微服务、敏捷、DevOps、持续集成部署、容器、可靠、高弹性、易扩展等领先的概念和特性，之后整个业界也在不断发展，社区中涌现了许多非常优秀的项目，Linux 基金会旗下的 CNCF（云原生计算基金会）应运而生。

CNCF 对云原生定义了三个基础要素，即：

1. 微服务化，为架构敏捷性和运维精益性奠定基础。

2. 容器化，以确保资源可重用、透明及隔离性。

3. 动态编排，以确保资源调度的效率，通过精益化运维极大降低成本和提升效能。

由此可见，云原生是加快产品发布速度、增强服务稳定性、提高计算资源利用率、降低运维成本的关键架构之道。

云原生的企业架构演进之路

为充分理解云原生这个概念，并思考传统企业架构迈向云原生的转型升级路径，我们先简单回顾一下云计算的行业发展和企业架构演进的一般情况。纵观全局，我们把传统企业架构迈向云计算架构的演进之路，可以粗粒度地抽象成三个阶段：

1. 云机房（Cloud-Based），指的是把机房迁移到云（包括公有云或专有云）的第一步，基于虚拟化技术使资源利用率和运维效率有所提高，但依旧需要重点关注中间件和底层平台，每一部分都要考虑高可用、扩展、交付部署等因素。

2. 云就绪（Cloud-Ready），基本完成去中心的服务化改造，应用无状态化并与缓存、数据库等持久化层分而治之，应用服务规模扩大，需要有较成熟的 DevOps 和自动化工具平台来统一管控。

3. 云原生（Cloud-Native），通过微服务化架构、容器和编排技术、DevOps 等技术实践，加快应用的交付和部署；通过对平台能力的抽象和标准化，辅以微服务治理、敏捷的资源编排和管控技术，使开发者的关注重心上移，更关注业务逻辑本身，做到“代码定义一切”(Code Defined Infrastructure/Everything)。

云原生的本质：平台能力抽象 & 标准化

在这三个发展阶段演进过程中，体现出了两层关键趋势：

1. 从应用上云历程上看，架构关注重心逐渐上移： 随着研发运维理念升级发展、相关工具平台的规范成熟，底层和中层基础平台设施的能力逐渐抽象，并同上层业务应用解耦，使得软件团队更加专注于业务逻辑的研发成为可能。

回顾蚂蚁金服的架构演进，从某种程度上也代表了许多发展成熟的互联网公司的多年架构升级过程，最早亦是从单体巨石应用架构发展而来，逐渐开始应用 SOA 服务化的架构思想，开展应用和数据的分拆，发展出较细粒度的微服务架构，并沉淀出能支撑上层业务灵活发展的坚实业务中台和技术中台。

通过成套的应用开发框架、研发流程和中间件、运维平台，基础平台技术和业务研发有了较清晰的边界和协同机制。业务开发团队因可不必太过关心业务系统的容灾、扩展等非功能特性，得以更加聚焦专注于业务逻辑的研发实现。

**2. 随着容器和编排技术的成熟和统一，PaaS 层的技术方向也趋于稳定：**企业应用迁移上云的历程，亦是代表着业界对云计算认知的过程和云计算技术本身成熟度的升级过程，逐渐从对 IaaS 层的依赖，发展向对 PaaS 层的依赖。

回顾行业发展史，早在大约 2006 年 AWS 开创了云计算商业化的先河，推出了云端弹性虚拟机、存储等产品，直接定位于从 IaaS 层面解决传统应用云上迁移的需求，直到现在，公有云市场绝大多数的收入还都是来自于 IaaS 产品服务。但是反观微软云和谷歌云的早期市场进入策略，最开始的差异化竞争点都在 PaaS 层：以 Google App Engine 作为一个 PaaS 平台为例，开发者在一整套平台框架内研发、部署和管控应用程序，底层资源全部由云服务来进行托管，省去了许多底层系统管理操作。现在来看这些理念是非常先进的，但在那个年代对于大多数还在理解什么是云计算的企业客户来说，过多的代码框架侵入性和研发运维架构模式的转变，为整体架构迁移至 PaaS 带来了非常高的壁垒，最后就如同大家所看到的一样，以虚拟机产品为代表的 IaaS 层仍将是迁移至云的第一站。

但不管是云计算服务商还是机构用户，都希望最大程度上发挥出云上能力，有非常多的商业公司和开源社区不断在 PaaS 领域上深耕，PaaS 也逐渐出现了细分，例如以应用发布运维为核心的 Application PaaS (aPaaS)，托管数据库服务 Database PaaS(dbPaaS）等等，可谓百家争鸣，这些平台服务确实解决了许多现实应用问题，降低对底层基础设施的依赖，但业界也产生了困惑 - PaaS 产品本身很可能对应用开发和运维产生侵入性，这对厂商来说是粘性，对用户来说可能就是厂商绑定了。直到后来 Kubernetes 等容器编排技术的成熟，获得了大部分社区和用户的认可，行业才相对往一个较为统一的方向发展，与此同时“云原生”的先进理念也开始蓬勃发展，逐渐被开发者和架构师们所接受。

云原生可能是“银弹”，但架构转型绝非一蹴而就

“银弹”一词出处来自欧美民间传说，指的是只有“银质的子弹”才能使狼人这样的怪物一枪毙命。在软件工程界，“没有银弹（No Silver Bullet）”的说法来自弗雷德里克·布鲁克斯在 1986 年所发表的一篇经典论文，该论述中强调“真正的银弹并不存在”，隐喻没有任何一项技术或方法可以能让软件工程的生产力在十年内提高十倍。

从技术圈的社区讨论火热程度来看，云原生、微服务、DevOps、敏捷、容器化等技术和理念似乎就是未来 IT 基础设施建设的方向。业界普遍认为，云原生架构能加快需求交付、降低运营成本、支持容量伸缩、保证业务连续，从而使组织能更从容地接入创新技术、促进渠道触达。同时从最基础的定义上来看，面向云原生的架构转型貌似就像把大象放进冰箱一样简单：1. 微服务化 - 把大象拆分成许多小象；2. 容器化 - 打开冰箱门，把小象塞进冰箱；3. 动态编排 - 最优化这些冰箱的排列以保证空间资源利用率。

且不说在信息技术高速发展的今天，“没有银弹”是否依旧能够成立，在企业级特别是银行等金融机构架构转型方面，云原生是一个很好的方向，只是在应用这套新技术时，仍旧需要充分考量各项因素，以及使用一整套经过验证有效的落地路径与方法来进行有力支撑。

事实上，金融系统的架构转型不太可能一蹴而就，新兴技术同传统架构的融合并存在许多方面带来了更大挑战。以银行为例，从 80、90 年代开始建设电子银行、网上银行到移动智慧银行，新的业务需求层出不穷，面临着很多架构转型和变革的机会。银行的 IT 化程度很高，也看重云原生和分布式架构对于业务和整体 IT 交付的价值，但是系统越是成熟，历史包袱就越重，有着大量非常关键的遗留系统，实施架构转型时则无疑将面临许多关键的重大挑战。

金融级云原生架构转型路径

伴随着蚂蚁金服在数字金融领域的探索，在十多年的发展过程中，技术团队积累了大量的架构设计原则、最佳实践和产品服务案例，而这背后的出发点和技术思考，同云原生架构的理念是高度一致的，我们致力于构筑一个完整的金融级云原生架构，通过成熟的中间件和架构运维平台，使上层的应用能专注业务逻辑并具备敏捷交付的能力，又使其天然拥有金融级的高可用、一致性特性和互联网的海量并发、弹性伸缩等云原生基础架构能力。

下面我们希望通过一些关于蚂蚁架构发展的实践案例和经验，和大家分享我们总结出的金融级云原生架构转型路径上的关键挑战，以及在面临这些挑战时的一些应对思路和策略，与行业共同推动架构转型升级与数字金融创新。

挑战 1：金融 IT 架构如何进行稳妥转型？

“架构”一词原本来自建筑学，其背后有着关于建筑的隐喻，从蓝图到地基再到封顶，在绝大多数建筑物拔地而起的发展过程中会尽量较少引入新的变量，因为对于建筑而言改变整体结构或根基的成本非常高，软件业从建筑业借用了“架构”这个概念时，我们把那些一旦改变就会伤筋动骨的系列组件构成方式或者设计决策集称之“架构（Architecture）"。传统 IT 架构和早期的软件研发，喜欢运用“瀑布式研发”模型，而这个概念现在可能只在软件历史教科书中提到，自上而下进行充分论证和设计，最终按照设计蓝图的定义进行构建，一旦设计成型之后很难改变，如果产生设计变更，则往往牵一发而动全身，一轮变更下来研发团队常常要脱一层皮，导致研发过程效率低下。

随着敏捷软件开发方法和互联网商业的崛起，21 世纪的软件工程更偏向于使用生物进化的隐喻，就像从猿猴逐渐进化成现代人的过程中，能够不断根据外界环境和自身发展的需求，持续进行适应性和最优化的调整演进。回顾蚂蚁十多年的发展过程中，飞速发展的业务场景和使用量级，一直在推动团队组织和技术架构进行持续的升级演化。蚂蚁从最早的单体应用，到 SOA 服务化改造、分布式架构主机下移、单元化改造，再到从容承载互联网金融业务的异地多活架构，整个循序渐进的演进过程都是暗合生物进化的架构隐喻。

好的软件架构是进化来的，而不是由一开始就能够进行完整的巨细靡遗的设计和按图制造。当前蚂蚁的 IT 架构已经有了诸如“金融级、异地多活、弹性伸缩、事务一致性”等标签，但在早期阶段，我们只是对这些架构目标做了设定，但并未在开始就完全设计好所有细节。回顾架构的历史变迁，金融 IT 架构转型创新的前提是保证用户体验和现有业务连续，确保整体稳妥可控，对此我们分享三个原则观点：

1. 增量化交付(Incremental)

架构落地不追求一步到位，由简单入手，渐进式攻克，每一步都为未来奠定基础。

支付宝的架构每年都需要迎接天猫双十一大促的峰值和容量挑战。从 2012 年开始，整体架构开始面临瓶颈，预计很难通过传统的扩容手段支撑来年业务量增长。（事实上，2013 年的峰值交易量达到了前一年的近四倍，已经达到每秒 15300 笔）。当时我们已经对单元化架构和 LDC（Logical Data Center, 逻辑数据中心）的整个愿景提出了设想，只是当时并没有想到其最终能发展到何种成就。

关于单元化架构，最初是支付宝用来解决业务和数据拆分后数据库连接数过多的问题，通过更多的场景沉淀，单元化架构今天已经成为蚂蚁金服异地多活和容灾架构的基础。单元化架构的本质是将系统进行水平拆分后的逻辑隔离，每一个单元都具备更小的规模，但拥有完整的业务功能，从接入网关到应用服务器再到数据库，每个单元依据规则支撑一定的流量和数据。通常来说，一般云计算应用的“分片”（Sharding） 通常是在数据层维度的，以支撑上层无状态（Stateless）应用的横向扩展。而单元化架构的核心设计思想，是把这种分片能力提升到机房入口流量的位置，使整体的业务处理能力能够通过一个个逻辑单元在数据中心的层级进行横向伸缩。

增量化交付：异地多活架构的演进历程

完成一个交易，背后有非常多的业务逻辑，调用非常多的业务系统。为验证单元化架构的思路的可行性，我们最初围绕着交易创建系统进行相关改造。通过前置系统从流量中截取用户的支付宝账户 ID 并取模，以识别该用户的数据属于哪一块逻辑单元分片，随后进行路由转发并执行处理逻辑，实现在网关层的服务路由、数据层的数据分布都能够通过账户 ID 来进行分片并形成封闭单元。

在 2012 年底完成交易系统的原型验证之后，才开始了全面的单元化改造。我们需要把这些业务系统集中在一个逻辑单元上，使流量一旦进入这个逻辑单元就能完成整个交易的全过程，尽量减少同其他单元进行通讯的机会，因此背后需要有一系列业务系统的改造，使完整链路的架构分片逻辑能与交易系统对齐。

那一年我们解决了大促高峰时数据库连接池的瓶颈，在夯实这个基础之后，我们把红利再扩展到核心的支付链路，一步一步再到账务链路，一直到整个体系完成覆盖，完成了单一机房内的逻辑单元化改造。在 2014 年的时候，遇到了单机房的容量瓶颈，于是把逻辑单元部署到了同城的第二个机房，完成“同城双活”的架构。这也为“异地多活”奠定了基础，并在之后通过容器和资源调度技术的成熟，使得逻辑单元能更灵活地“弹入”云计算机房和大数据离线机房，使得单元化不仅解决了机房级横向扩展的问题，更是在跨地域跨机房的容灾和资源利用率方面取得了很多红利。

2. 稳健型创新(Sustainable)

行走江湖安全第一，技术风险兜底增强适应能力。

金融的本质是风险识别和管理，而对于金融 IT 架构来说技术风险亦是重中之重。任何一笔交易处理的差错背后都有可能导致不可预计的资金损失。蚂蚁金服有一支专业的技术风险团队（SRE，Site Risk Engineering），确保从系统架构平台到风险文化机制，在架构设计、产品开发、变更上线、稳定性评估到故障定位恢复等等环节，都能全生命周期地确保风险质量控制，对任何系统变更作兜底保障。许多关于技术风险的实践经验，都已经沉淀到蚂蚁的架构逻辑和平台产品之中。以下我们举一个关于会员系统数据库迁移至 OceanBase 的案例，分享其技术风险保障方案和兜底逻辑。

2015 年的双十一大促，OceanBase 数据库已经支撑了 100%的交易流量，并开始支撑支付宝的会员系统等其他核心业务，全天运行稳定，零数据差错，在那一刻开始标志着 OB 已经成为了一个金融级数据库。这届大促的准备工作的目标之一就是会员系统背后的原商业数据库迁移至 OB，同时又要验证系统在新数据库下的可靠性和稳定性，不能影响整体业务连续性。确保项目万无一失，绝非只是进行简单的复制同步和数据源切换，这背后项目组对稳妥方案不断进行探求和验证，解决了具有挑战的核心技术问题，在多个架构层次上都达成了平衡和优雅的设计。“开着飞机换引擎”的过程，历时将近一年。

稳健型创新：会员系统迁移 OB

数据库层面的迁移过程可以抽象成四个步骤，包含了许多兜底逻辑：

第一步，写老读老，在原有架构下，通过同步机制，确保 OB 端的数据同原数据库对齐，但业务应用的数据读写依旧在商业数据库中；

第二步，写老读新，我们通过数据中间件，将一部分对一致性要求不高的访问流量，通过白名单切流的方式迁移至 OB，此时 OB 的数据来源仍旧来自商业数据库的同步；

第三步，写新读新，同步机制断开。这个步骤比较复杂，包含了大量的数据对比、禁写切换和性能验证操作。首先通过数据库层以及中间件层的禁写操作，关闭商业数据库的读写流量。其次，等待增量数据同步组件同步日志，边同步边开启增量比对。之后，增量数据同步完成后，开启数据全量比对。数据全量比对完成后，数据库层以及中间件层打开对 Oceanbase 的读写流量，完成"换主"操作。在整个切换过程中，针对每个阶段都准备了相应的回滚操作，并在线下多次练习，最终确保 10 亿＋数据分钟级的切换。

第四步，双写同步数据，保留原数据库作兜底，通过数据中间件双写来同步数据，一边做验证，一边确保整个体系有随时回滚能力，项目历时几个月，最终确保 OB 成功切换，完成大促挑战。

3. 演进式规划(Evolutionary)

在架构演化选择时，对关键架构决策进行原型验证，确定最佳演化方向。

谈到互联网时代的技术和产品迭代，我们常常看到一个观点，鼓励“快速试错”。精益创新和敏捷迭代固然重要，然而在严苛金融场景下进行关键架构决策时，“试错”的代价往往会变的难以承受。从我们的实践经历来看，演进式规划的本质是，迈向一个架构愿景目标时一定要对关键架构决策进行原型验证，为此还要最大程度上在实际环境中保证可行性。回顾 2015 年从同城双活迈向异地多活时，整个体系改造包括了机房搬迁、选址，几乎所有系统的相关改造，为保证能万无一失，所以我们做了非常多的验证。

演进式规划：异地部署前的充分原型验证

异地部署的一大难以逾越的挑战是地理位置所带来的延时。光纤可以做粗，但光速无法变快。我们首先在中间件层面实现了故障注入的能力，而延时就是可能的故障之一。我们在当时同城双活的架构中，在未来可能产生异地延时的节点加入埋点，模拟一旦流量走向异地机房时可能发生的延时。基于这个方案思路，我们做了非常多的演练，逐渐从某个单点应用扩展到数据层、路由层等方面。为了能更准确地评估模拟延时注入后的影响效果，我们还加入了链路追踪 Tracer 的能力，使一个交易请求从发起，经过各微服务和中间件再到数据库访问的整个过程，都能够被穿透式地监控记录到。以一个涉及到跨城调用的交易为例，整个过程涉及到的远程调用、异步消息等都有可能触发延时逻辑。通过对完整链路的跟踪串联，我们对异地部署延时对链路的影响作了充分可行性验证，最后流量切换上线、直到异地多活的改造完成，全程作到用户无感知，保证了用户体验和数据安全。

通过尽可能真实的状况模拟和故障注入，再到后来逐渐成熟的全链路压测，都是架构演化选择时的最佳实践，在演化的过程中，必须要对关键架构决策进行充分的原型验证，如同生物进化，做多种可能的尝试，以确定最佳演化方向。

小结：金融级云原生架构升级参考路径

我们把以上提到的三个观点，总结为一组金融架构进行稳妥转型的三大原则。大道至简却知易行难，在架构的演进过程中，这些原则已然深深的写进了蚂蚁的代码里。正是基于这些原则，蚂蚁应用架构完成了从单体改造，走向单元化，实现同城双活再到异地多活的变迁。在此过程中，我们关注技术风险，形成中台架构，不断把技术中台和业务中台沉淀下来。我们相信这些原则有一定的通用性，尤其是适合作为金融 IT 架构变迁的参考路径。

金融级云原生架构升级参考路径

对于绝大多数以银行为代表的金融机构，到了一定体量并对业务发展有积极预见之时，我们建议 IT 架构规划和升级，需要基于业务价值作增量化交付、稳健型创新、演进式规划，构建中台能力敏捷响应市场需求，同时夯实完整的技术风险平台和体系以保证在容量、变更、故障自愈、资损防控领域等方面的建设，使新老技术和价值理念混合并存、架构升级的过程中，依旧可以保证稳妥发展与创新。

挑战 2：严苛金融场景下如何确保架构平衡？

蚂蚁金服这十多年来，业务场景和规模持续同技术产品一起飞速发展，对技术能力的要求不断提高，从量变发展到架构质变；有了坚实的技术架构底盘支撑，业务亦能有更为广阔的想象空间，通过科技创新能力搭建一个开放、共享的信用体系和金融服务平台。

我们倡导“架构平衡”，意味技术目标与组织需求能够相互适应，共同发展。关于“严苛金融场景下如何确保架构平衡”的问题挑战，我们通过介绍微服务架构产品在蚂蚁的发展历程，讲述我们在不同阶段的架构平衡考量和原则，希望能对金融机构进行架构选型和路径决策时提供参考。

阶段一：快速搭建单体应用：满足交付效率

在最早期还只是淘宝收银台的早期时代，支付宝还是一家纯粹的创业公司，当时最重要的就是交付效率，当时尝试使用眼前能获得的最快最成熟的方案，比如许多金融机构 IT 耳熟能详的商业软硬件、互联网上能找到的开源技术。当时不用考虑太多扩展性和容灾能力，而正是这些非常经典的技术和架构，支撑了支付宝业务模式的早期探索。

阶段二：模块化+SOA：组织和业务规模飞速增长

第二个阶段，我们发现组织和业务规模上涨的非常快，同时对交付的要求又非常高，因此业务架构和应用设计急需一种抽象和模块化的能力，解决多方协作开发部署的需求。此时整体研发框架开始了面向服务化的改造，应用开始拆分以确保能够分而治之，极大了改善先前 100 多人同时开发整个业务模块的情况，通过抽象和隔离，减少并行研发过程中互相之间的影响，又极大加快了编译、测试、发布的效率。在这个背景下，分布式中间件 SOFA 应运而生，当时 SOFA 在内部的全称叫做 Service Oriented Fabric Architecture，意为能够将 SOA 架构通过服务化地方式重新组织，让研发运维人员像坐“沙发”一样舒适工作。

阶段三：微服务的「静态拆分」与「动态组合」：优化成本以应对容量问题

在第三阶段，业务规模和成本优化的这两个大的互相撕扯的力量是最需要破局的技术挑战。团队和开发人员的规模、业务的规模和峰值容量都上涨的非常快。关于微服务的拆分和治理，当时我们内部激烈讨论过一个问题，到底拆 100 个服务、1000 个服务还是 2000 个服务是正确的，而我们当时就在不断摸索这个平衡点。

俗话说分久必合，合久必分。微服务架构的优势不言而喻，但有时逆向思维也会非常精彩。我们考虑了另外一条路径，即有没有可能把各应用以微服务的方式分别开发测试的前提下，把一些系统上合并起来进行部署。回顾支付宝系统中的关键交易链路，交易创建、收银台展现、交易支付三个阶段的调用量是高度耦合的，这些业务逻辑背后所关联的许多微服务应用是否能有更优化的部署模型。于是我们对研发框架和运行时组件作了非常多的研究和改造，确保保持项目代码分开的情况下，能够进行“合并部署”。

合并部署的核心思路是实现类隔离，同时服务注册发现、路由逻辑以调用本地实例为优先。合并部署的技术应用经历过大量 POC 原型验证，最后成功地把一些指定的服务部署成为一套合并的系统，同时保持其他仍旧以微服务形式，最终为当年大促省下了非常多的机器，极大提高了资源利用率。随着架构的演进，后期我们将这套思路用更为优雅的编排调度和容器来实现，升级为合并部署 2.0，这个是后话了。

阶段四：单元化与异地多活：跨机房和地域的容灾和扩展能力保障业务急速发展

单机房的容量无法无限伸缩，更是无法保证容灾能力能满足业务连续性的需要。在此阶段，我们会在风险质量以及业务规模、成本方面去平衡，通过单元化改造使整体架构具备异地多活能力。为此，我们实现了跨机房的服务注册发现能力、提供了跨机房的服务调用路由逻辑，从入口流量到微服务、中间件和底层数据库，全链路地消除了单点，使整体服务都具备了分片和横向扩展能力，同时保证了资源利用率，破除了传统主备架构所带来的成本负担。

阶段五：服务化基础设施下沉：Service Mesh 平滑支撑海量异构的金融科技应用

随着蚂蚁业务发展和各线金融科技的不断探索，不止团队规模在飞速扩充，以支撑区块链、人工智能、风控核身、物联网、金融计算等各方面发展的需要。在这样的现状前提下，内部技术栈逐渐开始多样化，从相对统一的 Java 逐渐加入了非常多的基于 Node.js、C++、Python 等异构语言的微服务应用。但这些应用本身不应是割裂的，我们依旧希望依旧能够贯通到一个统一的体系进行管理，尽量以轻量级、低成本的方式向这些系统提供近乎一致的微服务管控和互相发现通讯能力，而不是向每一种技术栈都提供一个客户端 SDK 并将关键能力重新实现一遍。

同业界的观点一致，我们亦认为 Service Mesh 是微服务未来发展的重要趋势。其本身的实现原理和优势，社区已经有了非常多的讨论，而对蚂蚁来说，首先看重的就是其对异构微服务应用、遗留应用互相之间发现、通讯和治理提供了非常优雅的解法。通过 Service Mesh 的方案，我们可以尽量把最多的功能从中间件的客户端中移到一个并行部署的轻量代理中，并对服务应用透明，目标是做到一次实现，就搞定所有语言，这个对于基础设施团队来说，在成本和稳定性上都是一个提升。

小结：寻求最平衡的架构发展路径以满足业务发展和严苛场景考验，而不仅仅关注功能本身

微服务演进：应对业务发展诉求的架构平衡

金融 IT 系统的架构选型需要非常慎重，以银行核心系统为例，系统选型几乎就是一个公司战略级别的决策，关乎着长期影响。在当前历史时期，有非常多的银行机构开始考虑逐渐从单体架构向分布式架构进行融合与升级。围绕着业务价值作 IT 架构交付，绝不只是看哪种技术比较时髦或功能强大，这背后的选型元素涵盖了服务化架构、敏捷交付、API 平台开放、综合成本等话题，也包含着落地可行性和生态成熟度等方面，因此更需要关注这套技术产品的长期愿景和发展规划，比如有没有公有云的业务战略、有没有提供一整套从经典架构迁移至先进架构的转型路径方法实践，更看重在业内有没有真实参考案例和服务体系支撑。

在通过多个维度对架构和技术产品本身进行评估的同时，对组织发展现状的认知也非常重要。为此，我们为“技术选型决策”抽象出两部分能力，一部分代表不断发展的“现实状态”，包括了“团队能力”、“组织规模”和“业务规模”；另一部分代表“技术目标”，代表业务对我们的要求，包括了“交付效率”、“成本优化”和“质量风险”。我们认为架构选型的实质是为了使组织能力和技术能力达成一种平衡，通过权衡组织发展的现状和未来，来找寻最合适的技术发展可实现愿景和可落地路径。

挑战 3：如何应对核心金融系统的关键技术挑战？

成熟的新技术推动着数字化业务能力和客户体验个性化的提升。在购物、医疗、出行、社交等不同的复杂场景，最终用户通过互联网、移动端，甚至物联网设备等渠道获取金融服务的机会已经越来越频繁。在这样的场景化数字金融时代，用户选择多样，市场竞争也在不断加剧，在众多同类金融服务竞争中脱颖而出的必要条件是能够提供一体化全方位数字化的服务，即用户希望无论何时何地，通过触手可及的设备或者平台，都能一站式地满足其金融生活和业务的需求。场景极大丰富，亦为金融业务营销活动提供了非常大的想象空间–地理位置、时间作息、淡季旺季等因素不再是决定获客营销的关键因素，计划中的大促活动和计划外的热点事件，都有可能为金融机构的信息系统产生巨大挑战。

以一个常见的日常交易场景是当面付为例。当用户拿出手机，打开二维码进行付款操作，后台会进行一系列技术处理。这中间最主要的环节是风险识别；风险识别以后，是相应的营销决策，判断用户在该笔交易中应该获得多少红包或者奖励；最终完成交易，发生账户扣款并产生结果。这样一个简单的场景背后蕴含着一系列以计算为核心的交易处理过程。而这个场景正在时时刻刻发生在现实生活中。在普惠金融和互联网业务蓬勃发展的大背景下，具备大规模高并发交易处理的能力已成为银行等金融机构业务系统的标配。

核心金融系统，在技术层面的挑战有别于其他大规模互联网系统。在数字化转型的过程中，我们建议金融机构的技术决策者，预先考虑可靠的基础设施和弹性应用数据架构，在不同业务压力下依旧保证业务连续性和数据安全。而且在金融级交易系统中，对事务型的状态数据一致性处理以及交易成本的要求更高，对客户资金风险和安全性处理更加复杂。在产品迭代速度不断加快的背景下，还要有成熟的架构、流程和风险保障机制，在更新和维护应用及软硬件系统时，不对用户负面影响，保证在任何极端严苛的业务压力下始终保持丝般顺畅的用户体验。

基于蚂蚁的实践经验，金融级 IT 系统在迈向云原生架构的过程中，有以下四大关键技术挑战需要积极应对：

• 无限可扩展能力：如何规模化分布式服务和数据能力，也就是服务和数据处理的可伸缩性

• 无损秒级容灾：如何做到秒级快速容灾能力，做到四个 9 及以上的系统可靠性

• 高性能分布式事务：当服务和数据分布后，如何保证事务中数据的强一致性，这是金融级分布式系统最大挑战之一

• 弹性供给与调度：怎么做低成本，按需提供资源配置与调度，如何做到交易成本的降低

无限可扩展能力

我们在前文架构变迁历程中提到了单元化，这是整体架构能够进行无限可扩展的关键前提。单元具备四个重要特性：

一、自包含性，比如账户充值交易所涉及的所有计算和数据都会被封闭在一个单元；

二、松耦合性，单元之间只允许进行服务调用，不允许直接访问数据库或其他存储，对于必须跨单元的操作，比如位于两个不同单元之间的用户转账交易，服务调用需尽可能少，同时在不影响客户体验的情况下，尽可能异步化。这样，即便两个单元相距较远，整个系统的响应也不会受单元间访问延迟的影响；

三、故障独立性，一个单元的故障不会影响其他单元；

四、容灾性，单元之间相互备份，每个单元都保证在发生同城或异地故障时有可接管的单元，单元之间的备份方式是使用自研数据库提供的多地多中心的一致性方案。

无限可扩展：异地多活与单元化架构

通过单元化架构，全局系统的伸缩问题变成了逻辑单元的增减问题，而在此过程中，整个单元的规模和内部复杂性是相对稳定的，这就降低了系统整体伸缩的复杂度；其次，单元的故障独立性使得我们能够控制软硬件故障的影响面；最后，单元之间可快速切换，这就使得我们处理同城和异地容灾时可以更加简单高效。

无损秒级容灾

单元化解决了业务和服务层面的扩展性和容灾问题，但数据层面的容灾问题并没有得到解决。如果发生城市级故障，我们仍然不敢把核心业务流量切换到另一城市，那我们实际上仍然停留在原地。但这个问题不管是商业数据库还是开源数据库都是无解的，我们可以通过各种技术手段尽可能降低故障切换时间，减少故障影响的客户范围，但无法避免资损的发生。这个问题，在我们有了自己的数据库 OceanBase 之后，被彻底解决了。

OceanBase 的核心是基于 Paxos 协议的多数派分布式选举协议，Paxos 协议的价值已被业内广泛认可。该协议保证只要多数成员依然存活，任何少数成员的故障不会影响系统的整体可用性和数据一致性。所以，如果把一个数据集群部署到三个或三个以上城市时，我们就可以保证任何一个城市的故障，系统都可以实现无损容灾，也就是 RPO=0。同时，系统可在 30 秒以内把故障切换到另一城市，故障切换过程在数据库层面自动完成，对上层业务没有影响。另一方面，当我们把一个数据库集群部署到三个城市时，为了避免任何单机故障导致的业务跨城市访问问题，我们把数据库集群中的副本数量从 3 个增加到 5 个，这就是我们今天所说的三地五中心，或者严格一点，三地五副本多中心。

无损秒级容灾：金融级关系型数据库 OceanBase，三地五中心高可用部署

从两地三中心到三地五中心，我们解决了一个基础又非常重要的问题，即便发生城市级故障，整个城市都不可用，数据库层面仍然可以做到，系统不丢数据，不停服务。

蚂蚁金服花了数年时间来演进基于单元化和三地五中心的异地多活和容灾架构，至今已在多个城市部署了多个数据中心，所有的核心交易流量部署在所有数据中心并可随时切换和调配，通过异地多活，我们实现了流量在全国范围内的任意扩展，极大地提高了资源利用率。最重要的是，我们提升了系统面对城市级故障的能力。蚂蚁金服在如此大规模的金融交易系统中实现了这样的容灾能力，这在世界上属于首创。

高性能分布式事务

众所周知，金融交易对于一致性要求非常高，传统银行集中式核心采用单一事务，要么全成功，要么全失败，非常好的满足了一致性要求。蚂蚁通过微服务架构，实施业务垂直拆分和数据水平拆分，这就意味着存在大量的微服务和大量的单元数据库，一个完整金融业务需要调用多个服务和数据库完成，因此，保证服务与数据处理达到金融级的一致性将是面临的首要难题。传统技术中的事务一致性方案对资源加锁的时间长、粒度大，在很大程度上制约了系统的可伸缩性与高可用性，无法满足架构向单元化、异地多活的发展需要。

为了解决这个难题，我们自主研发和演进 SOFA-DTX 分布式事务解决方案已经近 10 年，伴随着支付宝一起经历了复杂场景和高并发的挑战，充分考虑了各类异常情况，具备足够的伸缩性、高并发和高可用性，支持跨机房的事务协调能力，已经是一套非常成熟的金融级分布式事务框架和服务。该方案引入事务观察者协调分布式事务的各参与方，达到整体的事务一致性。实现了两阶段提交协议，第一阶段采用本地端事务，操作仅预留必要的资源，处理成本足够低，第二阶段可以异步执行，使得业务整体具备了较高的性能和较强的吞吐能力。

高性能分布式事务：跨服务一致性保证和异步可靠消息

我们还辅以可靠消息中间件来支持最终一致性的需要，形成了一套事务型消息框架。此类消息发送给消息服务器与数据库事务状态保持一致，当事务状态是提交时，消息才会被投递到订阅者，当事务状态是回滚时，消息不会被投递到订阅者。

分布式事务解决方案被蚂蚁金服、网商银行各业务系统（包含核心账务等）广泛使用，从上线至今一直稳定运行，没有出现任何因为分布式事务机制，导致数据不一致的生产问题。

弹性供给与调度

互联网化的业务会出现短期的业务高峰，蚂蚁金服通过单元化架构化解了业务峰值对系统的冲击，再通过弹性伸缩架构实现了资源的按需供给。弹性混合云通过统一资源调度平台实现了资源的快速申请和建站，在业务高峰时将流量和数据动态弹出到新的单元，快速提升系统容量，在业务回落时，将流量和数据弹回，快速释放云上资源，从而极大降低资源采购和运行成本。在整个过程中，中间件将应用与基础设施充分解耦，整个过程对应用系统不需要改变。再通过统一管控平台，将高层的弹性操作，翻译成各个组件的部署与配置指令，并且统一调度执行，使操作协调一致、精准高效。

弹性供给与统一资源调度：弹性混部架构

弹性操作，需要在流量、数据与资源之间协调一致地操作，尤其是有状态的数据的弹性操作是最困难的，需要不中断业务，也需要保证数据的一致性。这些操作如果依靠运维人员人工执行会十分复杂低效，需要架构、中间件与管控系统的支持，其在实践中有以下关键点：

• 通过统一资源调度，灵活地申请与分配计算、存储与网络资源，创建单元，快速部署数据库、中间件与应用；

• 通过中间件，将应用与基础设施充分解耦，无论流量、数据与资源如何分布，应用系统不需要改变；

• 通过分布式架构与数据规范，以及中间件支持，保证所有请求、服务、数据、消息等都有全局唯一的 ID 和一致的 ID 编码规则。根据 ID，从接入网关、服务中间件、消息中间件、数据中间件等都能够正确地路由服务请求与数据访问；

• 通过统一管控平台，将高层的弹性操作，翻译成各个组件的部署与配置指令，并且统一调度执行，使操作协调一致、精准高效。

• 通过单元化伸缩的机制和容器化技术对底层虚拟化平台的屏蔽，实现多个异构机房的资源充分利用，无论基于什么架构，无论在哪个城市，都可以快速建站部署单元，并在业务高峰期过后快速回收，完成数据的回迁。

金融级云原生架构的共创设想

我们认可并通过实际行动践行云原生架构，但云原生还需继续发展前行以满足金融级的需求。对于金融级云原生架构，我们倡议如下：

• 以「异地多活」为目标 — 使系统容量能在多个数据中心内任意扩展和调度，充分利用服务器资源，提供机房级容灾能力，保证业务连续性。

• 具备「分布式事务」和「无损容灾」能力— 保证在分布式架构下承受高并发交易，在系统扩展、容灾恢复、更新发布时确保数据无损，服务可用。

• 整体设计秉承「开放」原则 — 使新兴架构向下兼容，能与经典架构有机融合；开放技术标准，拥抱开源生态；提供开放 API，实现能力复用、方便二次开发。

金融级云原生架构的共创设想

从经典 IT 架构迈向金融级云原生架构的转型过程，我们建议应基于业务价值作增量式交付、稳健型创新、演进式规划，构建中台能力敏捷响应市场需求；在架构和技术选型过程中，应寻求最平衡的发展路径以满足业务发展和严苛场景考验，而不仅仅关注功能本身；基于云原生架构的核心金融系统，还应面对并解决机房级的扩展能力、地区级的容灾能力、高并发条件下的分布式事务并做到灵活资源调度以保证成本最优化。

蚂蚁金服将持续把多年的积累的经验和科技向行业分享和开放，提供架构转型的可落地路径和相关洞见经验，也希望能同广大技术社区和各行业的伙伴深入交流，共同探讨和共建金融级云原生架构标准和最佳实践，使业务应用能专注需求作敏捷交付，又能同时原生地拥有高可用、一致性和互联网海量并发、弹性伸缩等金融级基础架构能力。

我们把这套金融级云原生的分布式架构解决方案，称之为 SOFA（Scalable Open Financial Architecture），SOFA 源自蚂蚁内部分布式架构实践，是一整套完整的金融级中间件产品技术和演进式架构转型服务体系。

同时，SOFA 体系内的各个组件已经开始逐步向社区开源，链接：

https:// github. com/alipay

希望能与技术社区共同完善和改进各关键产品，支持大家更加敏捷稳妥地实现金融级云原生架构。

本文转载自公众号蚂蚁金服科技（ID：Ant-Techfin）。

原文链接：

https://mp.weixin.qq.com/s/5UUjDcmtXYBKf5XDLTS7Lg