本文为杭州站云原生应用最佳实践演讲笔记整理。杭州站活动邀请了项目VP文明、有拍云平台开发部高级工程师莫洪波、蚂蚁金服技术专家王发康、有赞中间件开发工程师张超分享云原生落地经验。以下为王发康分享《云原生网络代理（MOSN）的演进》内容。

王发康（易松）是蚂蚁金服可信原生技术部的技术专家。主要从事高性能网络服务器的研发。他是 MOSN 和开源项目的核心成员。目前专注于云原生、云原生等相关领域。

今天我主要跟大家分享一下MOSN在演进过程中遇到的问题和思考，MOSN是在蚂蚁金服Mesh大规模落地之后，通过连接UDPA来构建的数据平面之一。我将从以下三个方面入手：

MOSN简介

我首先从MOSN诞生的背景、MOSN在蚂蚁集团的发展历史、MOSN的架构分析和实现等多个维度向大家介绍一下MOSN。

MOSN诞生背景

说起Mesh为什么出现，我们首先需要回顾一下服务的演进过程，一般会经历以下几个阶段：

单一服务：早期网站规模小，流量小，业务简单，所有部署都可以在同一个服务中完成；

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

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

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

总体来说，业务方有以下痛点：

现有行业解决方案：

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

MOSN发展历程

MOSN于2017年12月开始Mesh技术研究并进行产品孵化。历经重重困难，终于通过了2019年双11的大规模验证，实现了蚂蚁集团核心支付环节的覆盖。 MOSN在中国推出后，我们认为在利用开源的同时，也应该反哺开源，因此我们走上了生态融合之路，与业界各种开源标准组件共同走标准化的道路，从而实现共享并最大限度释放其技术红利。

△ MOSN 在整个蚂蚁集团的发展历程

下图展示了MOSN的全局功能视图。 MOSN作为网络数据平面，目前具备支持路由、负载均衡、多协议、可观测、可管理等多种功能。

△MOSN全局功能视图

MOSN架构分析

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

△MOSN架构图

每层通过工厂设计模式将其接口暴露给外部，方便用户灵活注册自己的需求。协程池用于使用户能够以同步编码风格实现异步功能特性。由于 MOSN 使用语言并支持以同步方式表达异步动作，因此 MOSN 可以轻松实现读取和两大类型的协程。具体流程参见MOSN的协程池模式示意图：

△MOSN协程架构图

通过上述框架设计，MOSN的竞争优势得到了极大的提升。其核心能力如下：

MOSN 内存和连接池

为了减少GC带来的滞后，MOSN封装了自己的内存池，以方便多个对象高效地复用内存。为了提高服务网格之间的连接建立能力，我们设计了一个连接池，封装了多种协议，方便连接复用和管理。

MOSN实施状况

△ 2019年MOSN实施对蚂蚁的影响

2019年，MOSN在双11期间得到大规模验证，实现了蚂蚁集团核心支付环节的全覆盖，效果惊人。当然，您可能有疑问。引入Mesh后，会比以前多一个环节。会有新的开销吗？答案是不一定。在实施过程中，MOSN将SDK的业务逻辑复制到了MOSN上，相当于从左手移到了右手，并且还进行了优化。事实上我们也发现一些业务引入Mesh后内存消耗减少了。

云原生演进

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

拱

如下图所示，在整个云原生架构中，最底层是基础设施（包括硬件、网络资源、机房等），上层是基于硬件抽象来进行容器资源的调度和管理，上层是Mesh，在这一层起作用，MOSN相当于扮演了数据平面的角色。

介绍

任何技术诞生时都会伴随着业务痛点。在介绍它之前，我们先来看看它为什么会出现。最早的时候，资源是由物理机管理的。后来由于微服务的分裂，任何解决一个问题的技术肯定会带来新的问题。当然，新问题会加速新技术的出现，所以诞生得更晚。 。它完美解决了管理、调度、编排等问题，但它只管理机器资源。作为写业务的人，我们也期望应用可以通过微服务来管理，所以我们应运而生。

具有业务互联、流量安全、流量控制、可观测等功能。它的出现弥补了服务治理的短板。两者可以紧密合作，充分发挥各自的功能优势，实现微服务网格化管理。

MOSN 与

经过MOSN社区近几个月的不断努力，MOSN已经成功适配。 7月28日，官方发表了我署名的文章《数据平面的另一种选择——MOSN》，说明可以选择使用MOSN作为数据平面。如果您有兴趣，可以点击查看。在Mesh领域，用它作为控制平面已经成为主流。如下图所示，我们可以看到，在架构中，我们使用MOSN作为数据平面，借助它来实现服务治理。

成为云原生标准是我们 MOSN 的目标。为此，我们建立了 MOSN，让更多的开发者参与到社区中。

下图展示了MOSN适配的整个特性列表。值得一提的是，相当多的功能是由外部开发人员贡献的。

目前MOSN已经适配了.5.X版本，可以引入进行业务管理。不过在使用之前我们可以先了解一下下面是如何映射到MOSN的配置项的。如下图所示，基于请求路由，MOSN通过xDS协议获取对应的资源，并转换相关配置。然后，当MOSN真正接收到服务请求时，它会匹配该请求并进行相应的路由转发处理。

初步适配后，我们还进行了实例测试。如图是一个经典的多语言服务案例。早期没有Mesh，所以需要使用SDK来多语言编写。开发成本高，升级困难。但通过服务管理，MOSN（图中棕色区域）不仅可以使用，还可以用来有效解决之前的技术痛点。

事实上，通过 MOSN 作为数据平面运行实例后，已经实现了以下常见的服务治理能力：

如果您有兴趣，可以通过演示教程“MOSN”了解更多信息。

开源生态建设

实现MOSN适配后，我们并没有拘泥于它，而是与社区中的很多项目进行了沟通与合作，比如.

MOSN 与

MOSN可以解决系统下和非系统下的服务治理问题。如图所示，在方案一的中非系统服务治理场景中，可以引入-go来支持pub/sub，复用原有的服务注册中心来实现治理；方案2针对服务体系已经标准化的场景，通过支持如下路由来实现其服务治理。

MOSN 与

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

MOSN 与

服务之间的调用依赖关系和调用状态是微服务管理中的重要指标。通过与MOSN合作，我们集成了底层SDK，实现了呼叫链路拓扑展示、QPS监控、细粒度RT展示。未来，我们将继续向支持的方向发展。

标准化演变

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

所以，MOSN适配了、等组件后，我们认为不仅要适配别人，还要标准化，这就需要我们关注并积极参与开源社区的建设。事实上，在适配过程中，我们一直在和官方沟通，参与开发和UDPA的讨论和标准制定。

经过 MOSN 和官方的全面讨论，MOSN 社区将主导并参与数据平面的解耦（如测试集、镜像构建等），这将更容易集成第三方数据平面，即就是，MOSN社区更方便用户集成和使用。 MOSN 中已添加以下项目并进行了适配：

关于第一个问题，我们向社区贡献了PR，帮助解耦数据面和控制面的镜像构建，方便集成第三方数据面。 7月14日，TOC（技术委员会）委员@也回复我们，“也是支持多个数据平面的解决方案，也建议在官博中将MOSN作为实验性的第三方数据平面纳入其中”方便用户，快来试试吧”，这表明MOSN已经得到了官方的充分认可。

在标准化演进的过程中，我们与官方进行了讨论，提出了基于UDPA领域制定规范的建议：

总结与展望

MOSN开源社区目前发展迅速，全程借力开源、重复开源，在标准化的实践道路上一步步进化。如图所示，在MOSN开源框架中，MOSN的上层包括 、 、 UDPA。 MOSN 在使用的​​同时开发新功能并反馈给它们。

未来，MOSN云原生演进将在以下四大领域展开：

以上就是我今天要分享的全部内容了。更多 MOSN 资讯及最新动态可通过以下渠道获取：

MOSN官网

莫森

网