前言
MOSN 在螞蟻集團的 Service Mesh 大規模落地後，通過對接 UDPA 打造爲 Istio 的數據面之一，本文就其在演進過程中遇到的問題及思考進行展開。對接 UDPA，實現 Istio 融合，並增強 MOSN 服務治理及流量控制能力對接雲原生周邊組件，實現 MOSN 開箱即用。
大家下午好，我叫王發康，來自螞蟻集團可信雲原生應用網絡團隊，之前幾年一直從事南北向網關（接入層）的開發和維護，說來也是和流量有着別樣的淵緣，現在主要做東西向的流量網關（Service Mesh）開發和設計。今天演講的主題是《雲原生網絡代理 MOSN 的進化之路》，主要從如下幾點介紹：
- MOSN 介紹；
- 雲原生演進；
- 總結與展望；
MOSN 介紹
接下來，就 MOSN 的誕生背景、發展歷程、MOSN 具備的功能和架構以及內部的落地情況這幾個維度介紹下 MOSN。
MOSN 誕生背景
隨着雲計算、物聯網等技術迅速發展，也促使着微服務的架構一直在進化，其演進過程通常經歷瞭如下四個階段：
單體 ：一般起始階段業務很簡單，流量也不大，所有的處理都可以在一個服務中完成；
分佈式 ：隨着業務操作的多樣化以及流量的日益增長，不得不按照服務維度進行拆分，這樣相同的服務資源消耗可對等，方便容量評估及管理；
微服務 ：隨着服務的拆分粒度越來越細，其服務的數量一直在增加，由此出現各種微服務治理的需求（限流、鑑權、路由等），於是便出現各種治理組件並以 SDK 插件的方式集成到不同應用中；
Service Mesh ：伴隨着服務治理的 SDK 種類、版本、重複等一系列問題，於是把 SDK 的能力剝離到 Sidecar，和業務進行解耦，從而實現業務和中間件能力的並行迭代；
業務痛點
- 多語言，中間件組件開發適配成本高；
- SDK 升級困難；
- 服務治理能力弱；
- 技術不通用，無法複用；
業界解決方案
- Envoy (C++)；
- Linkerd (活躍度較低)；
- NginxMesh (活躍度低)；
綜合以上業務痛點以及業界現有方案的評估，於是 MOSN 就誕生了。MOSN（Modular Open Smart Network）是用 GoLang 編寫的網絡代理服務器。作爲 Sidecar、API Gateway、雲原生 Ingress、Layer 4 或 Layer 7 負載均衡器等場景構建的。隨着時間的推移，我們添加了額外的功能，例如多協議框架，多進程插件機制，DSL 以及對 xDS API 等的支持，支持 xDS 意味着我們現在可以將 MOSN 用作 Istio 的數據平面。
MOSN 發展歷程
從 2017 年底開始 Service Mesh 技術調研，2018 年 3 月份 MOSN 雛形問世並進行了小規模試點，秉着讓更多的用戶能夠享受這一技術紅利的思路，於是 2018 年 6 月正式開源 MOSN。2019 年 618 進行了規模化落地，並在同年的雙 11 大促達到了核心支付鏈路的全覆蓋。在通過大規模驗證後，MOSN 社區開始在其標準化以及生態方面進行發展和演進。
MOSN 功能視圖
MOSN 作爲一個通用的數據轉發平面，提供多協議卸載、動態服務發現、服務治理（Trace、限流、重試、重寫、超時控制等）、豐富的負載均衡算法等功能，可用於 Sidecar、API Gateway、雲原生 Ingress、Layer 4 或 Layer 7 負載均衡器等場景。
MOSN 架構解析
MOSN 採用的是分層的體系結構，其系統分爲 NET/IO、Protocol、Stream、Proxy 四層：
- NET/IO 作爲網絡層，監測連接和數據包的到來，同時作爲 listener filter 和 network filter 的掛載點;
- Protocol 作爲多協議引擎層，對數據包進行檢測，並使用對應協議做 decode/encode 處理;
- Stream 對 decode 的數據包做二次封裝爲 stream，作爲 stream filter 的掛載點;
- Proxy 作爲 MOSN 的轉發框架，對封裝的 stream 做 proxy 處理;
其中，每一層通過工廠設計模式向外暴露其接口，方便用戶靈活地註冊自身的需求。通過協程池的方式使得用戶以同步的編碼風格實現異步功能特性。通過區分協程類型，MOSN 實現了 read 和 proxy worker 兩大類協程，read 協程主要是處理網絡的讀取及協議解析，proxy worker 協程用來完成讀取後數據的加工、路由、轉發等。其架構如下圖所示：
MOSN 爲了降低 Runtime GC 帶來的卡頓，自身做了內存池的封裝方便多種對象高效地複用，另外爲了提升服務網格之間的建連性能還設計了多種協議的連接池從而方便地實現連接複用及管理。
在連接管理方面，MOSN 設計了多協議連接池， 當 Proxy 模塊在 Downstream 收到 Request 的時候，在經過路由、負載均衡等模塊處理獲取到 Upstream Host 以及對應的轉發協議時，通過 Cluster Manager 獲取對應協議的連接池 ，如果連接池不存在則創建並加入緩存中，之後在長連接上創建 Stream，併發送數據，如下圖所示：
在內存管理方面，MOSN 在 sync.Pool 之上封裝了一層資源對的註冊管理模塊，可以方便的擴展各種類型的對象進行復用和管理。其中 bpool 是用來存儲各類對象的構建方法，vpool 用來存放 bpool 中各個實例對象具體的值。運行時通過 bpool 裏保存的構建方法來創建對應的對象通過 index 關聯記錄到 vpool 中，使用完後通過 sync.Pool 進行空閒對象的管理達到複用，如下圖所示：
MOSN 落地情況
服務在做了 Mesh 化後，有人可能會質疑，增加一跳 Sidecar 轉發是否會導致性能下降，其實不然，在螞蟻的部分業務場景中，部分業務上了 Mesh 後，其 CPU 消耗還比之前低了，原因是之前的一些通用 SDK 能力都下沉到 Sidecar 中，並統一做了一定的優化。另一個好處是，由於 MOSN 使用 GoLang 開發，天然具備其高開發效率，所以也大大的提升了中間件相關能力的研發速度。
MOSN 雲原生演進
在 MOSN 大規模落地並通過雙 11 大考後，MOSN 也開始在實踐的道路上進行標準化演進。並通過和 Istio 社區的合作，MOSN 實現了 xDS 的適配，可方便的實現 Istio 作爲 MOSN 的控制面進行服務配置的管理。另一方面，我們也在積極參加 Istio 相關社區，並貢獻了一些通用能力及問題修復的 PR。
Cloud Native 架構
如下圖所示，最下面是基礎設施層（物理機等），上層進行抽象出 Kubernetes 進行容器資源的調度和管理，再上層就是部署在容器裏面的各種服務了，Istio 的能力（服務治理）就在這一層進行發揮的。
Istio 簡介
在介紹 Istio 前，先說下它爲什麼會出現。10 年前，一般應用都是直接部署在物理機上的，但是隨着時間的推移，機型一直變化（如 CPU 核數）就出現了機型對等、環境部署以及彈性擴容等一系列問題，於是就出現了 Docker。但是 Docker 涉及到容器編排、調度、管理等問題， Kubernetes 便隨之出現。Kubernetes 在容器管理領域的用途是毋庸置疑的，但是其在微服務治理方面存在一些不足，於是 Istio 便專職解決微服務治理的問題而問世。
Istio 彌補了 Kubernetes 在服務治理上的短板，提供服務互連、流量安全、流量控制、可觀測性功能。
MOSN 和 Istio
通過 MOSN 社區幾個月的努力及推進，MOSN v0.14.0 版本可以使用 Istio 1.5.x 作爲雲原生控制面，從而方便的進行微服務的治理。如下是 Istio 官方在 2020 年 7 月 28 號發佈了在 Istio 中使用 MOSN：另一個數據平面博文，即 Istio 數據平面的另一個選擇 —— MOSN。
如下是 MOSN 在 Istio 1.5 版本中的架構圖，MOSN 通過 xDS 協議從 Istio 動態的獲取各種服務配置，從而實現服務治理的效果。
在 Service Mesh 領域，使用 Istio 作爲控制平面已成爲主流。Istio 通過 xDS 協議和數據面進行交互，因此，通過在 MOSN 中實現 xDS，我們就可以使用 Istio 作爲 MOSN 的控制面。Istio 的第三方數據平面集成可以通過以下三個步驟實現：
- 實現 xDS 協議，對齊數據面相關服務治理能力;
- 使用 Istio 的腳本並設置相關
SIDECAR等參數構建proxyv2鏡像; - 通過 istioctl 工具並設置 proxy 相關配置指定具體的數據面;
有了對應的改造方案後，於是我們成立了相關 Working Group ，帶領社區的同學一起進行討論和改造。
除了對 Istio 進行改造（相關能力已經合入 Istio 官方倉庫），MOSN 也需要在負載均衡、服務治理及相關框架上做一些適配和增強，其適配列表如下所示：
MOSN 在功能上對齊 Istio 後，就可以使用其進行微服務治理了。在使用前，我們先看看 Istio 中的 VirtualService 等相關策略是如何和 MOSN 進行關聯的。如下圖所示，在 Istio 中的 VirtualService 做爲一個服務的轉發描述，其對應到 MOSN 中就是一個 Listener 以及一組對應的路由策略 Routes。
在初步瞭解 MOSN 如何同 Istio 結合後，我們來看看 MOSN 在 Bookinfo 實例中可以做什麼：如下是一個經典的多語言服務使用 Istio 做服務治理，在該場景中，MOSN 不僅獨立的作爲 Ingress Gateway，還作爲 Sidecar。
通過 MOSN 作爲 Istio 的數據平面運行 Bookinfo 事例，實現如下服務治理通用能力：
- 按 version路由能力
- 按照權重路由能力
- 按照特定 header路由能力
- 故障注入能力
- 服務熔斷自護能力
- 透明劫持能力
- 超時重試機制
- etc
在這裏，你可以通過演示教程《MOSN with Istio》來學習 MOSN 如何作爲 Istio 的數據面進行服務治理。
開源生態建設
MOSN 在對接完 Istio 的同時，也和周邊的開源生態進行了緊密的合作，如 Dubbo、Sentinel、Skywalking 等。
MOSN With Dubbo
MOSN 中提供 Kubernes 和 非 Kubernes 體系下的 Dubbo 服務治理方案。如下圖所示，方案 1 是在非 Kubernes 體系下，MOSN 通過集成 dubbo-go 支持服務的 pub/sub，並複用原有的服務註冊中心。方案 2 則是在 Kubernes 體系下使用 Istio 進行一步到位的服務治理，MOSN 通過支持 Istio 下的路由策略，實現服務的治理。
MOSN With Sentinel
限流是微服務治理中的一個重要功能， MOSN 通過集成 Sentinel 並複用其底層的限流能力，從而實現單機限流（令牌桶/漏桶結合）、服務熔斷保護（依據服務的成功率）、自適應限流（依據機器的負載），同時目前 Istio 的限流規則也沒有一個成熟的 API，我們也和 UDPA 進行了一些限流規則的規範討論。
MOSN With Skywalking
調用依賴以及服務與服務之的調用狀態是微服務管理中一個重指標，MOSN 社區通過和 Skywalking 合作，把 Skywalking 的 GoLang SDK 集成到 MOSN 中，從而實現 HTTP 系調用鏈路拓撲展示、QPS 監控、細粒度 RT 如下圖所示，同時該功能也在持續演進，接下來會支持 Dubbo Tracing。
標準化演進
除了開源生態的適配外，MOSN 也在其標準化方面做了一些貢獻（如限流、路由的 UDPA 策略提議等）。谷歌在數據面和控制面之間標準化出 UDPA 規範，微軟在控制面和應用及工具層面之間標準出 SMI 規範，這所做的一切其實都是圍繞“防止鎖定，方便用戶靈活切換”。
可見“標準”、“規範”的重要性，當然 MOSN 社區也在其相關的標準下做了一些演進和貢獻。
- 雲原生標準 Sidecar 的打造；
- 標準化參與和建設；
針對第一點，MOSN 社區持續在進行 Istio 能力的對齊工作，包括 Istio 側多 Sidecar 支持以及 MOSN 側功能對齊 Istio，控制面方面支持注入 MOSN Sidecar、Pilot-agent 的適配以及 Istio 編譯構建的適配、負載均衡算法、流量管理體系、流量檢測、服務治理等。
在標準化方面，我們也參與了 UDPA 相關規範討論，並提出限流通用 API 規範討論，社區會議討論組織中。
同時 MOSN 社區也積極地在和 Istio 社區進行溝通以及尋求合作，我們的目標是希望能成爲 Istio 官方推薦的 Sidecar 產品，對此我們在 Istio Github 上提了相關 ISSUE，引發了比較大的關注，Istio 官方 Member 成員 @howardjohn 對此問題進行了非常詳細的回答和探討。
綜合 MOSN 社區和 Istio 官方的討論後，MOSN 社區主導並會參與 Istio 中數據面解耦的事情（比如測試集、鏡像構建等），這樣使得 Istio 更容易集成第三方的數據面，即 MOSN 社區的用戶更方便的集成 Istio 使用。對此 MOSN with Istio 適配的 Roadmap 中新增如下事項：
- 推動 Istio 的鏡像構建和數據面解耦，相關 Issue；
- 推動 Istio 的測試框架和數據面解耦，相關 Issue；
針對第一點，MOSN 社區向 Istio 貢獻 PR，並已合入主幹，通過該 PR 可以更方便的讓 Istio 的 proxyv2 鏡像集成其它數據面。
2020 年 7 月 14 號 Istio TOC（Istio 技術委員會）成員 @ShriramRajagopalan 最新回覆：“也是支持 Istio 中支持多數據面的方案，而且也建議先把 MOSN 做爲實驗性第三方數據平面納入到 Istio 的官方博客中，方便用戶來試用”：
經過 MOSN 社區不斷的努力，在 7月底，Istio 官方博客正式上線了 在 Istio 中使用 MOSN：另一個數據平面 博文，取到了 Istio 官方的一定認可。
總結及未來展望
從 Service Mesh 技術調研，到 MOSN 誕生並小規模試點，再到雙 11 規模化落地，並走向開源到標準化演進，一路走來實屬不易，這個過程中也離不開 MOSN 開源社區開發者和使用者的貢獻與支持。
合作伙伴及用戶
秉着借力開源，反哺開源的思想，MOSN 社區在衆多的合作伙伴的共同努力下，在實踐的道路上，一步步的走向標準化。
總結及未來展望
接下來，MOSN 社區不僅會持續兼容適配新版本的 Istio 的功能，而且還將在以下幾個方面進行發力：
- 可編程，如支持面向業務層的 DSL，可方便的控制請求的處理流程，另外也會在 WASM 上進行預研；
- Dapr 模式作爲微服務運行時，使得面向 MOSN 編程的服務更輕、更小、啓動速度更快；
- 被集成，遵循 UDPA 規範，可方便的被 Istio 、 Kuma 集成，另外 MOSN 裏面的通用工具鏈剝離爲 package，方便其它 GoLang 項目複用；
- 更多場景 Mesh 化方案支持，Cache Mesh/Message Mesh/Block-chain Mesh 等；
MOSN 是一個開源項目，社區中的任何人都可以使用，參與和改進。我們希望您能加入社區！可以通過這裏介紹的幾種方式瞭解 MOSN 正在做的事情並參與其中。
- MOSN 官網 http://mosn.io/
- MOSN Github http://github.com/mosn/mosn
- Service Mesh https://www.servicemesher.com/
歡迎加入 MOSN 開源交流羣：釘釘搜索羣號 : 21992058
作者介紹：
王發康（毅松）螞蟻集團可信原生技術部 技術專家，專注於高性能網絡服務器研發，是 MOSN、Tengine 開源項目核心成員，目前關注雲原生 Service Mesh、Nginx、Istio 等相關領域，喜歡開源，樂於分享。
GItHub：https://github.com/wangfakang
本文轉載自公衆號金融級分佈式架構（ID：Antfin_SOFA）。
原文鏈接：