雲原生網路代理（MOSN）的進化之路

又拍雲發表於2020-12-17

本文系雲原生應用最佳實踐杭州站活動演講稿整理。杭州站活動邀請了 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 全域性功能檢視，作為網路資料平面，MOSN 如今已具備支援路由、負載均衡、多協議等多功能，另外也包括可觀察性和 Admin 管理等。

MOSN 全域性功能檢視

MOSN 架構解析

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 協程架構圖

通過上述框架設計，MOSN 競爭優勢大大提高，其核心能力如下：

  • 熱生效：配置熱生效（xDS）；二進位制平滑升級（連線遷移）是核心競爭優勢

  • 多協議（Xprotocol）：支援 HTTP 系、SOFARPC、Dubbo

  • 流量管理及路由：headers/uri 分流；連線池、健康檢查、熔斷保護、故障注入；TLS/國密

  • 轉發能力：四層及七層；SWRR、Random、EDF、Maglev etc

  • 可觀察性：連線、請求、流量

MOSN 記憶體&連線池

MOSN 為了降低 Runtime GC 帶來的卡頓，自身做了記憶體池的封裝，方便多種物件高效的複用記憶體。為了提升服務網格之間的建連能力，我們設計封裝了多種協議的連線池，方便的實現連線複用及管理。

MOSN 落地情況

2019 年 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

相關文章