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 起源於 Service Mesh，原本在微服務之間的呼叫是通過比較重的 SDK 來完成的，當 SDK 升級的時候，需要應用配合一起升級，有比較強的打擾。

MOSN 為了解決這一痛點，向著把 SDK 剝離出來的方向演進。在應用所在的 Pod 內，單獨有一個執行 MOSN 的 sidecar，那麼應用本身只需要跟 MOSN 去通訊，就可以完成整個的服務呼叫的流程。把 SDK 剝離出來，相當於 MOSN 作為一個獨立的元件去演進，其演進過程對應用本身沒有打擾。這在螞蟻內部的收益其實是非常明顯的。

在整個演進的過程中，有兩個比較深的體會：一個比較明顯的是，有一個獨立的 sidecar，可以去跟業務邏輯做解耦；另外一個標準化，在雲原生的時代裡，控制面和資料面被拆分為兩個獨立的元件，MOSN 作為資料面的元件，演進過程中要跟很多控制面的服務對接，這期間標準化是一個很重要的。在整個標準化的過程中，它並不像業務解耦那麼直觀，但是用的時間越長，對其越深有體會。

現在 MOSN 已經在螞蟻內部全面的鋪開，部署有幾十萬 Pod，峰值 QPS 千萬級。

MOSN 的演進歷程

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 專案的貢獻之外，還有對其他專案/社群的貢獻，包括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 的擴充套件生態做到了什麼樣的程度了呢？

RPC 協議： 有 Dubbo 和 SOFABolt 的支援，同時基於 BabaSSL 做了國密的支援；

控制面： MOSN 已經做了 Istio 的支援；

註冊中心： SOFARegistry；

可觀測性：Skywalking 以及 Holmes 針對 Go 執行時期間，資源使用異常的自動分析和診斷。

在閘道器場景裡，有很多的邏輯是需要做定製的。除了常規的用 Go 寫一些 filter 擴充套件之外，還支援 Go Plugin 這種輕量級的模式，也支援 Proxy-Wasm 標準的 Wasm 擴充套件執行在 MOSN 中，服務治理方面也對接了 Sentinel。

Istio 1.10

MOSN 會通過標準的 xDS 協議和 Istio 通訊，這是一個非常標準的使用方式，同時我們也在積極的參與標準的建設。

我們在標準的制定過程中，積極提案參與討論，比如說限流的和路由的 proto，也正是我們和 Istio 有非常多的合作，才能夠獲得 Istio 官方的推薦。

MOSN 起源於 ServiceMesh 東西向流量的場景，我們經過了四年的努力，選擇在今天這個時間點發布 MOSN 1.0 版本，作為一個成熟穩定、有商業化落地、有社群、有生態的一個版本呈現出來，我們歡迎更多的人來使用 MOSN，也歡迎大家一起來共建和成長。

二、MoE 新架構

做這個的願景初衷是什麼？

這樣做的優勢是什麼？

MoE 新架構的探索有什麼新的進展？

首先 Enovy 和 MOSN 是作為目前市面上的兩個資料面，它們都各有特點， Enovy 是 C++寫的，處理效能會比較高。MOSN 的研發性和效能高，有很好的生態。

MoE 就是 MOSN 加 Enovy。我們希望能夠做把兩者的優勢給融合起來，相互融合，各取所長，把高效能和高研發效能結合到一起，支援我們做大做強，走得更遠。

MoE 架構在 Enovy 的角度來看，MOSN 作為 Enovy 的一個外掛擴充套件，在所有的 Enovy 的擴充套件方式裡面，做一個橫向的對比。

1.首先第一個是 Lua

嵌入式的指令碼語言有比較強的優勢，它操作簡單。但是作為相對小眾的語言，劣勢也很明顯——生態不好。我們目的是為了提高研發效能， Lua 無法讓我們達到目標。

2.WASM 是比較誘人的方案

WASM 在發展初期，有很多東西還只是停留在願景上。很多的語言支援不友好，以及 runtime 效能不夠好，這都是很現實的痛點。

3.外部跨程式通訊

外部跨程式通訊效能比較差，跟 CGo 比，相差將近一個數量級。其次管理很多其他外部程式比較複雜，如果有不同的語言，就需要有不同的程式，管理成本比較大。

相比， MoE 有兩方面優勢：

MOSN 現有很多的服務治理的能力，可以最大化複用起來；
Go 語言的生態，在未來的演進的路上需要寫更多的擴充套件，可以沿用 Go 高效的研發效能。

回過頭來看整個架構，站在 MOSN 這個角度上來說，Envoy 是作為 MOSN 的網路執行庫的角色。請求會先經過網路執行庫 （Envoy） ，然後再通過 CGo 這個橋樑，把請求資訊交給 MOSN，MOSN 完成請求邏輯之後，再去把響應交回給網路層。

目前的 MoE 的架構在螞蟻內部已經完成了落地，也拿到了我們預期的收益。

CGo 作為了 MOSN 和 Envoy 之間很重要橋樑，其效能很大程度決定了 MoE 的整體的效能表現。在 CGo 的具體實現裡，包括了從 C 到 Go，以及 Go 到 C 這兩個呼叫方向，兩個呼叫方向有一些實現上的區別。具體到 MoE 架構，主要是從 Envoy 到 MOSN，也就是從 C 到 Go 這個方向。

目前已經完成了一個數量級的優化提升——從 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

今年除了在東西向的持續演進迭代之外，還會做南北向的閘道器。

我們會結合 Istio 提供一個開源的產品，這是一個長遠的規劃，也是我們認為雲原生的閘道器未來可能會演進的方向。

2022 年的 Roadmap 中，除了這種核心能力，比如說我們會做模組化結構，優雅退出 （這些已經在 1.0 版本里實現了） 。還有各種微服務的生態，也會對接更多的註冊中心這種配置中心、雲原生、整合 Istio1.10。還特別增加了穩定性建設，隨著 MOSN 的使用者越來越多，大家對穩定效能力的呼聲也越來越高。

我們把螞蟻內部落地的 Holmes 整合到了開源的 MOSN 裡，對於執行時的資源異常，可以捕捉異常現場來分析。關於 Holmes，我們之前有過一個分享，感興趣的可以去閱讀。

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

南北向閘道器接入

除了 Roadmap 中各種能力上的發展計劃，有一個很重要的演進方向是南北向閘道器接入。MOSN 在 1.0 版本之後會升級到 MoE 的架構，南北向的接入閘道器是一個更大流量的場景，也將會用新架構的 MOSN 來支援。

由於歷史原因，MOSN 有非常多的閘道器形態，比如內部的 Spanner 和 MobileGW。並且每個閘道器形態，閘道器資料面都是不同的實現。

我們的演進方向是，資料面統一用 MOSN 來做底層支援，控制面走標準的 xDS 協議，跟 Istio 對接。這樣的話，無論是東西向還是南北向都能夠用雲原生的方式，以標準的方式去做對接。

基於傳統的南北向閘道器架構，我們去做雲原生的演進可能是一個艱難難的路子，我們更希望用 MOSN，用 MoE 新架構，這種更雲原生的架構來演進。

為什麼要去做 MoE 架構的探索？

MOSN 不侷限於東西向流量，而放眼於統一的網路轉發。以及在雲原生的時代，多雲已經是非常現實的需求了，這促使所有的網路要以標準的方式去對接。這是發力南北向接入閘道器的重要原因，我們希望把所有的網路轉發都統一起來，去支援更多的應用場景。

當然，南北向閘道器也會面臨很多的挑戰，作為一個集中式的閘道器，它的配置規則也很多，穩定性和效能要求也會更高。包括我們選擇的 Istio，也會面臨一個規模挑戰，以及怎麼面對從老的資料面遷移過來的成本。

面對新的挑戰，進行了 CGo 的優化保證效能，還有 TLS 協議能力的增強，目前 Envoy 在 TLS 協議的能力，還是比較適用於東西向閘道器。為了是適應於南北向閘道器，我們會去做一些增強，比如動態的證書籤發，還有單域名多證書的支援。以及穩定性方面，基於 Enovy 的多執行緒模型，程式 crash 會比多程式的方案有更大的影響，我們首先會提升 crash 後的恢復速度。