雲原生網絡代理（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/2020/mosn-proxy。在 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/courses/scenarios/mosn-with-istio 進一步了解。

開源生態建設

在實現 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