2022年云原生架构数字化转型方案

1、吧吧云原生架构数字化转型方案数字金融时代的云原生架构转型的关键挑战和应对思路倍巴倍巴目录 TOC o 1-5 h z 背景3 HYPERLINK l bookmark4 o Current Document 云原生架构的缘起和发展4 HYPERLINK l bookmark6 o Current Document 云原生的企业架构演进之路5 HYPERLINK l bookmark8 o Current Document 云原生可能是银弹“，但架构转型绝非一蹴而就10 HYPERLINK l bookmark10 o Current Document 金融级云原生架构转型路径11 HYPERL

2、INK l bookmark20 o Current Document 金融级云原生架构的共创设想40在产品需求日渐丰富、迭代速度不断加快的背景下，金融机构数字化转型需要有成熟的 IT架构、敏捷交付流程和技术风险保障机制支撑，缩短新业务产品的研发与投产时间， 快速响应细分客户需求，还要保证在更新和维护应用及软硬件系统时不对用户体验产生 负面影响，即使在极端严苛的业务压力下也须始终保持顺畅的产品服务体验，保证业务 连续性和数据安全。近几年来,云原生架构的相关话题讨论比较热烈,我们也相信这也将是金融IT架 构的关键发展趋势之一。IT架构转型绝不是一蹴而就的，积极探索和应用以云原生 为代表的新兴技术

3、的同时，还需考虑与传统模式和技术融合并存，沿着一条稳妥的可落 地路径进行创新变革，确保架构转型的价值交付能够稳妥支撑甚至积极引领业务创新。在蚂蚁金服内部架构变迁和对外金融科技开放的过程中，我们一直在持续探索，并在不 断巩固总结出一套金融级云原生的架构落地路径，顺应广大金融机构分布式改造和IT 架构稳妥创新升级的需求。我们希望本文能作为分享的开端，在未来我们将就相关实践 经验，持续和大家进行积极开放的交流分享。云原生架构的缘起和发展许多行业的领导者和新兴创业机构，其技术架构都有普遍的共同点：以移动为核心増强 用户体验、快速敏捷创新、服务持续可用、基础架构可扩展。这也是以金融为代表的传 统机构IT

4、数字化转型的目标，恰好也是当前非常火热的云原生(Cloud Native) 架构所希望带来的真正价值。云原生(Cloud Native )这个概念名词最初于2013年在技术社区中诞生，代表着一套 先进架构理念的思想集合，包括了微服务、敏捷、DevOps.持续集成部署、容器、可 靠、高弹性、易扩展等领先的概念和特性，之后整个业界也在不断发展，社区中涌现了 许多非常优秀的项目，Linux基金会旗下的CNCF (云原生计算基金会)应运而生。CNCF对云原生定义了三个基础要素，即:微服务化，为架构敏捷性和运维精益性奠定基础。容器化,以确保资源可重用、透明及隔离性。动态编排，以确保资源调度的效率，通过精

5、益化运维极大降低成本和提升效能。由此可见，云原生是加快产品发布速度、增强服务稳定性、提高计算资源利用率、降低运维成本的关键架构之道。云原生的企业架构演进之路为充分理解云原生这个概念，并思考传统企业架构迈向云原生的转型升级路径，我们先简单回顾一下云计算的行业发展和企业架构演进的一般情况。纵观全局，我们把传统企 业架构迈向云计算架构的演进之路，可以粗粒度地抽象成三个阶段：1.云机房(CloudBased )，指的是把机房迁移到云(包括公有云或专有云)的第一步， 基于虚拟化技术使资源利用率和运维效率有所提高，但依旧需要重点关注中间件和底层平 台，每一部分都要考虑高可用、扩展、交付部署等因素。2.云就

6、绪(Cloud-Ready ),基本完成去中心的服务化改造，应用无状态化并与缓存、 数据库等持久化层分而治之，应用服务规模扩大，需要有较成熟的DevOps和自动化工具 平台来统一管控。3.云原生(CloudNative)，通过微服务化架构、容器和编排技术、DevOps等技术实 践，加快应用的交付和部署；通过对平台能力的抽象和标准化，辅以微服务治理、敏捷的 资源编排和管控技术，使开发者的关注重心上移，更关注业务逻辑本身，做到代码定义 切(Code Defined Infrastructure/Everything)。smA Cloud-Based化确林态化服务规橫化业务确中间件&平台眼务PaaS

7、云就细Cloud-Ready容器童控 动态期业务应用业务应用”云原生“ aoud* NativeiE*tW$t-SPaaS上移基础设施服务laaS严砒&平台眼务PaaS :严砒&平台眼务PaaS :中间件&平台眼务PaaS:平台靛力抽魚&标准化囂吧温金服科技云原生的本质：平台能力抽象&标准化在这三个发展阶段演进过程中,体现出了两层关键趋势：1.从应用上云历程上看，架构关注重心逐渐上移：随着研发运维理念升级发展、相关工 具平台的规范成熟,底层和中层基础平台设施的能力逐渐抽象,并同上层业务应用解耦， 使得软件团队更加专注于业务逻辑的研发成为可能。回顾蚂蚁金服的架构演进，从某种程度上也代表了许多发展

8、成熟的互联网公司的多年架 构升级过程，最早亦是从单体巨石应用架构发展而来，逐渐开始应用SOA服务化的架 构思想,开展应用和数据的分拆，发展出较细粒度的微服务架构，并沉淀岀能支撑上层 业务灵活发展的坚实业务中台和技术中台。通过成套的应用开发框架、研发流程和中间件、运维平台，基础平台技术和业务研发有 了较清晰的边界和协同机制。业务开发团队因可不必太过关心业务系统的容灾、扩展等 非功能特性，得以更加聚焦专注于业务逻辑的研发实现。2.随着容器和编排技术的成熟和统一，PaaS层的技术方向也趋于稳定：企业应用迁移上 云的历程,亦是代表着业界对云计算认知的过程和云计算技术本身成熟度的升级过程,逐 渐从对Ia

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

10、， 过多的代码框架侵入性和研发运维架构模式的转变，为整体架构迁移至PaaS带来了非 常高的壁垒，最后就如同大家所看到的一样，以虚拟机产品为代表的IaaS层仍将是迁 移至云的第一站。但不管是云计算服务商还是机构用户，都希望最大程度上发挥出云上能力，有非常多的 商业公司和开源社区不断在PaaS领域上深耕，PaaS也逐渐出现了细分，例如以应用 发布运维为核心的Application PaaS (aPaaS),托管数据库服务Database PaaS(dbPaaS )等等，可谓百家争鸣，这些平台服务确实解决了许多现实应用问题， 降低对底层基础设施的依赖，但业界也产生了困惑PaaS产品本身很可能对应用开

11、发 和运维产生侵入性，这对厂商来说是粘性，对用户来说可能就是厂商绑定了。直到后来 Kubernetes等容器编排技术的成熟，获得了大部分社区和用户的认可，行业才相对往 一个较为统一的方向发展，与此同时云原生的先进理念也开始蓬勃发展，逐渐被开 发者和架构师们所接受。云原生可能是银弹,但架构转型绝非一蹴而就银弹一词出处来自欧美民间传说，指的是只有银质的子弹才能使狼人这样的怪 物一枪毙命。在软件工程界,没有银弹(No Silver Bullet )的说法来自弗雷德里 克布鲁克斯在1986年所发表的一篇经典论文，该论述中强调真正的银弹并不存在， 隐喻没有任何一项技术或方法可以能让软件工程的生产力在十年

12、内提高十倍。从技术圈的社区讨论火热程度来看，云原生、微服务、DevOps.敏捷、容器化等技术 和理念似乎就是未来IT基础设施建设的方向。业界普遍认为，云原生架构能加快需求 交付、降低运营成本、支持容量伸缩、保证业务连续，从而使组织能更从容地接入创新 技术、促进渠道触达。同时从最基础的定义上来看，面向云原生的架构转型貌似就像把 大象放进冰箱一样简单：L微服务化-把大象拆分成许多小象；2.容器化打开冰 箱门，把小象塞进冰箱；3.动态编排最优化这些冰箱的排列以保证空间资源利用 率。且不说在信息技术高速发展的今天，没有银弹是否依旧能够成立，在企业级特别是 银行等金融机构架构转型方面，云原生是一个很好的

13、方向，只是在应用这套新技术时， 仍旧需要充分考量各项因素，以及使用一整套经过验证有效的落地路径与方法来进行有 力支撑。事实上，金融系统的架构转型不太可能一蹴而就，新兴技术同传统架构的融合并存在许 多方面带来了更大挑战。以银行为例，从80、90年代开始建设电子银行、网上银行到 移动智慧银行，新的业务需求层出不穷，面临着很多架构转型和变革的机会。银行的IT 化程度很高，也看重云原生和分布式架构对于业务和整体IT交付的价值，但是系统越 是成熟，历史包袱就越重，有着大量非常关键的遗留系统，实施架构转型时则无疑将面 临许多关键的重大挑战。金融级云原生架构转型路径伴随着蚂蚁金服在数字金融领域的探索，在十多

14、年的发展过程中，技术团队积累了大量 的架构设计原则、最佳实践和产品服务案例，而这背后的出发点和技术思考，同云原生 架构的理念是高度一致的，我们致力于构筑一个完整的金融级云原生架构，通过成熟的 中间件和架构运维平台，使上层的应用能专注业务逻辑并具备敏捷交付的能力，又使其 天然拥有金融级的高可用、一致性特性和互联网的海量并发、弹性伸缩等云原生基础架 构能力。下面我们希望通过一些关于蚂蚁架构发展的实践案例和经验，和大家分享我们总结出的 金融级云原生架构转型路径上的关键挑战，以及在面临这些挑战时的一些应对思路和策 略，与行业共同推动架构转型升级与数字金融创新。挑战1 ：金融IT架构如何进行稳妥转型？架

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

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

17、如金融级、异地多活、弹性伸缩、事务一致性 等标签，但在早期阶段，我们只是对这些架构目标做了设定，但并未在开始就完全设计 好所有细节。回顾架构的历史变迁，金融IT架构转型创新的前提是保证用户体验和现 有业务连续，确保整体稳妥可控，对此我们分享三个原则观点:增量化交付（Incremental）架构落地不追求一步到位,由简单入手，渐进式攻克,每一步都为未来奠定基础。支付宝的架构每年都需要迎接天猫双十一大促的峰值和容量挑战。从2012年开始，整 体架构开始面临瓶颈，预计很难通过传统的扩容手段支撑来年业务量增长。（事实上， 2013年的峰值交易量达到了前一年的近四倍，已经达到每秒15300笔）。当时我们

18、已 经对单元化架构和LDC （ Logical Data Center,逻辑数据中心）的整个愿景提出了设 想，只是当时并没有想到其最终能发展到何种成就。关于单元化架构，最初是支付宝用来解决业务和数据拆分后数据库连接数过多的问题， 通过更多的场景沉淀,单元化架构今天已经成为蚂蚁金服异地多活和容灾架构的基础。 单元化架构的本质是将系统进行水平拆分后的逻辑隔离，每一个单元都具备更小的规模， 但拥有完整的业务功能，从接入网关到应用服务器再到数据库，每个单元依据规则支撑 一定的流量和数据。通常来说，一般云计算应用的分片（Sharding）通常是在 数据层维度的，以支撑上层无状态（Stateless ）应

19、用的横向扩展。而单元化架构的核心设计思想，是把这种分片能力提升到机房入口流量的位置，使整体的业务处理能力能 够通过一个个逻辑单元在数据中心的层级进行横向伸缩。交剧创H入口按 UID 佩 POC架恂扩JR到支付岳 踊，完成同城双活 那下LDC昇地跑 CRG改 遣，完成昇地多活业务谢维 混蹿构201220132014201520162017解决连接池收益蓝绿发布欖 式、分神圾同城容 灾.全慢路压测同阙活 LDC单驱 LDC1洋性伸缩总部异地多活匸,LDCLDC毛蚂蚁金服科技力.成功挑战新的 支忖收益 精益化成本 牧总极离资潦利 控制.小时圾/站 用率增量化交付：异地多活架构的演进历程完成一个交易，

20、背后有非常多的业务逻辑，调用非常多的业务系统。为验证单元化架构 的思路的可行性，我们最初围绕着交易创建系统进行相关改造。通过前置系统从流量中 截取用户的支付宝账户ID并取模,以识别该用户的数据属于哪一块逻辑单元分片，随 后进行路由转发并执行处理逻辑，实现在网关层的服务路由、数据层的数据分布都能够 通过账户ID来进行分片并形成封闭单元。 在2012年底完成交易系统的原型验证之后,才开始了全面的单元化改造。我们需要把 这些业务系统集中在一个逻辑单元上，使流量一旦进入这个逻辑单元就能完成整个交易 的全过程，尽量减少同其他单元进行通讯的机会，因此背后需要有一系列业务系统的改 造，使完整链路的架构分片逻

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

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

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

24、0B数据库层面的迁移过程可以抽象成四个步骤，包含了许多兜底逻辑:第一步，写老读老，在原有架构下，通过同步机制，确保0B端的数据同原数据库对齐， 但业务应用的数据读写依旧在商业数据库中； 第二步，写老读新，我们通过数据中间件，将一部分对一致性要求不高的访问流量，通过白名单切流的方式迁移至0B ,此时0B的数据来源仍旧来自商业数据库的同步；第三步，写新读新，同步机制断开。这个步骤比较复杂，包含了大量的数据对比、禁写 切换和性能验证操作。首先通过数据库层以及中间件层的禁写操作，关闭商业数据库的 读写流量。其次，等待增量数据同步组件同步日志，边同步边开启增量比对。之后,增 量数据同步完成后,开启数据全

25、量比对。数据全量比对完成后，数据库层以及中间件层 打开对Oceanbase的读写流量,完成换主操作。在整个切换过程中，针对每个阶段 都准备了相应的回滚操作，并在线下多次练习，最终确保10亿+数据分钟级的切换。第四步，双写同步数据，保留原数据库作兜底，通过数据中间件双写来同步数据，一边 做验证，一边确保整个体系有随时回滚能力，项目历时几个月，最终确保0B成功切换， 完成大促挑战。演进式规划(Evolutionary)在架构演化选择时,对关键架构决策逬行原型验证，确定最佳演化方向。谈到互联网时代的技术和产品迭代，我们常常看到一个观点，鼓励快速试错。精益 创新和敏捷迭代固然重要，然而在严苛金融场景下

26、进行关键架构决策时,试错的代 价往往会变的难以承受。从我们的实践经历来看，演进式规划的本质是，迈向一个架构 愿景目标时一定要对关键架构决策进行原型验证，为此还要最大程度上在实际环境中保 证可行性。回顾2015年从同城双活迈向异地多活时，整个体系改造包括了机房搬迁、 选址，几乎所有系统的相关改造，为保证能万无一失,所以我们做了非常多的验证。IDC-1IDC-1IDC-2演进式规划：异地部署前的充分原型验证异地部署的一大难以逾越的挑战是地理位置所带来的延时。光纤可以做粗，但光速无法 变快。我们首先在中间件层面实现了故障注入的能力，而延时就是可能的故障之一。我 们在当时同城双活的架构中，在未来可能产

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

28、全。通过尽可能真实的状况模拟和故障注入，再到后来逐渐成熟的全链路压测，都是架构演化选择时的最佳实践，在演化的过程中,必须要对关键架构决策进行充分的原型验证, 如同生物进化，做多种可能的尝试，以确定最佳演化方向。倍巴倍巴小结：金融级云原生架构升级参考路径我们把以上提到的三个观点，总结为一组金融架构进行稳妥转型的三大原则。大道至简 却知易行难，在架构的演逬过程中，这些原则已然深深的写进了蚂蚁的代码里。正是基 于这些原则，蚂蚁应用架构完成了从单体改造，走向单元化，实现同城双活再到异地多 活的变迁。在此过程中，我们关注技术风险，形成中台架构，不断把技术中台和业务中 台沉淀下来。我们相信这些原则有一定的

29、通用性，尤其是适合作为金融IT架构变迁的 参考路径。业务拆分和换务改ifi容觀化.DevOps平台工具 分布式事务与可H消息技术风险技术风险中台架构中台嘶m交何异地多活无损容灾元化与同城双:待地域秒圾容灾- -島线.呻牙卿逻抵单元化改造离可用与多加中心容轴设 SRE体系理设（蓝绿和灰度.攻防演塚.全犧路压测尊）应用分布式改造金融级云原生架构升级参考路径对于绝大多数以银行为代表的金融机构,到了一定体量并对业务发展有积极预见之时， 我们建议IT架构规划和升级，需要基于业务价值作增量化交付、稳健型创新、演进式 规划，构建中台能力敏捷响应市场需求,同时夯实完整的技术风险平台和体系以保证在 容量、变更、

30、故障自愈、资损防控领域等方面的建设，使新老技术和价值理念混合并存、 架构升级的过程中,依旧可以保证稳妥发展与创新。挑战2:严苛金融场景下如何确保架构平衡？蚂蚁金服这十多年来，业务场景和规模持续同技术产品一起飞速发展，对技术能力的要 求不断提高，从量变发展到架构质变；有了坚实的技术架构底盘支撑，业务亦能有更为 广阔的想象空间，通过科技创新能力搭建一个开放、共享的信用体系和金融服务平台。我们倡导架构平衡，意味技术目标与组织需求能够相互适应，共同发展。关于严 苛金融场景下如何确保架构平衡的问题挑战，我们通过介绍微服务架构产品在蚂蚁的 发展历程，讲述我们在不同阶段的架构平衡考量和原则，希望能对金融机构

31、进行架构选 型和路径决策时提供参考。阶段一：快速搭建单体应用：满足交付效率在最早期还只是淘宝收银台的早期时代，支付宝还是一家纯粹的创业公司，当时最重要 的就是交付效率，当时尝试使用眼前能获得的最快最成熟的方案，比如许多金融机构IT 耳熟能详的商业软硬件、互联网上能找到的开源技术。当时不用考虑太多扩展性和容灾 能力，而正是这些非常经典的技术和架构,支撑了支付宝业务模式的早期探索。阶段二：模块化+ SOA :组织和业务规模飞速增长第二个阶段，我们发现组织和业务规模上涨的非常快，同时对交付的要求又非常高，因 此业务架构和应用设计急需一种抽象和模块化的能力，解决多方协作开发部署的需求。 此时整体硏发框

32、架开始了面向服务化的改造，应用开始拆分以确保能够分而治之，极大 了改善先前100多人同时开发整个业务模块的情况，通过抽象和隔离，减少并行研发 过程中互相之间的影响，又极大加快了编译、测试、发布的效率。在这个背景下,分布 式中间件SOFA应运而生,当时SOFA在内部的全称叫做Service Oriented Fabric Architecture ,意为能够将SOA架构通过服务化地方式重新组织,让硏发运维人员像 坐沙发一样舒适工作。阶段三：微服务的静态拆分与动态组合：优化成本以应对容量问题在第三阶段，业务规模和成本优化的这两个大的互相撕扯的力量是最需要破局的技术挑 战。团队和开发人员的规模、业务

33、的规模和峰值容量都上涨的非常快。关于微服务的拆 分和治理，当时我们内部激烈讨论过一个问题，到底拆100个服务、1000个服务还是 2000个服务是正确的，而我们当时就在不断摸索这个平衡点。俗话说分久必合，合久必分。微服务架构的优势不言而喻，但有时逆向思维也会非常精 彩。我们考虑了另外一条路径，即有没有可能把各应用以微服务的方式分别开发测试的 前提下,把一些系统上合并起来进行部署。回顾支付宝系统中的关键交易链路，交易创 建、收银台展现、交易支付三个阶段的调用量是高度耦合的，这些业务逻辑背后所关联 的许多微服务应用是否能有更优化的部署模型。于是我们对研发框架和运行时组件作了 非常多的研究和改造，确

34、保保持项目代码分开的情况下，能够进行合并部署。合并部署的核心思路是实现类隔离，同时服务注册发现、路由逻辑以调用本地实例为优 先。合并部署的技术应用经历过大量POC原型验证,最后成功地把一些指定的服务部 署成为一套合并的系统，同时保持其他仍旧以微服务形式，最终为当年大促省下了非常 多的机器，极大提高了资源利用率。随着架构的演进,后期我们将这套思路用更为优雅 的编排调度和容器来实现，升级为合并部署2.0,这个是后话了。阶段四：单元化与异地多活：跨机房和地域的容灾和扩展能力保障业务急速发展单机房的容量无法无限伸缩，更是无法保证容灾能力能满足业务连续性的需要。在此阶 段，我们会在风险质量以及业务规模、

35、成本方面去平衡，通过单元化改造使整体架构具 备异地多活能力。为此，我们实现了跨机房的服务注册发现能力、提供了跨机房的服务 调用路由逻辑，从入口流量到微服务、中间件和底层数据库，全链路地消除了单点，使 整体服务都具备了分片和横向扩展能力，同时保证了资源利用率，破除了传统主备架构 所带来的成本负担。阶段五：服务化基础设施下沉：Service Mesh平滑支撑海量异构的金融科技应用随着蚂蚁业务发展和各线金融科技的不断探索，不止团队规模在飞速扩充，以支撑区块 链、人工智能、风控核身、物联网、金融计算等各方面发展的需要。在这样的现状前提 下，内部技术栈逐渐开始多样化，从相对统一的Java逐渐加入了非常多

36、的基于 Node.js、C+ +、Python等异构语言的微服务应用。但这些应用本身不应是割裂的， 我们依旧希望依旧能够贯通到一个统一的体系进行管理，尽量以轻量级、低成本的方式 向这些系统提供近乎一致的微服务管控和互相发现通讯能力，而不是向每一种技术栈都 提供一个客户端SDK并将关键能力重新实现一遍。同业界的观点一致，我们亦认为Service Mesh是微服务未来发展的重要趋势。其本身的实现原理和优势,社区已经有了非常多的讨论,而对蚂蚁来说，首先看重的就是其对 倍巴异构微服务应用、遗留应用互相之间发现、通讯和治理提供了非常优雅的解法。通过 Service Mesh的方案，我们可以尽量把最多的功

37、能从中间件的客户端中移到一个并行 部署的轻量代理中,并对服务应用透明，目标是做到一次实现，就搞定所有语言，这个 对于基础设施团队来说，在成本和稳定性上都是一个提升。小结：寻求最平衡的架构发展路径以满足业务发展和严苛场景考验，而不仅仅关注功能本 身SMt SOA THBlMRSOf微服务演进：应对业务发展诉求的架构平衡金融IT系统的架构选型需要非常慎重，以银行核心系统为例，系统选型几乎就是一个 公司战略级别的决策，关乎着长期影响。在当前历史时期，有非常多的银行机构开始考 虑逐渐从单体架构向分布式架构进行融合与升级。围绕着业务价值作IT架构交付，绝 不只是看哪种技术比较时髦或功能强大，这背后的选型

38、元素涵盖了服务化架构、敏捷交 付、API平台开放、综合成本等话题，也包含着落地可行性和生态成熟度等方面，因此 更需要关注这套技术产品的长期愿景和发展规划，比如有没有公有云的业务战略、有没 有提供一整套从经典架构迁移至先进架构的转型路径方法实践，更看重在业内有没有真 实参考案例和服务体系支撑。在通过多个维度对架构和技术产品本身进行评估的同时，对组织发展现状的认知也非常 重要。为此，我们为技术选型决策抽象出两部分能力,一部分代表不断发展的现 实状态，包括了 团队能力、组织规模和业务规模；另一部分代表技术 目标，代表业务对我们的要求，包括了 交付效率、成本优化和质量风险。我们认为架构选型的实质是为了

39、使组织能力和技术能力达成一种平衡，通过权衡组织发 展的现状和未来，来找寻最合适的技术发展可实现愿景和可落地路径。挑战3:如何应对核心金融系统的关键技术挑战？成熟的新技术推动着数字化业务能力和客户体验个性化的提升。在购物、医疗、出行、 社交等不同的复杂场景，最终用户通过互联网、移动端,甚至物联网设备等渠道获取金 融服务的机会已经越来越频繁。在这样的场景化数字金融时代，用户选择多样，市场竞 争也在不断加剧，在众多同类金融服务竞争中脱颖而出的必要条件是能够提供一体化全 方位数字化的服务,即用户希望无论何时何地，通过触手可及的设备或者平台，都能一 站式地满足其金融生活和业务的需求。场景极大丰富，亦为金

40、融业务营销活动提供了非 常大的想象空间-地理位置、时间作息、淡季旺季等因素不再是决定获客营销的关键因 素，计划中的大促活动和计划外的热点事件，都有可能为金融机构的信息系统产生巨大 挑战。以一个常见的日常交易场景是当面付为例。当用户拿出手机，打开二维码进行付款操作， 后台会进行一系列技术处理。这中间最主要的环节是风险识别；风险识别以后，是相应 的营销决策，判断用户在该笔交易中应该获得多少红包或者奖励；最终完成交易，发生 账户扣款并产生结果。这样一个简单的场景背后蕴含着一系列以计算为核心的交易处理 过程。而这个场景正在时时刻刻发生在现实生活中。在普惠金融和互联网业务蓬勃发展 的大背景下，具备大规模

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

42、生架构的过程中，有以下四大关键技 术挑战需要积极应对：无限可扩展能力：如何规模化分布式服务和数据能力，也就是服务和数据处理的可伸 缩性无损秒级容灾：如何做到秒级快速容灾能力，做到四个9及以上的系统可靠性 高性能分布式事务：当服务和数据分布后，如何保证事务中数据的强一致性，这是金 融级分布式系统最大挑战之一 弹性供给与调度：怎么做低成本，按需提供资源配置与调度,如何做到交易成本的降低无限可扩展能力我们在前文架构变迁历程中提到了单元化，这是整体架构能够进行无限可扩展的关键前提。单元具备四个重要特性：一、自包含性，比如账户充值交易所涉及的所有计算和数据都会被封闭在一个单元；二、松耦合性，单元之间只允

43、许进行服务调用,不允许直接访问数据库或其他存储，对 于必须跨单元的操作，比如位于两个不同单元之间的用户转账交易，服务调用需尽可能 少，同时在不影响客户体验的情况下，尽可能异步化。这样，即便两个单元相距较远, 整个系统的响应也不会受单元间访问延迟的影响；三、故障独立性，一个单元的故障不会影响其他单元；四、容灾性，单元之间相互备份，每个单元都保证在发生同城或异地故障时有可接管的 单元，单元之间的备份方式是使用自研数据库提供的多地多中心的一致性方案。单数据中心按澹澗配IDC级自包含按隽分度拨数据中心（华东）业务館元J业拆维调数据中心（华南）业务单元-2业务筆元-5业务单元3业务箪元-4中删中何件中间

44、件中1聃15板连共事草元无限可扩展：异地多活与单元化架构通过单元化架构,全局系统的伸缩问题变成了逻辑单元的增减问题，而在此过程中，整 个单元的规模和内部复杂性是相对稳定的，这就降低了系统整体伸缩的复杂度；其次, 单元的故障独立性使得我们能够控制软硬件故障的影响面；最后，单元之间可快速切换， 这就使得我们处理同城和异地容灾时可以更加简单高效。无损秒级容灾 单元化解决了业务和服务层面的扩展性和容灾问题，但数据层面的容灾问题并没有得到 解决。如果发生城市级故障，我们仍然不敢把核心业务流量切换到另一城市，那我们实 际上仍然停留在原地。但这个问题不管是商业数据库还是开源数据库都是无解的，我们 可以通过各

45、种技术手段尽可能降低故障切换时间，减少故障影响的客户范围，但无法避 免资损的发生。这个问题，在我们有了自己的数据库OceanBase之后，被彻底解决了。OceanBase的核心是基于Paxos协议的多数派分布式选举协议，Paxos协议的价值已被 业内广泛认可。该协议保证只要多数成员依然存活，任何少数成员的故障不会影响系统的 整体可用性和数据一致性。所以,如果把一个数据集群部署到三个或三个以上城市时，我 们就可以保证任何一个城市的故障，系统都可以实现无损容灾，也就是RPO=0e同时, 系统可在30秒以内把故障切换到另一城市，故障切换过程在数据库层面自动完成，对上 层业务没有影响。另一方面,当我们

46、把一个数据库集群部署到三个城市时，为了避免任何 单机故障导致的业务跨城市访问问题，我们把数据库集群中的副本数量从3个增加到5个， 这就是我们今天所说的三地五中心，或者严格一点，三地五副本多中心。倍巴城市2IDC1IDC2IDC3IDC4IDC5app write_3app.write.lRegion 1Region 2Region 3Read/Write Zojnenapp.read.lapp.read_2app.read.3app.read_4金服科技无损秒级容灾：金融级关系型数据库OceanBase ,三地五中心高可用部署从两地三中心到三地五中心，我们解决了一个基础又非常重要的问题，即便发

47、生城市级故障，整个城市都不可用，数据库层面仍然可以做到，系统不丢数据,不停服务。蚂蚁金服花了数年时间来演进基于单元化和三地五中心的异地多活和容灾架构，至今已 在多个城市部署了多个数据中心，所有的核心交易流量部署在所有数据中心并可随时切 换和调配，通过异地多活，我们实现了流量在全国范围内的任意扩展，极大地提高了资 源利用率。最重要的是，我们提升了系统面对城市级故障的能力。蚂蚁金服在如此大规 模的金融交易系统中实现了这样的容灾能力，这在世界上属于首创。高性能分布式事务众所周知，金融交易对于一致性要求非常高，传统银行集中式核心采用单一事务，要么 全成功,要么全失败，非常好的满足了一致性要求。蚂蚁通过

48、微服务架构,实施业务垂 直拆分和数据水平拆分，这就意味着存在大量的微服务和大量的单元数据库，一个完整 金融业务需要调用多个服务和数据库完成，因此，保证服务与数据处理达到金融级的一 致性将是面临的首要难题。传统技术中的事务一致性方案对资源加锁的时间长、粒度大， 在很大程度上制约了系统的可伸缩性与高可用性，无法满足架构向单元化、异地多活的 发展需要。为了解决这个难题，我们自主研发和演进SOFA-DTX分布式事务解决方案已经近10年，伴随着支付宝一起经历了复杂场景和高并发的挑战，充分考虑了各类异常情况，具 备足够的伸缩性、高并发和高可用性，支持跨机房的事务协调能力，已经是一套非常成熟的金融级分布式事

49、务框架和服务。该方案引入事务观察者协调分布式事务的各参与方, 达到整体的事务一致性。实现了两阶段提交协议，第一阶段采用本地端事务，操作仅预 留必要的资源，处理成本足够低,第二阶段可以异步执行，使得业务整体具备了较高的 性能和较强的吞吐能力。基于2PCS6务的分布式事务基于2PC消息的分布式事务交易系统账务系统数据持久流程引擎规则引擎交易引擎消恵臥列统一事件 商户通知 收费接入资金处理收费系统支付工具系统高性能分布式事务：跨服务一致性保证和异步可靠消息我们还辅以可靠消息中间件来支持最终一致性的需要，形成了一套事务型消息框架。此 类消息发送给消息服务器与数据库事务状态保持一致，当事务状态是提交时，消息才会 被投递到订阅者，当事务状态是回滚时，消息不会被投递到订阅者。分布式事务解决方案被蚂蚁金服、网商银行各业务系统（包含核心账务等）广泛使用，