MOSN 1.0 发布,开启新架构演进

图片

文|朱德江(花名:人德)

蚂蚁集团技术专家
负责 MOSN 核心开发,关注云原生流量网关的演进

以下内容整理自 SOFAStack 四周年的分享

本文 5332字 阅读 10 分钟

MOSN 1.0 发布

MOSN 是一款主要使用 Go 语言开发的云原生网络代理平台,由蚂蚁集团开源,经过双 11 大促几十万容器的生产级验证。

经过 4 年的蓬勃发展,在 11 位 commiter,100 多个 contributor 和整个社区的共同努力下,经历 27 个小版本的迭代,MOSN 1.0 版本正式发布了。

一个足够成熟稳定,有开源用户共建、有商业化落地、有社区,拥抱云原生生态的 MOSN 1.0 来了。

除了在蚂蚁集团的全面落地,MOSN 在业界也有较广泛的应用,比如有工商银行的商业化落地,还有阿里云、去哪儿网、时速云等企业的生产实践。

同时,随着 1.0 的发布,进入少年期的 MOSN 也将开启新一代 MOE 架构演进,奔向星辰大海。

发展历史

MOSN 1.0 发布,开启新架构演进_第1张图片

MOSN 起源于 Service Mesh,原本在微服务之间的调用是通过比较重的 SDK 来完成的,当 SDK 升级的时候,需要应用配合一起升级,有比较强的打扰。

MOSN 为了解决这一痛点,向着把 SDK 剥离出来的方向演进。在应用所在的 Pod 内,单独有一个运行 MOSN 的 sidecar,那么应用本身只需要跟 MOSN 去通讯,就可以完成整个的服务调用的流程。把 SDK 剥离出来,相当于 MOSN 作为一个独立的组件去演进,其演进过程对应用本身没有打扰。这在蚂蚁内部的收益其实是非常明显的。

在整个演进的过程中,有两个比较深的体会:一个比较明显的是,有一个独立的 sidecar,可以去跟业务逻辑做解耦;另外一个标准化,在云原生的时代里,控制面和数据面被拆分为两个独立的组件,MOSN 作为数据面的组件,演进过程中要跟很多控制面的服务对接,这期间标准化是一个很重要的。在整个标准化的过程中,它并不像业务解耦那么直观,但是用的时间越长,对其越深有体会。

现在 MOSN 已经在蚂蚁内部全面的铺开,部署有几十万 Pod,峰值 QPS 千万级。

MOSN 的演进历程

MOSN 1.0 发布,开启新架构演进_第2张图片

2018 年: 开始创建;

2019 年: 在双 11 完成了核心链路的覆盖,在 19 年底的时候,MOSN 开始独立运营;

2020 年: 7 月份获得 Istio 官方的推荐。同时,MOSN 开启了商业化的探索,年底完成了江西农信的落地;

2021 年: 对接了 Envoy、Dapr、WASM 生态,和主流的社区合作。同年 12 月份, 在工商银行完成了商业化的落地,树立了业界新标杆。

MOSN 除了在蚂蚁内部全面铺开,以及商业化的落地实践,还有逐渐完善的社区。MOSN 社区目前有 11 个 Committer,其中超过 70% 是非蚂蚁的 Committer,有 100 多位的 Contributor,经过了 28 个小版本的迭代。MOSN 还有很多开源的用户,他们将 MOSN 在自己公司落地,也对 MOSN 有很多的贡献。

MOSN 1.0 发布,开启新架构演进_第3张图片

社区除了在 MOSN 项目的贡献之外,还有对其他项目/社区的贡献,包括Holmes、BabaSSL、Proxy-Wasm 等项目,以及跟其他生态项目的对接。

总体来说,MOSN 现在足够成熟稳定,有商业化的落地,有社区、有周边、有生态,所以我们选择这个时间点发布 MOSN 1.0 版本。

1.0 的核心能力以及扩展生态

MOSN 1.0 版本标志性的成果是已经集成了 Istio 的 1.10 版本。

MOSN 作为网络代理的软件,在核心转发方面已经支持了 TCP、UDP、透明劫持的模式。MOSN 所处在东西向网关场景下,有很多内部的、私有的非标协议,MOSN 除了支持 HTTP 标准协议以外,还有很重要的 XProtocol 框架,可以非常简单、方便支持私有的非标协议,内置的 Bolt、 Dubbo 协议,也是通过 XProtocol 框架来实现的。我们还支持了多协议的自动识别,也是在东西向流量网关里面比较核心的、比较特别的能力支持。

后端管理和负载均衡是在网络代理情况下,比较基本的常规能力。MOSN 也支持了连接池、主动健康检查、各种各样的负载均衡的策略。

在核心路由上,MOSN 支持基于 Domain 的 VirtualHost,引入了一个非常强大的变量支持,通过变量做复杂的路由规则,也支持了 Metadata 的分组路由。还有路由级别的超时、重试的配置,以及请求头、响应头的处理。

简单来说,作为一个网络代理的平台,通用的核心能力 MOSN 都已经完全具备了。

同时在网络代理的场景,通常需要做很多扩展,MOSN 的扩展生态做到了什么样的程度了呢?

MOSN 1.0 发布,开启新架构演进_第4张图片

RPC 协议: 有 Dubbo 和 SOFABolt 的支持,同时基于 BabaSSL 做了国密的支持;

控制面: MOSN 已经做了  Istio 的支持;

注册中心: SOFARegistry;

可观测性:Skywalking 以及 Holmes 针对 Go 运行时期间,资源使用异常的自动分析和诊断。

在网关场景里,有很多的逻辑是需要做定制的。除了常规的用 Go 写一些 filter 扩展之外,还支持 Go Plugin 这种轻量级的模式,也支持 Proxy-Wasm 标准的 Wasm 扩展运行在 MOSN 中,服务治理方面也对接了 Sentinel。

Istio 1.10

MOSN 1.0 发布,开启新架构演进_第5张图片

MOSN 会通过标准的 xDS 协议和 Istio 通讯,这是一个非常标准的使用方式,同时我们也在积极的参与标准的建设。

我们在标准的制定过程中,积极提案参与讨论,比如说限流的和路由的 proto,也正是我们和 Istio 有非常多的合作,才能够获得 Istio 官方的推荐。

MOSN 起源于 ServiceMesh 东西向流量的场景,我们经过了四年的努力,选择在今天这个时间点发布 MOSN 1.0 版本,作为一个成熟稳定、有商业化落地、有社区、有生态的一个版本呈现出来,我们欢迎更多的人来使用 MOSN,也欢迎大家一起来共建和成长。

二、MoE 新架构

做这个的愿景初衷是什么?

这样做的优势是什么?

MoE 新架构的探索有什么新的进展?

MOSN 1.0 发布,开启新架构演进_第6张图片

首先 Enovy 和 MOSN 是作为目前市面上的两个数据面,它们都各有特点, Enovy 是 C++写的,处理性能会比较高。MOSN 的研发性和效能高,有很好的生态。

MoE 就是 MOSN 加 Enovy。我们希望能够做把两者的优势给融合起来,相互融合,各取所长,把高性能和高研发效能结合到一起,支持我们做大做强,走得更远。

MoE 架构在 Enovy 的角度来看,MOSN 作为 Enovy 的一个插件扩展,在所有的 Enovy 的扩展方式里面,做一个横向的对比。

MOSN 1.0 发布,开启新架构演进_第7张图片

1.首先第一个是 Lua

嵌入式的脚本语言有比较强的优势,它操作简单。但是作为相对小众的语言,劣势也很明显——生态不好。我们目的是为了提高研发效能, Lua 无法让我们达到目标。

2.WASM 是比较诱人的方案

WASM 在发展初期,有很多东西还只是停留在愿景上。很多的语言支持不友好,以及 runtime 性能不够好,这都是很现实的痛点。

3.外部跨进程通讯

外部跨进程通讯性能比较差,跟 CGo 比,相差将近一个数量级。其次管理很多其他外部进程比较复杂,如果有不同的语言,就需要有不同的进程,管理成本比较大。

相比, MoE 有两方面优势:

  • MOSN 现有很多的服务治理的能力,可以最大化复用起来;
  • Go 语言的生态,在未来的演进的路上需要写更多的扩展,可以沿用 Go 高效的研发效能。

MOSN 1.0 发布,开启新架构演进_第8张图片

回过头来看整个架构,站在 MOSN 这个角度上来说,Envoy 是作为 MOSN 的网络运行库的角色。请求会先经过网络运行库 (Envoy) ,然后再通过 CGo 这个桥梁,把请求信息交给 MOSN,MOSN 完成请求逻辑之后,再去把响应交回给网络层。

MOSN 1.0 发布,开启新架构演进_第9张图片

目前的 MoE 的架构在蚂蚁内部已经完成了落地,也拿到了我们预期的收益。

CGo 作为了 MOSN 和 Envoy 之间很重要桥梁,其性能很大程度决定了 MoE 的整体的性能表现。在 CGo 的具体实现里,包括了从 C 到 Go,以及 Go 到 C 这两个调用方向,两个调用方向有一些实现上的区别。具体到 MoE 架构,主要是从 Envoy 到 MOSN,也就是从 C 到 Go 这个方向。

MOSN 1.0 发布,开启新架构演进_第10张图片

目前已经完成了一个数量级的优化提升——从 1600 纳秒到 140 纳秒。 (通过本地最简单的测试,基本上只是覆盖到 CGo 本身的开销,不考虑掉到 Go 里面有很复杂的逻辑。

140 纳秒是个什么概念?

就差不多跟 Go 调 C 是一个量级,也就是目前官方的实现。 (我们目前的优化也提给了 Go 的官方,通过了几轮的 review,还在等其他官方成员的 review。)

因为 Go 是跨平台的,目前的实现还只支持 x86/64 体系,需要给不同的体系结构加对应的实现。

在 CGo 方面,还分析出了很多的优化空间。比如,搞一个 extra P 机制,对应于 extra M 的机制,解决高负载场景对 P 资源的争用。

另外一个就是寄存器传参,现在 C 和 Go 之间传参,把参数是放到一个结构体里,如果可以改用寄存器传参应该可以获得更好的性能。

目前已支持将 MOSN 部分 filter 运行在 Envoy 中,开源仓库可以找到这一部分,欢迎大家来试用。

https://github.com/mosn/mosn/...

MoE 开源计划

把抽象的 API 提供给 Enovy 官方,再基于标准 API 实现 Go 的扩展,(大概会是在 8 月份完成)。下半年完成 MoE 的整体开源,也欢迎大家持续的关注。

2022 年 Roadmap

MOSN 1.0 发布,开启新架构演进_第11张图片

今年除了在东西向的持续演进迭代之外,还会做南北向的网关。

我们会结合 Istio 提供一个开源的产品,这是一个长远的规划,也是我们认为云原生的网关未来可能会演进的方向。

2022 年的 Roadmap 中,除了这种核心能力,比如说我们会做模块化结构, 优雅退出 (这些已经在 1.0 版本里实现了) 。还有各种微服务的生态,也会对接更多的注册中心这种配置中心、云原生、集成 Istio1.10。还特别增加了稳定性建设,随着 MOSN 的用户越来越多,大家对稳定性能力的呼声也越来越高。

我们把蚂蚁内部落地的 Holmes 集成到了开源的 MOSN 里,对于运行时的资源异常,可以捕捉异常现场来分析。关于 Holmes,我们之前有过一个分享,感兴趣的可以去阅读。

https://mosn.io/blog/posts/mo...

南北向网关接入

MOSN 1.0 发布,开启新架构演进_第12张图片

除了 Roadmap 中各种能力上的发展计划,有一个很重要的演进方向是南北向网关接入。MOSN 在 1.0 版本之后会升级到 MoE 的架构,南北向的接入网关是一个更大流量的场景,也将会用新架构的 MOSN 来支持。

由于历史原因,MOSN 有非常多的网关形态,比如内部的 Spanner 和 MobileGW。并且每个网关形态,网关数据面都是不同的实现。

我们的演进方向是,数据面统一用 MOSN 来做底层支持,控制面走标准的 xDS 协议,跟 Istio 对接。这样的话,无论是东西向还是南北向都能够用云原生的方式,以标准的方式去做对接。

基于传统的南北向网关架构,我们去做云原生的演进可能是一个艰难难的路子,我们更希望用 MOSN,用 MoE 新架构,这种更云原生的架构来演进。

为什么要去做 MoE 架构的探索?

MOSN 不局限于东西向流量,而放眼于统一的网络转发。以及在云原生的时代,多云已经是非常现实的需求了,这促使所有的网络要以标准的方式去对接。这是发力南北向接入网关的重要原因,我们希望把所有的网络转发都统一起来,去支持更多的应用场景。

当然,南北向网关也会面临很多的挑战,作为一个集中式的网关,它的配置规则也很多,稳定性和性能要求也会更高。包括我们选择的 Istio,也会面临一个规模挑战,以及怎么面对从老的数据面迁移过来的成本。

面对新的挑战,进行了 CGo 的优化保证性能,还有 TLS 协议能力的增强,目前 Envoy 在 TLS 协议的能力,还是比较适用于东西向网关。为了是适应于南北向网关,我们会去做一些增强,比如动态的证书签发,还有单域名多证书的支持。以及稳定性方面,基于 Enovy 的多线程模型,进程 crash 会比多进程的方案有更大的影响,我们首先会提升 crash 后的恢复速度。

MOSN 1.0 发布,开启新架构演进_第13张图片

我们的长远目标是希望跟社区共建,提供开源的完整产品,大家基于开源的方式协作,把产品做大做强。

MOSN 目前作为数据面的呈现,产品能够包含一整套解决方案,我们的第一目标是达到开箱即用的效果。

另外一个是双模支持,首先是 MOSN 会支持标准的 xDS,这是比较有潜力的演进方向。其次,在落地的过程中,MOSN 不会只保留 xDS 这一条路。MOSN 还是会去支持所有的注册中心、配置中心。这样在业务落地的过程中,两边可以同时运行。基于原有的高性能的研发效能,保持方便的定制开发能力。

最终,希望 MOSN 成为统一的网络转发平台,支持东西向、南北向的流量,以及在多云场景下的支持。

当数据面网络能够做到统一,MOSN 会在开源、商业化朝着这个方向持续的探索集中力量去做更长远的事情,也希望更多朋友能够参与进来,一起来共建。

欢迎大家使用 MOSN,共同成长

​MOSN 官网:https://mosn.io/

​MOSN GitHub 地址:https://github.com/mosn

你可能感兴趣的:(云原生开源架构资讯golang)