干货 | 蚂蚁金服是如何实现经典服务化架构往 Service Mesh 方向的演进的？

摘要： 小蚂蚁说： 蚂蚁金服在服务化上面已经通过多年的沉淀，支撑了每一年双十一的高峰峰值。Service Mesh 做为微服务的一个新方向，在最近两年成为领域的一个大热点，可是如何从经典服务化架构往 Service Mesh 的方向上演进，中间可能会遇到什么样的问题，几乎没有能够借鉴的经验。

小蚂蚁说：

蚂蚁金服在服务化上面已经通过多年的沉淀，支撑了每一年双十一的高峰峰值。Service Mesh 做为微服务的一个新方向，在最近两年成为领域的一个大热点，可是如何从经典服务化架构往 Service Mesh 的方向上演进，中间可能会遇到什么样的问题，几乎没有能够借鉴的经验。

本文会给你们分享 Service Mesh 在蚂蚁金服的演进历程和在2018年6月举办的 GIAC 全球互联网架构大会中蚂蚁金服高级技术专家与现场人员关于Service Mesh的热门QA互动。

前言

在过去的一段时间中蚂蚁金服已经开始采用 Service Mesh 来帮助解决一些架构上的问题，而且在 Service Mesh 如何更好地与经典的服务化架构结合上有必定的经验，但愿借此分享和你们交流咱们这部分的实践。使你们对蚂蚁金服当前的服务化架构有更多了解，并对 Service Mesh 如何解决经典服务化架构中的问题以及蚂蚁金服实际在落地Service Mesh 中的时候的一些设计考虑和将来展望有更进一步的了解，也但愿能与行业分享蚂蚁金服服务化架构现状。

蚂蚁金服从单体应用转移到服务化的架构下已经通过了差很少 10 年的时间，在整个过程当中，为了知足蚂蚁金服金融级的要求，咱们也构建了一整套地面向金融级的分布式架构的解决方案，也就是 SOFA。

SOFA 其实包含了金融级分布式中间件，CICD 以及 PAAS 平台。SOFA中间件部分包含的内容包括 SOFABoot 研发框架、SOFA微服务相关的框架（RPC，服务注册中心，批处理框架，动态配置等等）、消息中间件、分布式事务和分布式数据访问等等中间件。

以上的这些中间件都是基于 Java 技术栈的，目前 SOFA 在蚂蚁金服内部大概超过 90% 的系统在使用，除了这些系统以外，还有剩下的 10% 的系统，采用 NodeJS，C++，Python 等等技术栈研发的。这剩下的 10% 的系统想要融入到 SOFA 的整个体系中，一种办法是用对应的语言再去写一遍 SOFA 中间件的各个部分对应的客户端。

事实上，以前咱们正是这么干的，蚂蚁金服内部以前就有一套用 NodeJS 搞的 SOFA 各个组件的客户端，可是最近几年随着 AI 等领域的兴起，C++ 也在蚂蚁金服内部也在被应用到愈来愈多的地方，那么咱们是否也要用 C++ 再来写一遍 SOFA 中间件的各个客户端？若是咱们继续采用这种方式去支持 C++ 的系统，首先会遇到成本上的问题，每一个语言一套中间件的客户端，这些中间件的客户端就像一个个烟囱，都须要独立地去维护，去升级。另外一方面，从稳定性上来说，以前 Java 的客户端踩过的一些坑，可能其余的语言又得从新再踩一遍坑。

对于多语言的问题来讲，Service Mesh 其实就很好地解决了这部分的问题，经过 Service Mesh的方案，咱们能够尽可能把最多的功能从中间件的客户端中移到 Sidecar 中，这样就能够作到一次实现，就搞定掉全部语言，这个对于基础设施团队来讲，在成本和稳定性上都是一个提高。

另外的一个问题实际上是全部在往云原生架构中转型的公司都会遇到的问题，云原生看起来很是美好，可是咱们怎么渐进式的演进到云原生的架构下？特别是对于遗留系统，到底怎么作比较好。固然，一种简单粗暴的方式就是直接用云原生的设施和架构从新写一套，可是这样，投入的成本就很是高，并且重写就意味着可能会引入 Bug，致使线上的稳定性的问题。那么有没有一种方式可让这些遗留系统很是便捷地享受到云原生带来的好处呢？Service Mesh 其实为咱们指明了一个方向，经过 Service Mesh，咱们为遗留系统安上一个 Sidecar，少许地修改遗留系统的配置甚至不用修改遗留系统的配置就可让遗留系统享受到服务发现，限流熔断，故障注入等等能力。

最后咱们在蚂蚁金服的服务化的过程当中遇到的问题是中间件升级的问题，蚂蚁金融从单体应用演进到服务化的架构，再演进到单元化的架构，再演进到弹性架构，其实伴随了大量中间件升级，每次升级，中间件不用说要出新的版本去提供新的能力，业务系统也须要升级依赖的中间件，这中间再出个 Bug，又得从新升级一遍，不光是中间件研发同窗痛苦，应用的研发同窗也很是痛苦。

咱们从单体应用演进到了服务化的架构，从原来好几个团队维护同一个应用，到各个团队去维护各自领域的应用，团队之间经过接口去沟通，已经将各个业务团队之间作到了最大程度的解耦，可是对于基础设施团队来讲，仍是和每个业务团队耦合在一块儿。

咱们中间尝试过用各类方法去解决升级过程当中的耦合的问题，一种是经过咱们本身研发的应用服务器 CloudEngine 来管理全部的基础类库，尽可能地去减小给用户带来的升级成本，不用让用户一个个升级依赖，一次升级就能够。

可是随着蚂蚁的业务的不断发展，规模地不断扩大，团队的数量，业务的规模和咱们交付的效率已经成为了主要的矛盾，因此咱们指望以更高的效率去研发基础设施，而不但愿基础设施的迭代受制于这个规模。

后来蚂蚁本身研发的数据库 OceanBase 也在用一个 Proxy 的方式来屏蔽掉 OceanBase 自己的集群负载，FailOver切换等方面的逻辑，而恰好 Service Mesh 的这种 Sidecar 的模式也是这样的一个思路，这让咱们看到将基础设施的能力从应用中下移到 Sidecar 这件事情是一个业界的总体的趋势和方向，经过这种方式应用和中间件的基础设施今后成了两个进程，咱们能够针对中间件的基础设施进行单独的升级，而不用和应用的发布升级绑定在一块儿，这不只解放了应用研发和基础设施团队，也让基础设施团队的交付能力变地更强，之前可能须要经过半年或者一年甚至更长时间的折腾，才可以将基础设施团队提供的新的能力铺到全部的业务系统中去，如今咱们经过一个月的时间，就能够将新能力让全部的业务系统享受到。这也让基础设施团队的中台能力变得更强了。这样咱们就能够把咱们仍是把一些架构当中很是关键的支撑点以及一些逻辑下沉到 Sidecar上面去，由于整个蚂蚁金服的总体架构有很是多的逻辑和能力承载在这一套架构上面的。这些东西咱们有一个最大的职责是要支撑它快速向前演进和灵活。

Service Mesh 的选型

前面讲到了蚂蚁金服当前服务化架构下遇到的问题以及咱们但愿可以经过 Service Mesh 可以去解决的一些问题，接下来就面临一个很现实的问题，Service Mesh 的框架咱们到底应该怎么选，咱们应该用什么样的标准去衡量，那接下来，我就给你们分享一下蚂蚁金服在Service Mesh 的框架上的选型上的一些思考。

首先，全部的架构的演进都不是一蹴而就的，都是一个渐进式地演进的一个过程，越大的公司在架构演进的过程当中其实越须要考虑这一点。因此咱们在选型的时候就须要去考虑这一点，考虑目标框架可否很好地和当前的架构融合在一块儿。另外一个点，做为一个和钱打交道的公司，咱们须要特别地去关注目标框架是否在生产环境通过大规模的验证，在场景上，是否通过了各种场景的验证。

目前，业界主流的 Service Mesh 相关的框架有三个，分别是 Google，IBM，Lyft都参与其中的 Istio，以及 Bouyant 公司下的两个开源的 Service Mesh 的框架 Linkerd 以及 Conduit。

首先咱们来看下 Istio，Istio 应该是目前被关注最高的一个 ServiceMesh 框架，自己又有顶尖公司的光环加持，好比 Google，IBM 等等，他也完整地包含了一个 Data Plane 以及 Control Plane，可是Istio 一直以来被挑战的地方其实在于他的 Control Plane 的 Mixer 的部分，Istio 的 Mixer 承担了服务鉴权，Quota 控制，Tracing，Metrics等等能力，它是一个中央的节点，若是不开启缓存的状况下，全部的调用都须要从 Mixer 中去过，即便开启了缓存的状况，也不可避免的有请求必定要从 Mixer 中去过，而在全蚂蚁，有20000 多的服务，服务之间的调用是很是频繁的，若是都须要过 Mixer，那 Mixer 就成了一个单点，这个单点的运维和高可用又成了一个问题。

另外，Istio 的性能是咱们一直以来比较担忧的问题，虽然 Istio 每一个版本的发布，性能都有了必定程度的提高。可是咱们来看下 Istio 的性能数据，0.5.1 的时候是 700 的 TPS，0.6.0 的时候是 1000 个 TPS，0.7.1 的时候是 1700 个 TPS，相对于通常的RPC 通讯框架，最低最低都是万级别的 TPS，Istio 的这个性能数据的确是有点儿惨淡，彻底没法知足蚂蚁这边的性能要求。

接下来咱们来看 Linkerd，Linkerd 算是业界几个 Service Mesh的框架里面最成熟的一个了，可是他也有一个问题，首先就是他脱胎于 Twitter 的 Finagle，架构上其实不够开放，无法很好的适配到蚂蚁的环境里面去，另外Linkerd 也没有 Control Plane 这一层，只有 Sidecar，再者 Linkerd 的路由规则 DTab 实际上是挺难理解的。最后，其实也是咱们当时选型的时候最关心的一个问题，Linkerd是用 Scala 写的，跑在 JVM 上面，我从 Linkerd 的一篇博客上摘录出了一张图片，这篇博客主要讲的是如何优化 JVM 的内存使用，这种文章通常上是的确有这个问题，才会去写这样的文章，从这张图片中咱们能够看到 Linkerd 所须要的内存至少都须要 100M，这也是 Bouyant 官方不推荐 Linkerd 和应用作一对一的部署，而是采用 DaemonSet 的方式进行部署。而咱们指望的一个部署方式是和应用作一对一的部署，这样的内存占用对于咱们来讲成本太过，咱们指望将 Sidecar 的内存占用控制在 10M 左右。

最后，咱们来看下 Conduit，首先 Conduit 也是 Linkerd 不久以前推出的一个Service Mesh 的框架，其实不太成熟，其次，Conduit 选择的语言是 Rust，咱们来看下 Rust 在 Tiebo 上的排名，Java 长时间高居第一位，C++在第三位，Golang 通过这几年云基础设施的蓬勃发展，到了 14 位，而 Rust，和一众语言的占用率没有太大的差异，排在了 50 位日后。

因此，咱们最后选择了自研 Service Mesh，一方面固然是咱们基于前面的两个准则去衡量目前业界流行的Service Mesh 框架，没有可以彻底知足咱们的要求的，另外一方面蚂蚁金服服务化上有长期以及深厚的积累，这部分的一些经验也能够支持咱们可以更好地去自研咱们本身的Service Mesh 的框架。

固然，咱们也不是说彻底从零开始搞 Service Mesh 框架，对于业界的Service Mesh 的框架中的优秀理念，咱们是但愿可以吸取过来的，另外一方面，咱们也但愿可以尽可能地去 Follow Service Mesh 目前社区中的一些规范。

SOFA Mesh 的设计

首先，SOFA Mesh 其实直接采用了 Istio 的 Control Plane 的Pilot 和 Auth，由于咱们以为 Istio 在这块上没有太大的问题甚至里面也有一些很是不错的设计，好比Pilot 这部分的 Universal Data API 就是很是不错的设计。Istio 的 Auth 这部分也充分地利用了 Kubernetes 的安全机制。

而Mixer 这部分，其实我以前就提到咱们是以为有设计上问题的，因此咱们的想法是直接把 Mixer 搬到 Sidecar 中实现。

再者，你们都知道 Istio 的 Sidecar 是 Envoy，它是一个用 C++ 写的，那么咱们怎么把Mixer 移入到 Sidecar 中去呢，其实咱们的 SOFA Mesh 的 Sidecar 是采用了 Golang 来写的，因此才给把 Mixer 移入Sidecar 提供了可能性，固然，咱们选择用 Golang 来研发 Sidecar 不只仅是为了把 Mixer 移入到 Sidecar 而已，其实也有其余的考虑，一方面，在云计算的时代，Golang以及成为构建基础设施的首选语言，咱们看到大量的基础设施都是用 Golang 写的，包括 Docker，Kubernetes 等等，选择 Golang，其实也是但愿可以更好地和云原生时代的这些基础设施贴合。

另外，相比于 Envoy 采用的 C++，Golang 显然更加容易上手，也更加容易找到这方面的人才，另外，Golang相对于 JVM 来讲，Memory Footprint 低了很是多，咱们用 Golang 写的 Sidecar，目前的峰值 TPS 下的内存在用在 11M，虽然还有必定的优化空间，可是相比于 JVM 来讲，已经下降了10 倍。

另外，虽然咱们采用了 Istio 的 Pilot，可是在内部使用的时候，直接使用Pilot 并不能知足咱们的诉求。首先，Pilot 在 Kubernetes 上是直接对接到 Kubernetes 的服务发现机制上的，不管是 SOFARPC，仍是微博的Motan 等等国内的服务框架，其实都是单个应用多个服务这样的模型，而 Kubernetes 的服务发现机制实际上针对的是单个应用单个服务的模型，在模型上就不太一致。另外，SOFA的服务注册中心 SOFARegistry 在蚂蚁金服内部通过了多年的实践，面对内部大规模的服务化的场景，SOFARegistry 的扩展能力以及可靠性已经通过了大量的实践证实，这里说一下SOFARegistry 上的一些数据，上面大约注册了 2W 多个服务，一个机房里面的 Pub 和 Sub 的加起来在千万级别。基于以上的考虑，咱们选择了用Pilot 上增长 SOFARegistry 的 Adapter，使之可以拿到 SOFARegistry 上的服务注册信息。

而后，Pilot 还有一个问题，就是原来 Pilot 会把全部的服务注册相关的数据都同步到Pilot 上，这个对于 Pilot 的集群的压力是很是大的，因此咱们选择了只同步必要的数据到一个 Pilot 的节点上，介绍 Pilot 自己的内存压力。

最后，我再分享一个蚂蚁金服的场景，在蚂蚁金服，由于事业部众多以及监管的问题，不用的事业部之间的一些机器多是网络不通的，那么他们要作服务访问，就必须有一个角色来作跨环境之间的服务访问，因此咱们基于 Sidecar 的概念，提出了 EdgeSidecar 的角色，他在技术的实现细节上其实和和应用部署在一块儿的 Sidecar 是很是相似的，只是这个 Sidecar 做为一个“边缘”的角色，来负责跨环境的服务通讯问题。

因此，SOFA Mesh 在总体的大图上大概是这样的，咱们自研了一个 Golang 的Sidecar，而且把 Mixer 归入到 Sidecar 中，来防止出现相似于 Istio 那样的性能问题，在 Pilot 和 Auth 这两个角色了，咱们选择直接使用Istio 的，而后在上面作必定程度的适配，适配到蚂蚁内部的环境中，而后咱们在整个部署上，新增了一个 EdgeSidecar 的角色，来解决跨环境的服务调用的问题。

我知道你们必定对 SOFA Mesh 在蚂蚁内部的落地状况很是感兴趣，目前咱们已经落地的场景主要是多语言的场景，解决其余的语言和 SOFA 的通讯问题，大约上了二三十个系统。而后咱们正在尝试用 SOFA Mesh 去更好地解决服务间调用的安全，以及蓝绿发布的问题，在异构系统通讯的这件事情上，咱们也在不久的未来会尝试用 SOFA Mesh 去解决。

固然，SOFA Mesh 在蚂蚁内部的落地其实离不开开源社区，因此在将来的两三个月内，咱们也会将 SOFA Mesh 开源出来，将蚂蚁内部实践 Service Mesh 的成果开源出来，给你们更多在这方面的参考。

对于将来，其实我以为中间件做为基础设施将来和云平台融合是一个不可阻挡地趋势，除了 Service Mesh，将来还可能会出现 Message Mesh，DB Mesh 等等产品，我知道业界有些同窗已经开始作这方面的努力了。最后总结一下我今天演讲的内容，一个是 Service Mesh 给蚂蚁金服解决的问题，包括多语言，遗留系统以及基础设施团队和业务团队耦合的问题。在 ServiceMesh 的选型上，咱们主要考量和当前架构的可融合性，以及框架的高可用，稳定性。将来除了 ServiceMesh，可能还会出现其余的 Mesh，中间件和底层云平台进一步融合的趋势不可挡。多谢你们！

下面带来的是GIAC大会中蚂蚁金服高级技术专家与现场参会人员进行关于Service Mesh的问答互动，咱们精选了几个比较热门的问答分享给你们。

1、Mesh的高可用和安全，可否详细说明一下？

答：咱们最近正在作安全这件事情，安全涉及到两个方面，一个方面是 RPC 的整个服务调用健全的问题，这个是能够直接在 Mesh 中去作的，能够直接利用 Istio 的 RBAC 来实现，另外是 Mesh 和 Mesh 之间的 TLS双向认证的事情。这个其实 Istio 里面会有一些现成的方案，它与 K8S 融合的也很是好，这些东西是能够直接拿过来去用的。

2、如何解决服务的多版本路由和数据单元的多版本路由的问题？

答：ServiceMesh 主要关注的是服务调用这一块，我来解释一下多版本的路由，其实咱们在内部的话，服务版本这件事情用得会比较少，用得更多的是同一服务不一样的实现。可是其实多版本路由这一块，若是说你们知道 K8S 的 Label 的话，能够把它的这种设计来借鉴到整个Mesh当中，而后经过不一样的标签来作区分，后面也会有一些这方面的分享出来。

3、Service Mesh 主要是解决了请求的可靠传输和服务治理的问题吗？

答：应该是说Service Mesh提出了更好的方式去解决请求的可靠传输和服务治理的问题。其实想像一下，若是说你要上一整套的服务治理的架构的话，在原来的方式下可能须要大家全部的上层业务系统都接入大家对应的服务治理的组件，如今的话，只要有一个Service Mesh，在这个 Sidecar 当中就能够把服务治理的这件事情作掉。它没有去解决新的问题，只是把一些老的问题用更好的方式去解决。

4、为何Control Plane对于Mesh来讲很重要？

答：其实这个就涉及到整个云平台和咱们整个服务化体系的融合的问题。其实目前你们能够看到，Pilot 这部分的东西，在原来 Istio 设计当中是很是强的和 K8S 这个东西融合在一块儿的，若是说你没有这套东西存在的话，对于 Mesh 来讲仍是一个很是上层的中间件这样的东西。固然你能够说不用 Control Plane 这一层，只有 Sidecar，对接到原来的一整套的服务治理体系当中去，这样作也是能够的，没有太大的问题。可是有了 Control Plane 这一层东西，它定义了很是通用的 API，自己这个架构又是和云平台整个架构是绑定得比较紧的，有更好的融合度。因此咱们以为整个Control Plane这一层是很是重要的。

另外，Istio 提出 Control Plane，实际上是在往微服务标准化方面迈进了很大一层。它里面有很是多的服务发现的标准，治理的标准，虽说他大胆提出了这样的概念和假设，咱们也看到了它的一些不足，因此咱们但愿和社区一块儿推动这一层的标准化。就像我一开始分享的，基础设施一层一层的向上包。像咱们以为愈来愈多的中间件的部分，实际上是会被沉淀到基础设施当中的。如今也有云原生语言，咱们编译了一下，发现很慢，问题也不少，可是咱们以为这是一个方向。你们在写的时候，可能就用这样的语言去写，不少能力就提高上去了。咱们但愿把基础设施向上再推一下，去扮演这样一个角色。这也是咱们认为 Control Plane 的最大的价值。

本文做者：兔子酱
阅读原文本文为云栖社区原创内容，未经容许不得转载。