MOSN 子项目 Layotto：开启服务网格+应用运行时新篇章

作者简介：

马振军，花名古今，在基础架构领域耕耘多年，对 Service Mesh 有深度实践经验，目前在蚂蚁集团中间件团队负责 MOSN、Layotto 等项目的开发工作。

Layotto 官方 GitHub 地址:

https://github.com/mosn/layotto

点击最下方“阅读原文”即可观看现场视频

Service Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。

在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。

一、Service Mesh 回顾与总结

A、Service Mesh 的初衷

在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。

伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大，生产环境同时跑着各种版本的 SDK，这种现象又会让新功能的迭代必须考虑各种兼容，就好像带着枷锁前进一般，这样随着不断迭代，会让代码维护非常困难，有些祖传逻辑更是一不小心就会掉坑里。

同时这种“重”SDK 的开发模式，导致异构语言的治理能力非常薄弱，如果想为各种编程语言都提供一个功能完整且能持续迭代的 SDK 其中的成本可想而知。

18 年的时候，Service Mesh 在国内持续火爆，这种架构理念旨在把服务治理能力跟业务解耦，让两者通过进程级别的通信方式进行交互。在这种架构模式下，服务治理能力从应用中剥离，运行在独立的进程中，迭代升级跟业务进程无关，这就可以让各种服务治理能力快速迭代，并且由于升级成本低，因此每个版本都可以全部升级，解决了历史包袱问题，同时 SDK 变“轻”直接降低了异构语言的治理门槛，再也不用为需要给各个语言开发相同服务治理能力的 SDK 头疼了。

B、Service Mesh 落地现状

蚂蚁很快意识到了 Service Mesh 的价值，全力投入到这个方向，用 Go 语言开发了 MOSN 这样可以对标 envoy 的优秀数据面，全权负责服务路由，负载均衡，熔断限流等能力的建设，大大加快了公司内部落地 Service Mesh 的进度。

现在 MOSN 在蚂蚁内部已经覆盖了数千个应用、数十万容器，新创建的应用默认接入 MOSN，形成闭环。而且在大家最关心的资源占用、性能损耗方面 MOSN 也交出了一份让人满意的答卷：

1.  RT 小于 0.2ms

2.  CPU 占用增加 0%~2%

3.  内存消耗增长小于 15M

由于 Service Mesh 降低了异构语言的服务治理门槛，NodeJS、C++等异构技术栈也在持续接入到 MOSN 中。

在看到 RPC 能力 Mesh 化带来的巨大收益之后，蚂蚁内部还把 MQ，Cache，Config 等中间件能力都进行了 Mesh 化改造，下沉到 MOSN，提高了中间件产品整体的迭代效率。

C、新的挑战

1. 应用跟基础设施强绑定

一个现代分布式应用，往往会同时依赖 RPC、Cache、MQ、Config 等各种分布式能力来完成业务逻辑的处理。

当初看到 RPC 下沉的红利以后，其他各种能力也都快速下沉。初期，大家都会以自己最熟悉的方式来开发，这就导致没有统一的规划管理，如上图所示，应用依赖了各种基础设施的 SDK，而每种 SDK 又以自己特有的方式跟 MOSN 进行交互，使用的往往都是由原生基础设施提供的私有协议，这直接导致了复杂的中间件能力虽然下沉，但应用本质上还是被绑定到了基础设施，比如想把缓存从 Redis 迁移到 Memcache 的话，仍旧需要业务方升级 SDK，这种问题在应用上云的大趋势下表现的更为突出，试想一下，如果一个应用要部署在云上，由于该应用依赖了各种基础设施，势必要先把整个基础设施搬到云上才能让应用顺利部署，这其中的成本可想而知。

因此如何让应用跟基础设施解绑，使其具备可移植能力，能够无感知跨平台部署是我们面临的第一个问题。

2. 异构语言接入成本高