云原生网络代理（MOSN）的进化之路

本文系云原生应用最佳实践杭州站活动演讲稿整理。杭州站活动邀请了 Apache APISIX 项目 VP 温铭、又拍云平台开发部高级工程师莫红波、蚂蚁金服技术专家王发康、有赞中间件开发工程师张超，分享云原生落地应用的经验心得，以下是王发康《云原生网络代理（MOSN）的进化之路》分享内容。

王发康（毅松），蚂蚁金服可信原生技术部技术专家，专注于高性能网络服务器研发，MOSN、Tengine 开源项目核心成员，目前关注云原生 ServiceMesh、Nginx、Istio等相关领域。

今天主要分享 MOSN 在蚂蚁金服的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，其在演进过程中遇到的问题及思考，我从以下三方面展开：

MOSN 介绍
云原生演进
总结与展望

MOSN 介绍

我先从 MOSN 的诞生背景、MOSN 在蚂蚁集团的发展历程、MOSN 的架构解析和落地情况等维度向大家介绍 MOSN。

MOSN 诞生背景

说到 Service Mesh 为什么会出现，我们需要先回顾服务演进历程，大体经历如下阶段：

单体服务：早期网站小、流量少，业务简单，可在同一个服务中完成所有部署；

分布式：当用户达到一定规模且日益增长，需要进行服务拆分；

微服务：随着服务数量的持续增加，出现了服务治理的需求，如限流、鉴权、熔断等，于是一些治理组件便被以 SDK 插件的形式集成到不同的应用中；

Service Mesh：由于服务治理的 SDK 多语言、中间件组件开发适配成本高，以及其本身较弱的服务治理能力，开始尝试将 SDK 和业务剥离，解耦出一个单独的 Sidecar，从而解决多语言开发、业务迭代等难题。

总的来看，业务侧有如下痛点：

多语言，中间件组件开发适配成本高
SDK 升级困难
服务治理能力弱
技术不通用，无法复用

现有业界方案：

Envoy (C++)
Linkerd (活跃度较低)
NginxMesh (活跃度低)

基于上述业务的痛点以及对业界相应的解决方案评估过后，最终我们决定自主研发 MOSN。MOSN（ModularOpen Smart Network）是用 GoLang 语言开发的网络代理软件，作为云原生的网络数据平面，旨在为服务提供多协议、模块化、智能化、安全的代理能力。

MOSN 发展历程

MOSN 从 2017 年 12 月开始 Service Mesh 技术调研，到产品孵化，历经重重困难，最终通过 2019 年双 11 规模化验证，实现蚂蚁集团核心支付链路覆盖。MOSN 在内部落地后，我们认为借力开源也要反哺开源，因此着手进行 CloudNative 生态融合，和业界多种开源标准组件联合走标准化道路，从而实现共享并最大化的释放其技术红利。

下图为 MOSN 全局功能视图，作为网络数据平面，MOSN 如今已具备支持路由、负载均衡、多协议等多功能，另外也包括可观察性和 Admin 管理等。

MOSN 架构解析

MOSN 整体框架采用分而治之的架构思想，如图所示 MOSN 整个架构共分四层：

-Network：最底层是网络层，负责接收数据包，Listener_filter（original_dst）、network_filter（tcp、faultinject）

Protocol：多协议层（HTTP 系、SOFARPC、Dubbo），提供自定义协议能力（Xprotocol）
Stream：Stream_filter(health_check、faultinject)
Proxy：提供 proxy 框架（分阶段处理、router、loadbalancer、connection pool）

每一层通过工厂设计模式向外暴露其接口，方便用户灵活的注册自身的需求，采用协程池的方式使得用户以同步的编码风格就可以实现异步功能特性。鉴于 MOSN 使用 GoLang 语言，支持用同步的方式表达异步的动作，因而 MOSN 较为容易的实现了 read 和 proxy 两大类协程，具体流程见 MOSN 的协程池模式示意图：

通过上述框架设计，MOSN 竞争优势大大提高，其核心能力如下：

热生效：配置热生效（xDS）；二进制平滑升级（连接迁移）是核心竞争优势
多协议（Xprotocol）：支持 HTTP 系、SOFARPC、Dubbo
流量管理及路由：headers/uri 分流；连接池、健康检查、熔断保护、故障注入；TLS/国密
转发能力：四层及七层；SWRR、Random、EDF、Maglev etc
可观察性：连接、请求、流量

MOSN 内存&连接池

MOSN 为了降低 Runtime GC 带来的卡顿，自身做了内存池的封装，方便多种对象高效的复用内存。为了提升服务网格之间的建连能力，我们设计封装了多种协议的连接池，方便的实现连接复用及管理。

MOSN 落地情况

2019 年 MOSN 已经经过双 11 规模化验证，实现蚂蚁集团核心支付链路全覆盖，效果惊人。当然大家可能会有疑问，引入 Service Mesh 后比以前的链路多一条，会不会产生新的开销？答案是不一定。MOSN 在落地实现的过程中将 SDK 的业务逻辑复制到 MOSN，相当于从左手倒到右手，同时还进行了优化。事实上我们当时还发现有些业务引入 Service Mesh 之后，内存消耗更少。

云原生演进

前面我们了解了 MOSN 在蚂蚁集团数据面落地的情况，我们其实一直有一个小梦想——希望更多人使用 MOSN ，所以我们做了标准化云原生演进，打通周边的生态合作，下面详细展开。

Could Native Arch

如下图所示，在整个云原生架构中，最下层是基础设施（包含硬件、网络资源、机房等），上一层是基于硬件抽象出的 Kubernetes 进行容器资源的调度管理，再上面一层是 Service Mesh、Serverless ，Istio 在这一层发挥功能，而 MOSN 相当于是在 Istio 里扮演数据面的角色。

Istio 简介

任何一项技术都是伴随业务痛点诞生的，在介绍 Istio 之前我们也来看一下为什么 Istio 会出现。最早的时候都是物理机管理资源，之后由于微服务拆分出现了 Docker，但任何一项技术解决一个问题，肯定又会带来新的问题，当然新的问题会加速新技术出现，所以 Docker 之后诞生了 Kubernetes 。Kubernetes 完美解决了 Docker 的管理、调度、编排等问题，但也只管理了机器资源。作为写业务的人，我们也期望应用能够进行微服务治理，于是 Istio 应运而生了。

Istio 具有服务互连、流量安全、流量控制、可观测性等功能，它的出现弥补了 Kubernetes 在服务治理上的短板，二者可以紧密合作，充分发挥其功能优势，从而实现微服务网格管理。

MOSN with Istio

经过 MOSN 社区近几个月的不断努力，MOSN 已经成功适配 Istio。7 月 28 日 Istio 官方发表了本人署名的文章《Istio 数据平面的另一个选择 —— MOSN》，说明 MOSN 是可以作为数据面被选择使用的，感兴趣可以点击查看 https://istio.io/latest/blog/...。在 Service Mesh 领域，使用Istio 作为控制平面已成为主流，如下图所示可以看出在 Istio 的架构中，我们是将 MOSN 作为 Istio 的数据面，通过借助 Istio 实现服务治理。

成为云原生标准 Sidecar 是我们为 MOSN 定的目标，为此我们成立了 Istio、MOSN、Dubbo 相关的 Working Group，让社区更多的开发工作人员参与进来。

下图展示了 MOSN 适配 Istio 整个功能列表，值得一提的是相当多的功能都是外部开发者贡献的。

目前 MOSN 已经适配了 Istio1.5.X 版本，可以引入其进行服务治理。不过使用前我们可以先了解下 Istio 中的 Virtual Service 是如何映射到 MOSN 的 router 配置项的。如下图所示，Istio 的 Virtual Service 基于请求 Header 路由，MOSN 通过 xDS 协议从 Istio 获取到对应的资源进行相关配置的转换，然后当 MOSN 真正的接收到业务请求后，对请求进行 Header 匹配，做对应的路由转发处理。

在初步适配 Istio 之后，我们也进行了 Bookinfo 实例测试。如图是一个经典的多语言服务案例，早期没有 Service Mesh，需要用到 SDK 多语言来写，开发成本高、升级难度大。但当通过 Istio 做服务管理后，MOSN（图中棕色区域）不仅可以做 Ingress Gateway，还可作为 Sidecar，有效解决此前技术痛点。

事实上在通过 MOSN 作为 Istio 的数据平面运行 Bookinfo 实例后，目前已实现下列多项服务治理通用能力：

按 version 路由能力
按照权重路由能力
按照特定 header 路由能力
故障注入能力
服务熔断自护能力
透明劫持能力
超时重试机制
etc

大家如果感兴趣可以通过演示教程《MOSN withIstio》 https://www.katacoda.com/mosn... 进一步了解。

开源生态建设

在实现 MOSN 适配 Istio 后，我们并未拘泥于 Istio，而是和社区的很多项目进行沟通合作，例如 Dubbo、Sentinel、Skywalking。

MOSN with Dubbo

MOSN 可以解决 Kubernetes 体系和非 Kubernetes体系下的 Dubbo 服务治理难题。如图中所示，方案 1 中非 Kubernetes 体系服务治理场景中，可以引入 MOSN 集成 Dubbo-go 支持 pub/sub，复用原有的服务注册中心实现治理；方案 2 则是针对服务体系已 Kubernetes 化场景，通过支持 Dubbo 在 Istio下的路由，从而实现其服务治理。

MOSN with Sentinel

限流是服务治理中重要功能之一，而 Sentinel 是阿里巴巴开源的限流组件，经历过双十一大促考验，所以我们选择通过 MOSN 集成 Sentinel 复用其底层的限流能力，实现单机限流（令牌桶/漏桶结合）、服务熔断保护（服务成功率）、自适应限流（依据机器负载）等功能。下一步我们将丰富限流算法，结合 Istio 联手 UDPA 制定新规则。

MOSN with Skywalking

调用依赖以及服务与服务之的调用状态是微服务管理中一个重指标，MOSN 通过和 Skywalking 合作，集成 Skywalking 底层的 SDK，实现调用链路拓扑展示、QPS 监控、细粒度 RT 展示。未来，我们也会朝着 Dubbo Tracing 支持方向持续演进。

标准化演进

除了开源生态适配外，MOSN 也在尝试标准化。大家都知道「标准」和「规范」很重要，例如谷歌提议 UDPA 规范，在数据面之上的一层标准 API 解耦控制面和数据面通信；而微软则提出 ServiceMesh Interface，在控制面之上的一层标准 API 解耦控制面和上层应用/工具，这些规范的背后都是为了遵守“防止锁定，可方便用户灵活切换”原则。

因此在 MOSN 在适配 Istio 以及 Dubbo、Skywalking 等组件后，我们认为不仅要适配别人，也要标准，这需要我们关注并积极参与开源社区建设。事实上在适配 Istio 的过程中，我们已经在和 Istio 官方沟通，既参与 Istio 的开发，也参与了 UDPA 讨论及标准制定。

而在综合 MOSN 和 Istio 官方的讨论后，MOSN 社区主导并会参与 Istio 中数据面解耦的事情（比如测试集、镜像构建等），这样让 Istio 先变得更容易集成第三方的数据面，即 MOSN 社区的用户更方便的集成 Istio 使用。MOSN with Istio 适配的 Roadmap 中新增如下事项：

推动 Istio 的镜像构建和数据面解耦
推动 Istio 的测试框架和数据面解耦

就第一个问题，我们向 Istio 社区贡献 PR，帮助 Istio 数据面和控制面的镜像构建实现解耦，使其更容易集成第三方的数据面。而在 7 月 14 号 Istio TOC（Istio 技术委员会）成员 @Shriram Rajagopalan 也回复我们“也是支持 Istio 中支持多数据面的方案，而且也建议先把 MOSN 做为实验性第三方数据平面纳入到 Istio 的官方博客中，方便用户来试用”，这说明 MOSN 已经充分得到 Istio 官方认可。

在标准化演进过程中，我们和 Istio 官方商议，提出基于 UDPA 领域制定规范的建议：