2019年11月19日，蚂蚁金服在北京举办“巅峰洞见·聚焦金融新技术”发布会，介绍2019双11支付宝背后的技术，并重磅发布全新 OceanBase 2.2 版本和 SOFAStack 双模微服务平台。我们将系列演讲整理并发布在 “蚂蚁金服科技” 公众号上，欢迎关注。

蚂蚁金服金融科技产品技术部总经理杨冰，在发布会分享了蚂蚁金服金融级云原生在双十一的大规模应用实践，以下为演讲整理全文：

2018年双11，蚂蚁金服和网商银行正式应用云原生架构，2019年双11，蚂蚁金融级云原生架构进一步深入落地，Service Mesh 架构100%覆盖蚂蚁金服核心支付链路，是业界最大的 Service Mesh 集群。本文将分享蚂蚁金融级云原生在2019年双11中的大规模应用实践。

历年双十一的交易峰值不断增长，给整个技术带来了巨大挑战和牵引力。在这样的驱动力下，技术架构又发生什么样的变革？蚂蚁金服从第一代集中式架构，逐步走向分布式架构，再到云平台，蚂蚁的架构已经形成了比较体系化的金融级分布式架构，能够很好的去支撑业务的发展。

金融级分布式架构需要 Service Mesh

几代架构演进中，虽然解决了很多业务痛点和问题，但也确实让业务做了很多的升级、改造、上云等事情。我们开玩笑说云包治百病，业务研发团队就问，能不能让我们未来只关注业务开发本身，剩下的事情交给基础设施？我相信这个问题也是我们下一代架构往金融级云原生架构演进过程中需要去解决的一个问题，也是云原生这个技术本身要解决的问题。总结来说：交易规模的演进确实需要架构升级，但架构升级不希望成为业务的负担。

如何解决这个问题呢？我们先来回顾下架构演进的过程。

金融交易技术演进的第一阶段是实现金融级分布式架构，SOFAStack 和 OceanBase 是构成这个架构的基础。需要强调的是，整个金融级能力，包括高可用、一致性、可扩展、高性能，都需要应用到数据存储端到端整体能力。

比如分布式事务，OceanBase 从数据库层面提供了分布式事务的支持，但当我们把两个极其重要的业务数据放到两个 OceanBase 集群的时候，就需要由应用层来解决跨数据库的一致性问题，这个就是中间件需要提供的能力了。所以分布式架构下必须具备的端到端的一致性，才能构成整体架构的一致性。高可用、可扩展、高性能也是一样的道理，缺任何一个能力都不能算是真正的金融级分布式架构。

这张架构图的虚线以下表示的是目前蚂蚁的金融级分布式架构中的核心组件，这一层软件经历了十几年的发展已经抽象的比较完备，而且很好的支撑了业务的发展。

但真正系统实现中，业务层跟下面几个组件有着千丝万缕的联系，这个关系可能存在于下层为了减少上层的改动提供的兼容性SDK 里，也许存在于上层迁就适配下层特殊用法里，这样的例子层出不穷，一直伴随着整个架构演进的过程。

而在下层演进发展过程中，这种耦合和千奇百怪的兼容适配问题就会形成巨大的阻力和风险。金融IT同行在做数字化转型的时候也会遇到同样的痛点，甚至于可能会比像蚂蚁金服这样的互联网公司遇到的困难更多一些。相比于互联网公司相对还比较统一的架构来说，很多企业的IT 系统中就像博物馆，三代同堂，遗留系统一大堆，还有很多外采的系统。所以这个架构分层虽然清晰，但却无法独立演进。

蚂蚁同样有这样的问题，内部有上千个系统，几十万台服务器，在业务迭代发展这么快的情况下，根本没有太多精力来配合进行基础设施的升级。而业务不动基础设施就动不了，很多能力就无法全局生效，这样就发挥不了威力。

举个最简单的例子，全链路压测很强大，但如果没有自上而下的推动全业务线配合升级 SDK，使得整体通信架构能支持全链路标识透传和识别的能力，就无法实现全链路压测，也许到今天我们还没法享受这个技术带来的红利。这样的例子很多，很多的创新也是因为卡在「相互等待」的死锁中，迟迟未能落地，甚至胎死腹中。

软件世界里面有一句经典的话：没有什么问题是不能通过一层抽象解决的，如果说有，那就再加一层。我们希望能够有这一层将业务和基础设施解耦，正好云原生发展过程中出现了 Service Mesh，而且这一层软件抽象从逻辑分层走向了物理分离，既起到了解耦的作用，又具备独立演进的能力。

康威定律认为，一个软件系统的架构背后一定有对应的组织架构，之前的架构中，业务开发和基础设施开发虽然在组织上已经基本分开，但软件上却没有切开，Service Mesh 的出现正好解决了软件架构和组织架构不匹配的问题。

把这层抽象剥离变成独立的载体是一个趋势，不仅仅 Service 应该被 Mesh 化，更多的中间层可以被 Mesh 化，蚂蚁也是这么实践的。这也是业务应用在云原生时代，如何把自己的一些诉求更好的交给云，让应用跟云之间的交互变得更简单的一个过程。

蚂蚁金服自研的 SOFAMesh 在双十一中大规模应用，100%覆盖核心支付链路，容器规模几十万，千万 QPS，性能消耗极低，而将迭代速度从1-2次每年提升到10+次每月。在 CPU、内存和相应时间等数据上来看，我们通过极小资源的代价，换来了系统快速迭代的速度，在备战双十一的短短两个月，Service Mesh 进行了几十次迭代和发布，快速响应了全新的大促需求，并完整多次的全站升级和全链路的线上验证。

这在以前几乎是不可想象的，今年任务的复杂度和工作量，如果没有 Service Mesh，将无法完成。要么只能砍需求，要么需要消耗更多业务研发的资源来配合我们做大量升级验证工作。遗留系统也能通过装配这样一套软件，就能够具备完整的分布式架构能力，且性能损失只有一点点，同时还获得了分布式架构的快速演进能力，因此这绝对是一个值得投资的技术方向。

SOFAMesh架构图

这个是 SOFAMesh 的架构图，里面是分成控制面和数据面两个部分，控制面是在产品层大家想要的一些能力，走向微服务架构要解决什么样的问题，希望在这个架构上有更多的运维能力、监控能力、流量调控能力、安全能力、扩展能力。

数据面 SOFAMosn 是独立出来的进程，它可以跟 APP 进行交互，和 APP 在一个 POD 里。图中除了 SOFAMosn 承载了 APP 之间的通信任务之外，还将异步消息的通信逻辑也沉淀进去了，成为应用对外同步异步通信的统一门面。同时我们也把应用访问数据库的中间层路由逻辑和配置管理逻辑独立成一个 sidecar，称之为 DBMesh，这个图里用 More Sidecar 来表示，意味着未来可能有更多的逻辑可以下沉到 Mesh 层。

未来应用将使用非常轻薄的 SDK 或者简单的 API 跟外界交互，而复杂的路由、治理、高可用等相关的逻辑就下沉到 Mesh 层了，此后全局架构改造就会变得非常的轻松，对业务没有打扰。

接入 Service Mesh 的挑战与解决之道

在应用 Service Mesh 的过程中，蚂蚁金服也遇到了不少困难和挑战，很多的社区方案其实并不能很好的满足金融行业的需求，尤其对高可用、稳定性的苛刻要求，蚂蚁在接入过程中也做了不少创新。

首先第一个问题是，Service Mesh 是如何接入到整个体系里呢，它的资源消耗又怎样呢？

要按云原生社区的方式安装一个 sidecar，就是扩容出来一批新的 POD，里面已经为APP 装配好了 sidecar，然后把老的 POD 逐步下线销毁。这就像要给一辆车装个新功能，我们需要搞一批有这个新功能的新车给到客户，然后把老车召回，这个非常浪费资源。而且在给大规模集群上 sidecar 时需要更多的资源 buffer 去做滚动升级，成本很高且效率很低，而且连应用和 POD 一并销毁重建，这个变更的动静太大，也的确有不小的风险。

我们采用了注入升级的方式，这里也对原生的 K8s 做了很多扩展的改动。

在资源消耗的优化方面，我们也做了很多探索。理论上既然将这个进程独立出来跑在容器里，就应该分配独立的 CPU 和内存资源，我们开始也是这么做的，但跑下来反而出现很多性能瓶颈。后来我们发现，根本性问题在于虽然这个进程是独立的，本质上它还是一段从应用里剥离出来的逻辑，无论它是帮助应用做服务通讯，还是访问数据库，都是在应用主链路上，如果为这些逻辑设置了跟应用不一样的 CPU 和内存限制，反而会使得应用在做主链路业务的时候，受到这个独立进程的资源消耗瓶颈影响。最后我们通过实践，通过注入融合的方式，跟应用一起去共享 CPU 和内存，不但能达到最好效果，也最大程度减少资源开销。

这整个升级的过程，类似于我们把一辆普通的车，注入一个模块变成了一个可持续升级的特斯拉，随时随地做空中升级。而且这个模块与应用共享电源和公共资源，达到最小的功耗。

既然空中升级的能力很好，怎么样能稳妥保证这个模块自身的升级呢？

社区的方案是销毁整个 POD，连同 APP 和 sidecar，再创造一个新的，里面包含了原来的 APP 和新的 sidecar。这样一来，虽然这个东西从应用层剥离出来，但是还是跟应用放在一起整体作为一个软件创建、销毁、升级，未免显得有些笨重。

其实大部分是要做这个进程的升级时，应用是没有变化的。这种方案似乎也违背了把它剥离出来进行独立演进的初衷，这也是我们探索过程中发现社区的方式不太理想的地方，而且整个方案也没有流量摘除、优雅上下线这种设计，整个方案比较简陋粗暴。

我们探索了独立升级 sidecar 的模式，并且实现了较为复杂的流量热迁移。整个过程应用完全无感知，就像是我们给别人打电话，如果对方是个双胞胎，当话筒被另一个接过去时，我们还是面对的同样的电话，同样的通话通道，对方换了个人，我们无感知。这样整个升级过程非常的平滑，也对业务无打扰，流量也不会出现波动，符合金融级对稳定性的要求。

整个过程还是用车打比方，之前看过一个劳斯莱斯的广告，车子开过隔离带的时候，里面的乘客没有任何感觉，放在车上那杯水也没有任何的震动，虽然没坐过这么好的车，不知道是否真的能做到像广告里的效果，但整个过程很震撼。我想平滑升级的效果就应该像这个过程一样。

Service Mesh 在双11大促中起到了什么作用呢？我们先回顾下过去做过的一些事情。

蚂蚁在上云后整个系统具备了弹性伸缩能力，于是每次在搞大促活动，无论双11、双12还是新春红包，我们都将对应业务链路的系统，动态弹到云上，用完了再缩回来。这个动作说起来简单，其实非常复杂，而且操作的变更非常大，但是由于几个活动间隔时间足够长，所以我们可以比较坦然的做这个事情，而且还是会额外消耗资源。

今年提了新要求，双11零点要搞天猫大促，第二天早上7点蚂蚁森林又要支持偷能量搞活动，考虑到双十一后还有两三个小时处理收尾流量和降级的调度任务，留给系统做调度的时间也就短短的4、5个小时，怎么样在这么短的时间内将一个业务链路上的系统全部熄火，再把另外一条拉起来预热到最佳状态，而且不允许额外增加资源，这个挑战非常大。

我们通过类似超卖的方式把两条链路的应用部署在同一组 POD 里，一组处于运行态，一组处于保活态，当需要切换时，我们将运行态的资源收缩，流量比例调低，变为保活态，把另一组应用做反向操作变成运行态。

整个过程我们做了非常精细化的流量调拨、转发、保活。保活非常重要，因为应用在这么短时间热起来，需要有一定的保活流量来维系应用的基本状态，包括DB连接、通信连接、缓存等等。Service Mesh 在切换过程中将一部分流量转发到别的机器，一部分放进来用于维系应用的「热状态」。

听到这里大家可能会问，这样的场景是不是只有像蚂蚁金服或者是阿里巴巴大的一些公司才会有的？这个功能对于我来说有什么用？对于大部分的企业的意义是什么呢？这些流量调拨能力只是 Service Mesh 在大促应用场景当中一个小小的尝试。Mesh 架构除了解决基础设施下沉的一些问题之外，我认为最大的价值在于服务化流量的精细化管控，这也是精细化运维的趋势。

以上图为例，这里介绍了精细化流量管控的三个方面，包括多版本发布、压测引流、服务分组。

很多朋友听过灰度发布，新上一个服务，线上灰度验证一下，控制一定的流量比例给新服务，如果 OK 再全量放开，这件事情听上去也不难，例如这个服务就是外部流量入口的话，很容易控制入口流量的比例，因为流量上游就是外部客户请求，一定是有接入层可以控制的，但当是一个上游有好几十个，甚至好几个百各应用来调用就不那么好控制了。

如果我们想同时验证一组新服务可能更难，如何能保证这个灰度流量只在这组新服务之间流转而不逃逸出去？如果没有统一的流量调拨能力就没有办法控制这么细，那只能用大招，就是用额外的资源，单独开辟一个环境，或者是单独开辟一个机房，专门作为灰度环境，流量在这个环境内闭环，这个方案可行，也是我们目前在用的方案之一，但是成本很高。如果全部装上这套系统，就可以在线划分出来任意的逻辑单元，做流量灰度，做多版本验证发布。

同样的逻辑也适用于细粒度的容灾切换、引流压测、服务分组等，未来可以基于这种全局的流量管控能力做很多创新，来做稳定性和高可用的事情，也能帮助业务做灵活的业务相关的流量调拨。

Service Mesh 带来的全局流量管控能力就好比手机导航。比如要从国贸去北京南站，系统会给你一个推荐路线。当大家都用同类软件的时候，整个系统就能根据整个交通通行状况给不同的人不同的推荐路线，以便最大程度的提升整体交通的吞吐量，在全局形成最优方案。这就是导航系统通过手机这个 sidecar 来进行全局车流量调拨和优化的场景，这也是 Service Mesh 可以给我们系统带来的价值。在这个方向上，我们内部已经有很多新的探索在做，我相信未来会有更多的创新玩法出来。

蚂蚁金服 Service Mesh 正式对外开放

以上提到的技术会我们会在 SOFAStack 的微服务平台上逐步开放，大家可能也都遇到了异构系统无法统一治理、分布式改造成本比较高、技术栈绑定等问题，也在希望能有一种方式简单直接的帮助整个系统改造为一套分布式系统，并且能适配兼容各种框架。我们今天开放的 SOFAMesh 可以以无侵入的方式帮助应用进行分布式改造，支持多种协议，兼容异构系统，不但可以跑在云原生，还可以跑在虚机上。且经过了大规模金融级的线上验证。

这个图是大概的架构，不展开讲，核心意思是说这样一套体系可以兼容蚂蚁金服的 SOFA 系统，也可以兼容社区的 Dubbo 应用、SpringCloud 应用，整个可以跑在云原生架构上，也可以跑在虚拟机架构上，背后是有经过我们多年考验的服务注册中心作为支撑。

现在我们只迈出一小步，在未来还会继续做更多探索。除了服务化，我们正在把全机房流量都统一管理起来，无论是从网络接入层进来的南北向流量，还是一个机房内部的东西向，或者是机房之间的东西向流量，全部纳入到一套体系上来管理。同时，在对外的产品上，为了帮助更多的客户适配已有的体系，我们也在做针对不同的注册中心适配工作，以便能够纳入到同一个控制面统一管理，这个是未来演进的方向。

这些技术本身有很多核心的代码也是开源的，对内在跟阿里集团在共建，对外也在努力向 upstream 做贡献，跟谷歌这样的公司合作。我们希望能够得到大家更多的关注并参与贡献，也希望大家能积极参与到云原生架构在金融场景的落地探索中来。