蚂蚁金服 Service Mesh 大规模落地系列 - RPC 篇

蚂蚁金服云原生负责人鲁直 双十一后首次线下分享

引言

Service Mesh 是蚂蚁金服下一代架构的核心，本主题主要分享在蚂蚁金服当前的体量下，咱们如何作到在奔跑的火车上换轮子，将现有的 SOA（service-oriented architecture，面向服务的架构）体系快速演进至 Service Mesh 架构。聚焦 RPC 层面的设计和改造方案，本次将分享蚂蚁金服双十一核心应用是如何将现有的微服务体系平滑过渡到 Service Mesh 架构下并下降大促成本。

蚂蚁金服每一年双十一大促会面临很是大的流量挑战，在已有 LDC（Logical Data Center，逻辑数据中心，是蚂蚁金服原创的一种“异地多活单元化架构”实现方案）微服务架构下已支撑起弹性扩容能力。本次分享主要分为 5 部分：

• Service Mesh 简介；
• 为何要 Service Mesh；
• 方案落地；
• 分时调度案例；
• 思考与将来；

做者简介

黄挺（花名：鲁直）：蚂蚁金服云原生负责人
主要 Focus 领域：

• SOFAStack 微服务领域；
• Service Mesh，Serverless 等云原生领域；

雷志远（花名：碧远）：蚂蚁金服 RPC 框架负责人
主要 Focus 领域：

• 服务框架：SOFARPC（已开源）；
• Service Mesh：MOSN（已开源）；

SOFARPC：https://github.com/sofastack/sofa-rpc

MOSN：https://github.com/sofastack/sofa-mosn

Service Mesh 简介

在讲具体的蚂蚁金服落地以前，想先和你们对齐一下 Service Mesh 的概念，和蚂蚁金服对应的产品。这张图你们可能不陌生，这是业界广泛承认的 Service Mesh 架构，对应到蚂蚁金服的 Service Mesh 也分为控制面和数据面，分别叫作 SOFAMesh 和 MOSN，其中 SOFAMesh 后面会以更加开放的姿态参与到 Istio 里面去。

今天咱们讲的实践主要集中在 MOSN 上，如下个人分享中提到的主要就是集中在数据面上的落地，这里面你们能够看到，咱们有支持 HTTP/SOFARPC/Dubbo/WebService。

为何咱们要 Service Mesh

有了一个初步的了解以后，可能你们都会有这样一个疑问，大家为何要 Service Mesh，我先给出结论：

由于咱们要解决在 SOA 下面，没有解决但亟待解决的：基础架构和业务研发的耦合，以及将来无限的对业务透明的稳定性与高可用相关诉求。

那么接下来，咱们一块儿先看看在没有 Service Mesh 以前的情况。

在没有 Service Mesh 以前，整个 SOFAStack 技术演进的过程当中，框架和业务的结合至关紧密，对于一些 RPC 层面的需求，好比流量调度，流量镜像，灰度引流等，是须要在 RPC 层面进行升级开发支持，同时，须要业务方来升级对应的中间件版本，这给咱们带来了一些困扰和挑战。如图所示：

1. 线上客户端框架版本不统一；
2. 业务和框架耦合，升级成本高，不少需求因为在客户端没法推进，须要在服务端作相应的功能，方案不够优雅；
3. 机器逐年增长，若是不增长机器，如何度过双十一；
4. 在基础框架准备完成后，对于新功能，再也不升级给用户的 API 层是否可行；
5. 流量调拨，灰度引流，蓝绿发布，AB Test 等新的诉求；

这些都困扰着咱们。咱们知道在 SOA 的架构下，负责每一个服务的团队均可以独立地去负责一个或者多个服务，这些服务的升级维护也不须要其余的团队的接入，SOA 其实作到了团队之间能够按照接口的契约来接耦。可是长期以来，基础设施团队须要推进不少事情，都须要业务团队进行紧密的配合，帮忙升级 JAR 包，基础设施团队和业务团队在工做上的耦合很是严重，上面提到的各类问题，包括线上客户端版本的不一致，升级成本高等等，都是这个问题带来的后果。

而 Service Mesh 提供了一种可能性，可以将基础设施下沉，让基础设施团队和业务团队可以解耦，让基础设施和业务均可以更加快步地往前跑。

咱们的方案

说了这么多，那咱们怎么解决呢？咱们经历了这样的选型思考。

整体目标架构

咱们的 MOSN 支持了 Pilot、自有服务发现 SOFARegistry 和自有的消息组件，还有一些 DB 的组件。在产品层，提供给开发者不一样的能力，包括运维、监控、安全等能力，这个是目前咱们的一个线上的状态。

SOFARegistry 是蚂蚁金服开源的具备承载海量服务注册和订阅能力的、高可用的服务注册中心，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。

看上去很美好，要走到这个状态，咱们要回答业务的三个灵魂拷问。

这三个问题后面，分别对应着业务的几大诉求，你们作过基础框架的应该比较有感触。

框架升级方案

准备开始升级以后，咱们要分析目前咱们的线上状况，而咱们如今线上的状况，应用代码和框架有必定程度的解耦，用户面向的是一个 API，最终代码会被打包，在 SOFABoot 中运行起来。

SOFABoot 是蚂蚁金服开源的基于 Spring Boot 的研发框架，它在 Spring Boot 的基础上，提供了诸如 Readiness Check，类隔离，日志空间隔离等能力。在加强了 Spring Boot 的同时，SOFABoot 提供了让用户能够在 Spring Boot 中很是方便地使用 SOFA 中间件的能力。

那么，咱们就能够在风险评估可控的状况下，直接升级底层的 SOFABoot。在这里，咱们的 RPC 会检测一些信息，来肯定当前 Pod 是否须要开启 MOSN 的能力。而后咱们完成以下的步骤。

咱们经过检测 PaaS 传递的容器标识，知道本身是否开启了 MOSN，则将发布和订阅给 MOSN，而后调用再也不寻址，直接完成调用。

能够看到，经过批量的运维操做，咱们直接修改了线上的 SOFABoot 版本，以此，来直接使得现有的应用具有了 MOSN 的能力。有些同窗可能会问，那你一直这么作不行吗？不行，由于这个操做是要配合流量关闭等操做来运行的，也不具有平滑升级的能力，并且直接和业务代码强相关，不适合长期操做。

这里咱们来详细回答一下，为何不采用社区的流量劫持方案？

主要的缘由是一方面 iptables 在规则配置较多时，性能下滑严重。另外一个更为重要的方面是它的管控性和可观测性很差，出了问题比较难排查。蚂蚁金服在引入 Service Mesh 的时候，就是以全站落地为目标的，而不是简单的“玩具”，因此咱们对性能和运维方面的要求很是高，特别是形成业务有损或者资源利用率降低的状况，都是不能接受的。

容器替换方案

解决了刚刚提到的第一个难题，也只是解决了能够作，而并不能作得好，更没有作得快，面对线上数十万带着流量的业务容器， 咱们如何马上开始实现这些容器的快速稳定接入？

这么大的量，按照传统的替换接入显然是很耗接入成本的事情，因而咱们选择了原地接入，咱们能够来看下二者的区别：

在以前，咱们作一些升级操做之类的，都是须要有必定的资源 Buffer，而后批量的进行操做，替换 Buffer 的不断移动，来完成升级的操做。这就要求 PaaS 层留有很是多的 Buffer，可是在双十一的状况下，咱们要求不增长机器，而且为了一个接入 MOSN 的操做，反而须要更多的钱来买资源，这岂不是背离了咱们的初衷。有人可能会问，不是仍是增长了内存和 CPU 吗，这是提升了 CPU 利用率。之前业务的 CPU 利用率很低，而且这个是一个相似超卖的方案，看上去分配了，实际上基本没增长。

能够看到， 经过 PaaS 层，咱们的 Operator 操做直接在现有容器中注入，并原地重启，在容器级别完成升级。升级完成后，这个 Pod 就具有了 MOSN 的能力。

MOSN 升级方案

在快速接入的问题完成后，咱们要面临第二个问题。因为是大规模的容器，因此 MOSN 在开发过程当中，势必会存在一些问题，出现问题，如何升级？要知道线上几十万容器要升级一个组件的难度是很大的，所以，在版本初期，咱们就考虑到 MOSN 升级的方案。

能想到最简单的方法，就是销毁容器，而后用新的来重建，可是在容器数量不少的时候，这种运维成本是不可接受的。若是销毁容器重建的速度不够快，就可能会影响业务的容量，形成业务故障。所以，咱们在 MOSN 层面，和 PaaS 一块儿，开发了无损流量升级的方案。

在这个方案中，MOSN 会感知本身的状态，新的 MOSN 启动会经过共享卷的 Domain Socket 来检测是否已有老的 MOSN 在运行，若是有，则通知原有 MOSN 进行平滑升级操做。

具体来讲，MOSN 启动的时候查看同 Pod 是否有运行的 MOSN (经过共享卷的 Domain Socket)，若是存在，须要进入以下流程：

• New MOSN 通知 Old MOSN，进入平滑升级流程；
• Old MOSN 把服务的 Listen Fd 传递给 New MOSN，New MOSN 接收 Fd 以后启动， 此时 Old 和 New MOSN 都正常提供服务；
• 而后 New MOSN 通知 Old MOSN，关闭 Listen Fd，而后开始迁移存量的长连接；
• Old MOSN 迁移完成， 销毁容器；

这样，咱们就能作到，线上作任意的 MOSN 版本升级，而不影响老的业务，这个过程当中的技术细节，不作过多介绍，以后，本号会有更详细的分享文章。

分时调度案例

技术的变革一般必定不是技术自己的诉求，必定是业务的诉求，是场景的诉求。没有人会为了升级而升级，为了革新而革新，一般，技术受业务驱动，也反过来驱动业务。

在阿里经济体下，在淘宝直播，实时红包，蚂蚁森林，各类活动的不断扩张中，给技术带了复杂的场景考验。

这个时候，业务同窗每每想的是什么？个人量快撑不住了，个人代码已经最优化了，我要扩容加机器。而更多的机器付出更多的成本，面对这样的状况，咱们以为应用 Service Mesh 是一个很好的解法。经过和 JVM、系统部的配合，利用进阶的分时调度实现灵活的资源调度，不加机器。这个能够在资源调度下有更好的效果。

首先，咱们假设有两个大的资源池的资源需求状况，能够看到在 x 点的时候，资源域 A 须要更多的资源，Y 点的时候，资源域 B 须要更多的资源，总量不得增长。那固然，咱们就但愿能借调机器。就像下面这样。请你们看左图。

在这个方案中， 咱们须要先释放资源，而后销毁进程，而后开始重建资源，而后启动资源域 B 的资源。这个过程对于大量的机器是很重的，并且变动就是风险，关键时候作这种变动，颇有可能带来衍生影响。

而在 MOSN 中，咱们有了新的解法。如右图所示，有一部分资源一直经过超卖，运行着两种应用，可是 X 点的时候，对于资源域 A，咱们经过 MOSN 来将流量所有转走，应用的 CPU 和内存就被限制到很是低的状况，大概保留 1% 的能力。这样操做，机器依然能够预热，进程也不停。

在这里，咱们能够看这张图。

在须要比较大的资源调度时，咱们推送一把开关，则资源限制打开，包活状态取消。资源域 B 瞬间能够满血复活。而资源域 A 此时进入上一个状态，CPU 和内存被限制。在这里，MOSN 以一个极低的资源占用完成流量保活的能力，使得资源的快速借调成为可能。

咱们对 Service Mesh 的思考与将来

Service Mesh 在蚂蚁金服通过 2 年的沉淀，最终通过双十一的检验，在双十一，咱们覆盖了数百个双十一交易核心链路，MOSN 注入的容器数量达到了数十万，双十一当天处理的 QPS 达到了几千万，平均处理 RT<0.2 ms，MOSN 自己在大促中间完成了数十次的在线升级，基本上达到了咱们的预期，初步完成了基础设施和业务的第一步的分离，见证了 Mesh 化以后基础设施的迭代速度。

不论何种架构，软件工程没有银弹。架构设计与方案落地老是一种平衡与取舍，目前还有一些 Gap 须要咱们继续努力，可是咱们相信，云原生是远方也是将来，通过咱们两年的探索和实践，咱们也积累了丰富的经验。

咱们相信，Service Mesh 可能会是云原生下最接近“银弹”的那一颗，将来 Service Mesh 会成为云原生下微服务的标准解决方案，接下来蚂蚁金服将和阿里集团一块儿深度参与到 Istio 社区中去，一块儿和社区把 Istio 打形成 Service Mesh 的事实标准。

今天的分享就到这里，感谢你们。若是有想交流更多的，欢迎参与到社区里来，寻找新技术带来更多业务价值。

SOFAStack：https://github.com/sofastack

本次分享 PPT 以及回顾视频：点击“这里”

蚂蚁金服 Service Mesh 大规模落地系列文章

• 蚂蚁金服 Service Mesh 大规模落地系列-运维篇
• 蚂蚁金服 Service Mesh 大规模落地系列-消息篇
• 蚂蚁金服 Service Mesh 大规模落地系列-核心篇
• Service Mesh 落地负责人亲述：蚂蚁金服双十一四大考题

公众号：金融级分布式架构（Antfin_SOFA）