本文系云原生應(yīng)用最佳實踐杭州站活動演講稿整理。杭州站活動邀請了 Apache APISIX 項目 VP 溫銘、又拍云平臺開發(fā)部高級工程師莫紅波、螞蟻金服技術(shù)專家王發(fā)康、有贊中間件開發(fā)工程師張超，分享云原生落地應(yīng)用的經(jīng)驗心得，以下是王發(fā)康《云原生網(wǎng)絡(luò)代理（MOSN）的進化之路》分享內(nèi)容。

王發(fā)康（毅松）， 螞蟻金服可信原生技術(shù)部技術(shù)專家，專注于高性能網(wǎng)絡(luò)服務(wù)器研發(fā)，MOSN、Tengine 開源項目核 心成員，目前關(guān)注云原生 ServiceMesh、Nginx、Istio等相關(guān)領(lǐng)域。

今天主要分享 MOSN 在螞蟻金服的 Service Mesh 大規(guī)模落地后，通過對接 UDPA 打造為 Istio 的數(shù)據(jù)面之一，其在演進過程中遇到的問題及思考，我從以下三方面展開：

• MOSN 介紹

• 云原生演進

• 總結(jié)與展望

MOSN 介紹

我先從 MOSN 的誕生背景、MOSN 在螞蟻集團的發(fā)展歷程、MOSN 的架構(gòu)解析和落地情況等維度向大家介紹 MOSN。

MOSN 誕生背景

說到 Service Mesh 為什么會出現(xiàn)，我們需要先回顧服務(wù)演進歷程，大體經(jīng)歷如下階段：

**單體服務(wù)：**早期網(wǎng)站小、流量少，業(yè)務(wù)簡單，可在同一個服務(wù)中完成所有部署；

**分布式：**當用戶達到一定規(guī)模且日益增長，需要進行服務(wù)拆分；

**微服務(wù)：**隨著服務(wù)數(shù)量的持續(xù)增加，出現(xiàn)了服務(wù)治理的需求，如限流、鑒權(quán)、熔斷等，于是一些治理組件便被以 SDK 插件的形式集成到不同的應(yīng)用中；

**Service Mesh：**由于服務(wù)治理的 SDK 多語言、中間件組件開發(fā)適配成本高，以及其本身較弱的服務(wù)治理能力，開始嘗試將 SDK 和業(yè)務(wù)剝離，解耦出一個單獨的 Sidecar，從而解決多語言開發(fā)、業(yè)務(wù)迭代等難題。

總的來看，業(yè)務(wù)側(cè)有如下痛點：

• 多語言，中間件組件開發(fā)適配成本高

• SDK 升級困難

• 服務(wù)治理能力弱

• 技術(shù)不通用，無法復(fù)用

現(xiàn)有業(yè)界方案：

• Envoy (C++)

• Linkerd (活躍度較低)

• NginxMesh (活躍度低)

基于上述業(yè)務(wù)的痛點以及對業(yè)界相應(yīng)的解決方案評估過后，最終我們決定自主研發(fā) MOSN。MOSN（ModularOpen Smart Network） 是用 GoLang 語言開發(fā)的網(wǎng)絡(luò)代理軟件，作為云原生的網(wǎng)絡(luò)數(shù)據(jù)平面，旨在為服務(wù)提供多協(xié)議、模塊化、智能化、安全的代理能力。

MOSN 發(fā)展歷程

MOSN 從 2017 年 12 月開始 Service Mesh 技術(shù)調(diào)研，到產(chǎn)品孵化，歷經(jīng)重重困難，最終通過 2019 年雙 11 規(guī)?；炞C，實現(xiàn)螞蟻集團核心支付鏈路覆蓋。MOSN 在內(nèi)部落地后，我們認為借力開源也要反哺開源，因此著手進行 CloudNative 生態(tài)融合，和業(yè)界多種開源標準組件聯(lián)合走標準化道路，從而實現(xiàn)共享并最大化的釋放其技術(shù)紅利。

下圖為 MOSN 全局功能視圖，作為網(wǎng)絡(luò)數(shù)據(jù)平面，MOSN 如今已具備支持路由、負載均衡、多協(xié)議等多功能，另外也包括可觀察性和 Admin 管理等。

MOSN 架構(gòu)解析

MOSN 整體框架采用分而治之的架構(gòu)思想，如圖所示 MOSN 整個架構(gòu)共分四層：

-Network：最底層是網(wǎng)絡(luò)層，負責接收數(shù)據(jù)包，Listener_filter（original_dst）、network_filter（tcp、faultinject）

• Protocol：多協(xié)議層（HTTP 系、SOFARPC、Dubbo），提供自定義協(xié)議能力（Xprotocol）

• Stream：Stream_filter(health_check、faultinject)

• Proxy：提供 proxy 框架（分階段處理、router、loadbalancer、connection pool）

每一層通過工廠設(shè)計模式向外暴露其接口，方便用戶靈活的注冊自身的需求，采用協(xié)程池的方式使得用戶以同步的編碼風格就可以實現(xiàn)異步功能特性。鑒于 MOSN 使用 GoLang 語言，支持用同步的方式表達異步的動作，因而 MOSN 較為容易的實現(xiàn)了 read 和 proxy 兩大類協(xié)程，具體流程見 MOSN 的協(xié)程池模式示意圖：

通過上述框架設(shè)計，MOSN 競爭優(yōu)勢大大提高，其核心能力如下：

• 熱生效：配置熱生效（xDS）；二進制平滑升級（連接遷移）是核心競爭優(yōu)勢

• 多協(xié)議（Xprotocol）：支持 HTTP 系、SOFARPC、Dubbo

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

• 轉(zhuǎn)發(fā)能力：四層及七層；SWRR、Random、EDF、Maglev etc

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

MOSN 內(nèi)存&連接池

MOSN 為了降低 Runtime GC 帶來的卡頓，自身做了內(nèi)存池的封裝，方便多種對象高效的復(fù)用內(nèi)存。為了提升服務(wù)網(wǎng)格之間的建連能力，我們設(shè)計封裝了多種協(xié)議的連接池，方便的實現(xiàn)連接復(fù)用及管理。

MOSN 落地情況

2019 年 MOSN 已經(jīng)經(jīng)過雙 11 規(guī)模化驗證，實現(xiàn)螞蟻集團核心支付鏈路全覆蓋，效果驚人。當然大家可能會有疑問，引入 Service Mesh 后比以前的鏈路多一條，會不會產(chǎn)生新的開銷？答案是不一定。MOSN 在落地實現(xiàn)的過程中將 SDK 的業(yè)務(wù)邏輯復(fù)制到 MOSN，相當于從左手倒到右手，同時還進行了優(yōu)化。事實上我們當時還發(fā)現(xiàn)有些業(yè)務(wù)引入 Service Mesh 之后，內(nèi)存消耗更少。

云原生演進

前面我們了解了 MOSN 在螞蟻集團數(shù)據(jù)面落地的情況，我們其實一直有一個小夢想——希望更多人使用 MOSN ，所以我們做了標準化云原生演進，打通周邊的生態(tài)合作，下面詳細展開。

Could Native Arch

如下圖所示，在整個云原生架構(gòu)中，最下層是基礎(chǔ)設(shè)施（包含硬件、網(wǎng)絡(luò)資源、機房等），上一層是基于硬件抽象出的 Kubernetes 進行容器資源的調(diào)度管理，再上面一層是 Service Mesh、Serverless ，Istio 在這一層發(fā)揮功能，而 MOSN 相當于是在 Istio 里扮演數(shù)據(jù)面的角色。

Istio 簡介

任何一項技術(shù)都是伴隨業(yè)務(wù)痛點誕生的，在介紹 Istio 之前我們也來看一下為什么 Istio 會出現(xiàn)。最早的時候都是物理機管理資源，之后由于微服務(wù)拆分出現(xiàn)了 Docker，但任何一項技術(shù)解決一個問題，肯定又會帶來新的問題，當然新的問題會加速新技術(shù)出現(xiàn)，所以 Docker 之后誕生了 Kubernetes 。Kubernetes 完美解決了 Docker 的管理、調(diào)度、編排等問題，但也只管理了機器資源。作為寫業(yè)務(wù)的人，我們也期望應(yīng)用能夠進行微服務(wù)治理，于是 Istio 應(yīng)運而生了。

Istio 具有服務(wù)互連 、 流量安全 、 流量控制 、 可觀測性等功能，它的出現(xiàn)彌補了 Kubernetes 在服務(wù)治理上的短板，二者可以緊密合作，充分發(fā)揮其功能優(yōu)勢，從而實現(xiàn)微服務(wù)網(wǎng)格管理。

MOSN with Istio

經(jīng)過 MOSN 社區(qū)近幾個月的不斷努力，MOSN 已經(jīng)成功適配 Istio。7 月 28 日 Istio 官方發(fā)表了本人署名的文章《Istio 數(shù)據(jù)平面的另一個選擇 —— MOSN》，說明 MOSN 是可以作為數(shù)據(jù)面被選擇使用的，感興趣可以點擊查看 https://istio.io/latest/blog/2020/mosn-proxy。在 Service Mesh 領(lǐng)域，使用Istio 作為控制平面已成為主流，如下圖所示可以看出在 Istio 的架構(gòu)中，我們是將 MOSN 作為 Istio 的數(shù)據(jù)面，通過借助 Istio 實現(xiàn)服務(wù)治理。

成為云原生標準 Sidecar 是我們?yōu)?MOSN 定的目標，為此我們成立了 Istio、MOSN、Dubbo 相關(guān)的 Working Group，讓社區(qū)更多的開發(fā)工作人員參與進來。

下圖展示了 MOSN 適配 Istio 整個功能列表，值得一提的是相當多的功能都是外部開發(fā)者貢獻的。

目前 MOSN 已經(jīng)適配了 Istio1.5.X 版本，可以引入其進行服務(wù)治理。不過使用前我們可以先了解下 Istio 中的 Virtual Service 是如何映射到 MOSN 的 router 配置項的。如下圖所示，Istio 的 Virtual Service 基于請求 Header 路由，MOSN 通過 xDS 協(xié)議從 Istio 獲取到對應(yīng)的資源進行相關(guān)配置的轉(zhuǎn)換，然后當 MOSN 真正的接收到業(yè)務(wù)請求后，對請求進行 Header 匹配，做對應(yīng)的路由轉(zhuǎn)發(fā)處理。

在初步適配 Istio 之后，我們也進行了 Bookinfo 實例測試。如圖是一個經(jīng)典的多語言服務(wù)案例，早期沒有 Service Mesh，需要用到 SDK 多語言來寫，開發(fā)成本高、升級難度大。但當通過 Istio 做服務(wù)管理后，MOSN（圖中棕色區(qū)域） 不僅可以做 Ingress Gateway，還可作為 Sidecar，有效解決此前技術(shù)痛點。

事實上在通過 MOSN 作為 Istio 的數(shù)據(jù)平面運行 Bookinfo 實例后，目前已實現(xiàn)下列多項服務(wù)治理通用能力：

• 按 version 路由能力

• 按照權(quán)重路由能力

• 按照特定 header 路由能力

• 故障注入能力

• 服務(wù)熔斷自護能力

• 透明劫持能力

• 超時重試機制

• etc

大家如果感興趣可以通過演示教程《MOSN withIstio》 https://www.katacoda.com/mosn/courses/scenarios/mosn-with-istio 進一步了解。

開源生態(tài)建設(shè)

在實現(xiàn) MOSN 適配 Istio 后，我們并未拘泥于 Istio，而是和社區(qū)的很多項目進行溝通合作，例如 Dubbo、Sentinel、Skywalking。

MOSN with Dubbo

MOSN 可以解決 Kubernetes 體系和非 Kubernetes體系下的 Dubbo 服務(wù)治理難題。如圖中所示，方案 1 中非 Kubernetes 體系服務(wù)治理場景中，可以引入 MOSN 集成 Dubbo-go 支持 pub/sub，復(fù)用原有的服務(wù)注冊中心實現(xiàn)治理；方案 2 則是針對服務(wù)體系已 Kubernetes 化場景，通過支持 Dubbo 在 Istio下的路由，從而實現(xiàn)其服務(wù)治理。

MOSN with Sentinel

限流是服務(wù)治理中重要功能之一，而 Sentinel 是阿里巴巴開源的限流組件，經(jīng)歷過雙十一大促考驗，所以我們選擇通過 MOSN 集成 Sentinel 復(fù)用其底層的限流能力，實現(xiàn)單機限流（令牌桶/漏桶結(jié)合）、服務(wù)熔斷保護（服務(wù)成功率）、自適應(yīng)限流（依據(jù)機器負載）等功能。下一步我們將豐富限流算法，結(jié)合 Istio 聯(lián)手 UDPA 制定新規(guī)則。

MOSN with Skywalking

調(diào)用依賴以及服務(wù)與服務(wù)之的調(diào)用狀態(tài)是微服務(wù)管理中一個重指標，MOSN 通過和 Skywalking 合作，集成 Skywalking 底層的 SDK，實現(xiàn)調(diào)用鏈路拓撲展示、QPS 監(jiān)控、細粒度 RT 展示。未來，我們也會朝著 Dubbo Tracing 支持方向持續(xù)演進。

標準化演進

除了開源生態(tài)適配外，MOSN 也在嘗試標準化。大家都知道「標準」和「規(guī)范」很重要，例如谷歌提議 UDPA 規(guī)范，在數(shù)據(jù)面之上的一層標準 API 解耦控制面和數(shù)據(jù)面通信；而微軟則提出 ServiceMesh Interface，在控制面之上的一層標準 API 解耦控制面和上層應(yīng)用/工具，這些規(guī)范的背后都是為了遵守“防止鎖定，可方便用戶靈活切換”原則。

因此在 MOSN 在適配 Istio 以及 Dubbo、Skywalking 等組件后，我們認為不僅要適配別人，也要標準，這需要我們關(guān)注并積極參與開源社區(qū)建設(shè)。事實上在適配 Istio 的過程中，我們已經(jīng)在和 Istio 官方溝通，既參與 Istio 的開發(fā)，也參與了 UDPA 討論及標準制定。

而在綜合 MOSN 和 Istio 官方的討論后，MOSN 社區(qū)主導(dǎo)并會參與 Istio 中數(shù)據(jù)面解耦的事情（比如測試集、鏡像構(gòu)建等），這樣讓 Istio 先變得更容易集成第三方的數(shù)據(jù)面，即 MOSN 社區(qū)的用戶更方便的集成 Istio 使用。MOSN with Istio 適配的 Roadmap 中新增如下事項：

• 推動 Istio 的鏡像構(gòu)建和數(shù)據(jù)面解耦

• 推動 Istio 的測試框架和數(shù)據(jù)面解耦

就第一個問題，我們向 Istio 社區(qū)貢獻 PR，幫助 Istio 數(shù)據(jù)面和控制面的鏡像構(gòu)建實現(xiàn)解耦，使其更容易集成第三方的數(shù)據(jù)面。而在 7 月 14 號 Istio TOC（Istio 技術(shù)委員會）成員 @Shriram Rajagopalan 也回復(fù)我們“也是支持 Istio 中支持多數(shù)據(jù)面的方案，而且也建議先把 MOSN 做為實驗性第三方數(shù)據(jù)平面納入到 Istio 的官方博客中，方便用戶來試用”，這說明 MOSN 已經(jīng)充分得到 Istio 官方認可。

在標準化演進過程中，我們和 Istio 官方商議，提出基于 UDPA 領(lǐng)域制定規(guī)范的建議：

• 限流 Proto：限流 key 的定義、觀察者模式、限流后的 Action 抽象；

• 通用的 Router Proto：不局限于 HTTP 系、層級路由支持、路由條件的可擴展性增強；

總結(jié)與展望

MOSN 開源社區(qū)目前高速發(fā)展，**借力開源、反復(fù)開源貫穿始終，在實踐的道路上一步步的標準化演進。**如圖所示的 MOSN 開源框架中，MOSN 上層有 Fasthttp、Istio、UDPA，MOSN 在使用的同時對其進行新功能開發(fā)并回饋給它們。

未來 MOSN 云原生演進會在以下四大領(lǐng)域展開：

• 可編程： 面向業(yè)務(wù)層的 DSL，靈活、方便的控制請求的處理行為

• 微服務(wù)運行時 OS：Dapr 模式，面向 MOSN 編程促使服務(wù)更輕、更小、啟動更快

• 被集成：符合 UDPA 規(guī)范，可被 Istio 、Kuma 集成通用工具鏈剝離，方便其他項目復(fù)用

• 更多形態(tài)支持：Cache Mesh，Message Mesh，Block-chain Mesh

以上是我今天的全部內(nèi)容分享，更多 MOSN 信息和最新動態(tài)可以通過下列渠道了解：

MOSN 官網(wǎng) http://mosn.io

MOSN Github http://github.com/mosn/mosn

Service Mesh https://www.servicemesher.com

超強干貨來襲 云風專訪：近40年碼齡，通宵達旦的技術(shù)人生

總結(jié)

以上是生活随笔為你收集整理的云原生网络代理（MOSN）的进化之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。