关于又拍云:云原生网络代理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 畛域制订标准的倡议：

• 限流 Proto：限流 key 的定义、观察者模式、限流后的 Action 形象；
• 通用的 Router Proto：不局限于 HTTP 系、层级路由反对、路由条件的可扩展性加强；

总结与瞻望

MOSN 开源社区目前高速倒退， 借力开源、重复开源贯通始终，在实际的路线上一步步的标准化演进。 如图所示的 MOSN 开源框架中，MOSN 下层有 Fasthttp、Istio、UDPA，MOSN 在应用的同时对其进行新性能开发并回馈给它们。

将来 MOSN 云原生演进会在以下四大畛域开展：

• 可编程：面向业务层的 DSL，灵便、不便的管制申请的解决行为
• 微服务运行时 OS：Dapr 模式，面向 MOSN 编程促使服务更轻、更小、启动更快
• 被集成：合乎 UDPA 标准，可被 Istio、Kuma 集成通用工具链剥离，不便其余我的项目复用
• 更多状态反对：Cache Mesh，Message Mesh，Block-chain Mesh

以上是我明天的全部内容分享，更多 MOSN 信息和最新动静能够通过下列渠道理解：

MOSN 官网 http://mosn.io

MOSN Github http://github.com/mosn/mosn

Service Mesh https://www.servicemesher.com