蚂蚁金服 Service Mesh 深度实践

支付宝技术团队

于 2019-11-06 09:12:22 发布

阅读量2.5k

点赞数 2

分类专栏：蚂蚁技术文章标签：分布式中间件云原生

本文链接：https://blog.youkuaiyun.com/weixin_44326589/article/details/102928587

版权

作者丨敖小剑

2019 年，蚂蚁金服在 Service Mesh 领域继续高歌猛进，进入大规模落地的深水区。本文介绍了 Service Mesh 在蚂蚁金服的落地情况和即将来临的双十一大考，以及大规模落地时遇到的困难和解决方案，助你了解 Service Mesh 的未来发展方向和前景。

一、前言

大家好，我是敖小剑，来自蚂蚁金服中间件团队，今天带来的主题是“诗和远方：蚂蚁金服 Service Mesh 深度实践”。

在过去两年，我先后做过两次 Service Mesh 的演讲：

2017 年，当时 Service Mesh 在国内还属于蛮荒时代，我当时做了一个名为“Service Mesh: 下一代微服务”的演讲，开始在国内布道 Service Mesh 技术；
2018 年，做了名为“长路漫漫踏歌而行：蚂蚁金服 Service Mesh 实践探索”的演讲，介绍蚂蚁金服在 Service Mesh 领域的探索性的实践，当时蚂蚁金服刚开始在 Service Mesh 探索。
今天，有幸第三次，给大家带来的依然是蚂蚁金服在 Service Mesh 领域的实践分享。和去年不同的是，今年蚂蚁金服进入了 Service Mesh 落地的深水区，规模巨大，而且即将迎来双十一大促考验。

备注：现场做了一个调研，了解听众对 Servicve Mesh 的了解程度，结果不太理想：在此之前对 Service Mesh 有了解的同学目测只有 10% 多点（肯定不到 20%）。Service Mesh 的技术布道，依然任重道远。

今天给大家带来的内容主要有三块：

蚂蚁金服落地情况介绍：包括大家最关心的双十一落地情况；
大规模落地的困难和挑战：分享一下我们过去一年中在大规模落地上遇到的问题；
是否采用 Service Mesh 的建议：这个问题经常被人问起，所以借这个机会给出一些中肯的建议供大家参考。

二、蚂蚁金服落地情况介绍

（一）发展历程和落地规模

Service Mesh 技术在蚂蚁金服的落地，先后经历过如下几个阶段：

技术预研阶段：2017 年底开始调研并探索 Service Mesh 技术，并确定为未来发展方向；
技术探索阶段：2018 年初开始用 Golang 开发 Sidecar SOFAMosn，年中开源基于 Istio 的 SOFAMesh；
小规模落地阶段：2018 年开始内部落地，第一批场景是替代 Java 语言之外的其他语言的客户端 SDK，之后开始内部小范围试点；
规模落地阶段：2019 年上半年，作为蚂蚁金融级云原生架构升级的主要内容之一，逐渐铺开到蚂蚁金服内部的业务应用，并平稳支撑了 618 大促；
全面大规模落地阶段：2019 年下半年，在蚂蚁金服内部的业务中全面铺开，落地规模非常庞大，而且准备迎接双十一大促。

目前 ServiceMesh 正在蚂蚁金服内部大面积铺开，我这里给出的数据是前段时间（大概 9 月中）在云栖大会上公布的数据：应用数百个，容器数量（pod 数）超过 10 万。当然目前落地的 pod 数量已经远超过 10 万，这已经是目前全球最大的 Service Mesh 集群，但这仅仅是一个开始，这个集群的规模后续会继续扩大，明年蚂蚁金服会有更多的应用迁移到 Service Mesh。

（二）主要落地场景

目前 Service Mesh 在蚂蚁金服内部大量落地，包括支付宝的部分核心链路，落地的主要场景有：

多语言支持：目前除了支持 Java 之外，还支持 Golang，Python，C++，NodeJS 等语言的相互通信和服务治理；
应用无感知的升级：关于这一点我们后面会有特别的说明；
流量控制：经典的 Istio 精准细粒度流量控制；
RPC 协议支持：和 Istio 不同，我们内部使用的主要是 RPC 协议；
可观测性。

（三）Service Mesh 的实际性能数据

之前和一些朋友、客户交流过，目前在 Service Mesh 方面大家最关心的是 Service Mesh 的性能表现，包括对于这次蚂蚁金服 Service Mesh 上双十一，大家最想看到的也是性能指标。

为什么大家对性能这么关注？

因为在 Service Mesh 工作原理的各种介绍中，都会提到 Service Mesh 是将原来的一次远程调用，改为走 Sidecar（而且像 Istio 是客户端和服务器端两次 Sidecar，如上图所示），这样一次远程调用就会变成三次远程调用，对性能的担忧也就自然而然的产生了：一次远程调用变三次远程调用，性能会下降多少？延迟会增加多少？

下图是我们内部的大促压测数据，对比带 SOFAMosn 和不带 SOFAMosn 的情况（实现相同的功能）。其中 SOFAMosn 是我们蚂蚁金服自行开发的基于 Golang 的 Sidecar/ 数据平面，我们用它替代了 Envoy，在去年的演讲中我有做过详细的介绍。

SOFAMosn：

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

CPU：CPU 使用在峰值情况下增加 8%，均值约增加 2%。在最新的一次压测中，CPU 已经优化到基本持平（低于 1%）；
内存：带 SOFAMosn 的节点比不带 SOFAMosn 的节点内存占用平均多 15M；
延迟：延迟增加平均约 0.2ms。部分场景带 SOFAMosn 比不带 SOFAMosn RT 增加约 5%，但是有部分特殊场景带 SOFAMosn 比不带 SOFAMosn RT 反而降低 7.5%；

这个性能表现，和前面"一次远程调用变三次远程调用"的背景和担忧相比有很大的反差。尤其是上面延迟的这个特殊场景，居然出现带 SOFAMosn（三次远程调用）比不带 SOFAMosn（一次远程调用）延迟反而降低的情况。

是不是感觉不科学？

（四）Service Mesh 的基本思路

我们来快速回顾一下 Service Mesh 实现的基本思路：