注：本文是王發(fā)康（毅松）在 2021 GopherChina 上演講的文字稿，相關(guān)分享 PPT 可自行到 MOSN meetup 下載。

MOSN meetup 地址：

https://github.com/mosn/meetup

MOSN 官方 Github 地址：

https://github.com/mosn/mosn

GitHub 地址：???????????????????????????????????????https://github.com/sofastack???????????????????????????????????????

?????????????????????????????????????????????

前言

MOSN 在 Service Mesh 領(lǐng)域作為東西向服務(wù)治理網(wǎng)絡(luò)在螞蟻集團雙 11 、春節(jié)紅包等活動及開源社區(qū)都得到了一定實踐。為了能夠讓社區(qū)用戶更好的享受到這一技術(shù)紅利，MOSN 從 2018 年開源以來在社區(qū)開發(fā)者、用戶的共同努力下，使得 MOSN 在云原生演進(jìn)方面做了很多探索和實踐。比如 Istio 下另一個數(shù)據(jù)面 — MOSN、WebAssembly 在 MOSN 中的探索與實踐、MOSN 子項目 Layotto：開啟服務(wù)網(wǎng)格+應(yīng)用運行時新篇章、MOSN 基于 Sentinel 的限流實踐、MOSN 中玩轉(zhuǎn) Dubbo-go 等周邊生態(tài)展開合作。

Istio 下另一個數(shù)據(jù)面 — MOSN 文章鏈接：

https://istio.io/latest/blog/2020/mosn-proxy

MOSN 基于 Sentinel 的限流實踐文章鏈接：

https://github.com/mosn/mosn/pull/1111

MOSN 中玩轉(zhuǎn) Dubbo-go 等周邊生態(tài)展開合作文章鏈接：

https://mosn.io/blog/posts/mosn-dubbo-integrate/

2021 年為了更好的為業(yè)務(wù)提效，MOSN 開啟了將云原生進(jìn)行到底的決心。本文介紹了 MOSN 在網(wǎng)絡(luò)擴展層的思考和技術(shù)選型，以及最終是如何通過使用 Envoy 作為 MOSN 的網(wǎng)絡(luò)層擴展，從而實現(xiàn) MOSN 和 Envoy 生態(tài)打通。使得網(wǎng)絡(luò)層具備 C++ 高性能的同時，上層業(yè)務(wù)治理能力也能借助 GoLang 進(jìn)行高效的定制化開發(fā)。

面臨的問題及挑戰(zhàn)

一、社區(qū)生態(tài)，如何最大化求同存異

最近幾年 Service Mesh 技術(shù)在云原生社區(qū)也是百花齊放，雖然 MOSN 在開源社區(qū)也是備受開發(fā)者的關(guān)注，但是 Envoy 經(jīng)過長久的發(fā)展其社區(qū)的活躍度和用戶量的積累這點是不可忽略的。另外選擇 MOSN 的用戶都是看重其二次開發(fā)的便捷性以及 GoLang 的生態(tài)豐富，選擇 Envoy 的用戶主要是看重其高性能的網(wǎng)絡(luò)處理能力及社區(qū)的活躍度。那我們是否能夠通過技術(shù)的手段將其二者優(yōu)勢融為一體，發(fā)揮各自的特長，不要讓用戶顧此失彼。

二、單一的 Proxy，無法支撐其架構(gòu)的演進(jìn)

在 Proxy 層面，無論是 MOSN 還是 Envoy 都是在各自領(lǐng)域中發(fā)揮優(yōu)勢。隨著云原生技術(shù)的快速發(fā)展和成熟以及業(yè)務(wù)的增長，既要 Proxy 能夠具備高研發(fā)效能，還要具備高處理性能，而單一的 Proxy 已經(jīng)無法滿足當(dāng)前業(yè)務(wù)架構(gòu)上的持續(xù)演進(jìn)。

• 東西向和南北向數(shù)據(jù)面 Proxy 逐步統(tǒng)一：兩套數(shù)據(jù)面定位不同但功能上存在一定重疊，導(dǎo)致維護成本高，未來需要逐步收斂。這就要求 Proxy 不僅具備易擴展性方便業(yè)務(wù)方擴展東西向業(yè)務(wù)上的流量治理能力，而且還要具備抗高并發(fā)的能力滿足南北向高流量轉(zhuǎn)發(fā)。

• Service Mesh 部署形態(tài)逐步向 Node 化架構(gòu)演進(jìn)：Service Mesh 規(guī)模化后，由于多出的 Proxy 勢必會導(dǎo)致一定資源上的浪費，那在中心化和 Mesh 化之間做一次折中，即通過 Node 化部署形態(tài)來解決。Node 化后就要求 Proxy 能夠高效、穩(wěn)定的承載多個 POD 的流量治理。

• Service Mesh 需要同時具備 Application Runtime 能力：雖然 Service Mesh 解決了微服務(wù)治理的痛點，但在實際業(yè)務(wù)開發(fā)中，緩存、數(shù)據(jù)庫、消息隊列、配置管理等，仍然需要維護一套重量級的 SDK 并且侵入應(yīng)用代碼。目前業(yè)界的解決方案是在 Service Mesh 的基礎(chǔ)上多引入一個 Proxy 如 Dapr 來解決，這就導(dǎo)致應(yīng)用的 POD 需要維護多個容器，所以如何讓 Service Mesh 的 Proxy 具備快速復(fù)用 Dapr 能力成為解決該問題的關(guān)鍵。

我們的思考

針對上述問題分析過后，其實背后的原因是有共性的。比如將其統(tǒng)一為一個 sidecar，如果單純的從一個數(shù)據(jù)面改為另一個，那其中的改造成本是巨大的。那是否可以換個思路，為 MOSN 的網(wǎng)絡(luò)層增加可擴展性，即可以讓 MOSN 的網(wǎng)絡(luò)處理直接下沉至 Envoy，同時將這個能力剝離出來成為 Envoy 在 GoLang 上的一個標(biāo)準(zhǔn)能力，這樣就能夠讓 Envoy 和 MOSN 互相復(fù)用已有的能力。二者相互融合，各取所長，使其同時具備高研發(fā)效能和處理性能高，自然而然就解決上述“單一的 Proxy，無法支撐架構(gòu)的演進(jìn)”和“社區(qū)生態(tài)，如何最大化求同存異”所面臨的問題。相互融合后，不僅融合了各種的優(yōu)勢，而且也能夠把兩邊的生態(tài)打通，借此 MOSN 社區(qū)和 Envoy 社區(qū)能形成雙贏的局面。

方案調(diào)研與分析

知道當(dāng)前面臨問題的原因后，便有了一個宏觀的解決方向。于是就對此展開了相關(guān)調(diào)研，梳理了業(yè)界針對此問題的一些解決方案，綜合各種方案的優(yōu)劣勢并結(jié)合螞蟻業(yè)務(wù)現(xiàn)狀以及開源社區(qū)用戶的痛點進(jìn)行了分析和評估。

擴展方案調(diào)研

擴展方案評估

通過上述方案優(yōu)劣勢的對比以及評估，MOE（MOSN on Envoy） 相比 ext-proc 無需跨進(jìn)程 gRPC 通信，性能高，易管理；相比 Envoy WASM 擴展無需網(wǎng)絡(luò) IO 操作轉(zhuǎn)換成本；相比 Lua 擴展生態(tài)好、能復(fù)用現(xiàn)有的 SDK，對于處理上層業(yè)務(wù)更合適。

同時我們將 Envoy 中增加 GoLang 擴展的這個方案也在 Envoy 社區(qū)進(jìn)行了討論，也得到了 Envoy 社區(qū) Maintainer 的贊同。其中依賴的技術(shù) CGO 是 GoLang 官方出品，該技術(shù)基本上在 GoLang 每個 release notes 中都有提到，說明也一直在維護的。另外業(yè)界也有很多項目在使用這項技術(shù)（比如：NanoVisor、Cilium、NginxUnit、Dragonboat、Badger、Go withOpenCV etc）其穩(wěn)定性已經(jīng)過一定的考驗了，同時我們自己也測試了 CGO 自身的開銷在 0.08 ~ 1.626 微秒，而且調(diào)用開銷也是屬于線性增長而非指數(shù)增長趨勢。

所以綜合穩(wěn)定性、性能、改造成本以及社區(qū)生態(tài)等因素評估，MOE 解決方案無論在當(dāng)前階段還是未來都具備一定優(yōu)勢。

方案介紹

一、整體架構(gòu)

如下是 MOE 的整體架構(gòu)圖，最下面是各種高性能數(shù)據(jù)面，目前我們主要適配的是 Envoy。在數(shù)據(jù)面之上剝離了一層 GoLang L7 extension filter 的抽象，用于和底層的數(shù)據(jù)面連通；然后在 MOSN 側(cè)通過 GoLang L7 extension SDK 將 MOSN 連通；最后通過 CGO 這個通道將 Envoy 和 MOSN 打通。

整體架構(gòu)如上圖所示，其核心包括如下三部分組成：

• GoLang L4/L7 extension filter

  使用 C++ 實現(xiàn)的 Envoy 側(cè)的 GoLang L4/L7 filter ，該模塊通過 CGO API 來調(diào)用 GoLang 實現(xiàn)的 L4/L7 extension filter。

• GoLang L4/L7 extension SDK

  GoLang L4/L7 extension SDK 會導(dǎo)出一些 CGO API，用于 Golang L4/L7 extension filter 和 L4/L7 extension GoLang filter 交互。

• L4/L7 extension filter via GoLang

  L4/L7 extension filter 是 GoLang 語言開發(fā)的，用于對 Envoy 的請求或者響應(yīng)做一些處理，最終是運行在 Envoy 工作線程之中。

二、功能職責(zé)

通過上面對整體架構(gòu)的介紹，應(yīng)該對 MOE 有了一個宏觀上的認(rèn)識。接下來我們通過功能職責(zé)方面來介紹下 MOE 中 MOSN 和 Envoy 是如何各司其職的：整體思路就是充分發(fā)揮 GoLang 的高研發(fā)效能以及 Envoy 在網(wǎng)絡(luò)層的高性能特性，所以在 MOSN 側(cè)來擴展上層業(yè)務(wù)的服務(wù)治理能力，復(fù)用 Envoy 底層高效的 Eventloop 網(wǎng)絡(luò)模型。

MOSN 側(cè)做業(yè)務(wù)擴展：擴展非 xDS 服務(wù)發(fā)現(xiàn)、擴展 L4/L7 filter、擴展 Xprotocol 支持、Debug 及 Admin 管理、Metrics 監(jiān)控統(tǒng)計；

Envoy 側(cè)復(fù)用基礎(chǔ)能力：復(fù)用高效 Eventloop 模型、復(fù)用 xDS 服務(wù)元數(shù)據(jù)通道、復(fù)用 L4/L7 filter、復(fù)用 Cluster LB、復(fù)用 State 統(tǒng)計。

三、工作流程

通過使用 GoLang 在 Envoy 中實現(xiàn)的“TraceID 事例”來介紹 Envoy GoLang extension 的工作流程：

1、請求/響應(yīng)到達(dá) Envoy 后，通過 GoLang L7 extension filter 將請求/響應(yīng)信息通過 API 封裝為特定格式；

2、然后將其封裝后的結(jié)構(gòu)體通過 CGO API 傳遞給 GoLang extension framework；

3、該框架收到數(shù)據(jù)后將會執(zhí)行 Trace ID filter（GoLang 實現(xiàn)的 Filter，用于生成一個 trace id 請求 header）；

4、當(dāng) GoLang filter 執(zhí)行完成后，會把處理后的信息通過特定的結(jié)構(gòu)體返回給 GoLang L7 extension filter；

5、GoLang L7 extension filter 收到返回的特定結(jié)構(gòu)體信息后，將其操作生效到當(dāng)前請求/響應(yīng)。

其中在上述的(1、2、4、5)步驟中涉及到 Envoy 和 GoLang 的交互協(xié)議、(2、4)中涉及到 Envoy 和 GoLang 之間的內(nèi)存如何管理、(2)中阻塞操作處理，接下來是這些問題的解決方案：

• 交互協(xié)議（1、2、4、5）

  將 Envoy 的請求使用 GoLang L7 extension filter 的 proxy_golang API(GoLang L7 extension SDK)進(jìn)行封裝，然后通過 CGO 通知 GoLang 側(cè)的 filter manager 進(jìn)行處理，其流程如下圖所示：

  當(dāng) Envoy 側(cè)收到請求后，將請求的 header、body、trailer 封裝為 CGO_Request 類型，然后調(diào)用 proxy_golang_on_request，GoLang filter 處理后的結(jié)果會封裝為 CGO_Response 返回給 Envoy 繼續(xù)處理。當(dāng) Envoy 側(cè)收到響應(yīng)后，將響應(yīng)的 header、body、trailer 封裝為 CGO_Resquest 類型，然后調(diào)用 proxy_golang_on_response，GoLang filter 處理后的結(jié)果會封裝為 CGO_Response 返回給 Envoy 繼續(xù)處理。同時我們也期望可以和 Envoy、Cilium、WASM 社區(qū)合作共建這套 API 規(guī)范，這樣可以使得多個擴展方案底層依賴的 API 能夠標(biāo)準(zhǔn)化。

• 內(nèi)存管理（2、4）

  請求鏈路（CGO Request）

  問題：將 Envoy 中的請求信息如何高效的傳送給 GoLang，應(yīng)該避免無效的內(nèi)存拷貝操作。

  方案：將 GoLang 中使用的 header、body 等信息直接指向 Envoy 的請求 header、body 的指針，這樣請求從 Envoy 到達(dá) GoLang 就不需要拷貝。

  響應(yīng)鏈路（CGO Response）

  問題：請求在 GoLang 側(cè)執(zhí)行完成后，將處理結(jié)果返回給 Envoy，如果直接使用 GoLang 返回的內(nèi)存是不安全的，因為 GoLang 中的內(nèi)存可能會被 GC。

  方案：把 GoLang 中生成的 CGO_Response 對象儲到全局的 map 中，通過請求 id 進(jìn)行映射，待 Envoy 使用完后，在將其對應(yīng)的結(jié)構(gòu)體從 map 中刪除。

• 阻塞處理（2）

  首先 Envoy 的事件模型是異步非阻塞的，如果 GoLang 實現(xiàn)的 HTTP filter 存在阻塞操作需要如何處理？

  對于純計算(非阻塞)或請求鏈路中的旁路阻塞操作，按照正常流程執(zhí)行即可。對于阻塞操作，通過 GoLang 的 goroutine（協(xié)程） 結(jié)合 Envoy 的 event loop callback 機制來解決：

  1、當(dāng)請求傳遞到 GoLang 側(cè)后，如果發(fā)現(xiàn) GoLang 實現(xiàn)的 filter 中有阻塞操作；

  2、則 GoLang 側(cè)會立刻啟動一個 goroutine 用來執(zhí)行阻塞操作，同時會立刻返回，并告知 Envoy 需要異步操作；

  3、Envoy 收到該消息后，則會停止該請求上的 filter 處理，然后繼續(xù)處理其他的請求；

  4、當(dāng) Golang 側(cè)的阻塞操作執(zhí)行完成后，則會通過 dispatcher post 一個事件告訴 Envoy 繼續(xù)處理該請求。

除了上述我們在 GoLang 側(cè)自身程序出現(xiàn)同步導(dǎo)致的阻塞外，是否還有其他場景？

我們都知道 GoLang 程序是 GMP 模型的，CGO 也是要遵守的，當(dāng) Envoy 通過 CGO 執(zhí)行 MOSN(GoLang)，此時 P 的數(shù)量如何管理？M 從哪來？

M 的問題比較好解決，由于宿主程序是 C 系列的，所以會把當(dāng)前 Envoy 線程通過 GoLang runtime 的 needm 來偽裝成一個 M。其次就是 P 這個資源比較關(guān)鍵，如果此時沒有空閑的 P 此時就會卡主 CGO 執(zhí)行，雖然目前我們生產(chǎn)上還未出現(xiàn)該問題，但是還是有這個可能性的。所以目前我們想到的解決方案就是為 Envoy 每個 worker thread 都預(yù)留對應(yīng)的 P，保證每次 CGO 的時候都可以找到 P 資源。

服務(wù)相關(guān)元數(shù)據(jù)如何管理

MOSN 和 Envoy 的相關(guān)服務(wù)元數(shù)據(jù)信息，是如何交互管理的?通過擴展 Envoy 中的 Admin API 使其支持 xDS 同等功能的 API, MOSN 集成的 Service Discovery 組件通過該 API(rest http) 和 Envoy 交互。使其 MOE 的服務(wù)發(fā)現(xiàn)能力也具備“雙模”能力，可同時滿足大規(guī)模及云原生的服務(wù)發(fā)現(xiàn)通道。

如何 Debug

MOSN 和 Envoy 相互融合后，在運行時變?yōu)橐粋€進(jìn)程了，那之前的可觀測性以及調(diào)試如何保障？關(guān)于可觀測性方面這塊可以直接復(fù)用 MOSN 和 Envoy 自帶 admin API 及 metrics 功能，關(guān)于兩者之間的交互層我們增加了每次交互的耗時以及異常下的容災(zāi)保護。最后就是關(guān)于一個程序即有 C++ 又有 GoLang 如何便捷性調(diào)試的問題，對此我們調(diào)研了相關(guān)方案，通過 net/rpc 網(wǎng)絡(luò)庫模擬? CGO 的調(diào)用，使得用戶調(diào)試 GoLang 側(cè)和之前 Native GoLang 一樣的方式調(diào)試即可。

方案總結(jié)

MOE 借助 CGO 通道不僅將 Envoy 和 MOSN 二者優(yōu)勢融為一體，而且將 GoLang 生態(tài)集成進(jìn) Envoy 變成了可能。在研發(fā)效能方面通過將 MOSN 作為 Envoy 的動態(tài)庫，上層業(yè)務(wù)改動只需編譯 GoLang 代碼即可，極大的提升了編譯速度，同時也增強了 Envoy 的自身擴展能力，使其能夠方便復(fù)用 MOSN 中現(xiàn)有的服務(wù)治理能力。性能方面，MOE 復(fù)用 Envoy 的高效網(wǎng)絡(luò)通道，之間的數(shù)據(jù)拷貝實現(xiàn)了 Zero Copy 可為 Dapr、Layotto 等提供高效網(wǎng)絡(luò)通道，同時 Envoy 使用 C++/C 系可方便的集成硬件加速能力。關(guān)于在服務(wù)元數(shù)據(jù)通道方面，MOE 即可復(fù)用 Envoy 原生的 xDS 又可以方便的集成 GoLang Discovery SDK 實現(xiàn)多種服務(wù)元數(shù)據(jù)通道支持。最后 MOE 不僅單純的將兩個軟件的優(yōu)勢做了加法，更重要的是使得 MOSN/GoLang 可以和 Envoy 生態(tài)拉通，實現(xiàn)多社區(qū)技術(shù)共享。

開源共建及展望

秉著借力開源，反哺開源的思路。當(dāng)我們對 MOE 方案 POC 驗證可行性后，我們也將這個思路在 MOSN 和 Envoy 社區(qū)展開了相關(guān)的 A proposal of high-performance L7 network GoLang extension for Envoy 討論。在得到 Envoy maintainer 的認(rèn)可后，我們也在主導(dǎo)關(guān)于使用 GoLang 來擴展 Envoy 的提案：Envoy's GoLang extension proposal ，歡迎大家參與進(jìn)來討論。

另外，近期我們也在設(shè)計 MOE 具備 L4 的 GoLang 擴展能力，這樣可方便使得 Envoy 集成 Layotto 或 Dapr 能力，從而同一個 sidecar 可具備 Service Mesh 與 Application runtime 能力，解決一個應(yīng)用部署多個 Sidecar 導(dǎo)致的運維復(fù)雜性問題。

方案實施效果

踩坑記錄

前面我們對 MOE 從整體架構(gòu)、功能職責(zé)以及工作流程做了詳細(xì)的介紹，看似整體流程是可以跑通了。但是在我們落地實踐的過程中也是遇到了不少問題。

下面這個列子就是在 MOE 工程中剝離出來的一個問題的最小復(fù)現(xiàn)場景，當(dāng)時我們在 CGO 傳遞數(shù)據(jù)的過程中，為了方便我們直接在 C++ 側(cè)通過指針來保存 header 的長度，當(dāng)其傳遞到 GoLang 側(cè)的時候，運行著運行著就 panic 掉了，如下所示：

通過分析后，發(fā)現(xiàn)是由于 GoLang 的函數(shù)棧在運行時觸發(fā)了棧擴容操作，從而會觸發(fā) GoLang runtime 對當(dāng)前函數(shù)棧上的指針做了一系列操作。對上述問題有影響的操作包括兩個：其一是會對當(dāng)前棧上的指針指向的地址做判斷，檢查是否是一個安全的地址；其二是判斷當(dāng)前棧上的指針指向的地址是否位于即將要擴容或者縮容的函數(shù)棧空間范圍內(nèi)，如果在該范圍，則會根據(jù)擴縮容函數(shù)棧后的偏移量直接修改指針指向的地址。然而在我們的場景中，直接使用指針來存儲長度，這將導(dǎo)致 runtime 中的第一個操作檢查不通過，直接拋異常。雖然當(dāng)時我們通過調(diào)整 GoLang runtime invalidPtr 來繞過第一個檢查報錯，但一旦我們所記錄的長度正好和函數(shù)棧地址空間有交集的話，那對應(yīng)長度的值也是會被修改的，所以也是不能滿足的。最后通過修改了長度的傳遞存儲方式來解決該問題。

由于篇幅有限，本文就不對所有問題進(jìn)行展開了，整體來說遇到的問題還是非常有趣的，對此感興趣或有疑問的歡迎找我們交流。

最佳實踐

從 2021 年 1 月到 3 月期間我們進(jìn)行了 MOE 的方案設(shè)計到編碼實現(xiàn)，并在 2 月份在 gRPC 網(wǎng)關(guān)集群進(jìn)行了小規(guī)模試點，各項指標(biāo)都正常，MOE 雛形方案得到了線上真實流量的驗證。于是 3 月份的時候我們就找到兄弟團隊相關(guān)同學(xué)討論：今年有一個目標(biāo)需要全站資源成本優(yōu)化，我們基礎(chǔ)設(shè)施是不是可以做點什么？所以就順利成章的引出了 MOE 合作契機，經(jīng)過幾輪討論以及簡單的 POC 驗證后決定在經(jīng)濟體互通網(wǎng)關(guān)場景，將內(nèi)部的一個 Native Go 實現(xiàn)的網(wǎng)關(guān)基于 MOE 架構(gòu)來替代螞蟻側(cè)的互通網(wǎng)關(guān)。其部署架構(gòu)如下圖所示(目前互通網(wǎng)關(guān)螞蟻側(cè)已經(jīng)在灰度中)：

雙方目標(biāo)達(dá)成一致后，就準(zhǔn)備開干了。雖然 MOE 雛形之前已經(jīng)踩過一些坑了，但是在實際適配的過程中還是多多少少遇到了一些問題，那最終我們也趕在了 6.18 這個時間點前進(jìn)行了灰度上線。如下引自第一個基于 MOE 架構(gòu)來替換網(wǎng)關(guān)的實踐 —《融合 Envoy 和 Go 語言生態(tài)打造高性能網(wǎng)關(guān)》，后續(xù)會有相關(guān)文章，敬請關(guān)注。

經(jīng)過這樣一番“折騰”，最終新版本基于 MOE 的網(wǎng)關(guān)在 6.18 活動前上線，并承擔(dān)了總體流量的 10%，整體表現(xiàn)平穩(wěn)，符合預(yù)期，現(xiàn)在逐步擴大引流中（截止 7 月 2 號引進(jìn)引流到 30% 左右）。從我們的壓測數(shù)據(jù)上看，相較于老版本，CPU 使用率和請求 RT 都有顯著下降，在TCP 連接數(shù)越高的場景，優(yōu)勢越明顯，總體上能夠取得 2.6~4.3 倍的 QPS 性能提升。

總結(jié)

MOE 技術(shù)方案使得 MOSN/GoLang 和 Envoy 相互融合成為了可能，打破了 MOSN/GoLang 和 Envoy 割裂的社區(qū)生態(tài)現(xiàn)狀，為將來 Proxy 的持續(xù)演進(jìn)奠定了堅實的技術(shù)基礎(chǔ)。隨著在經(jīng)濟體互通螞蟻側(cè)網(wǎng)關(guān)的落地實踐，其 MOE 技術(shù)方案的穩(wěn)定性、可靠性、易用性等方面都得到了一定的考驗。同時秉著對技術(shù)的高標(biāo)準(zhǔn)要求以及能夠更好的服務(wù)好我們的用戶，我們也會持續(xù)探索和優(yōu)化 MOE，如果該方案能也夠解決你業(yè)務(wù)上遇到的問題，歡迎聯(lián)系我們，最后感謝正在關(guān)注此項技術(shù)的用戶，歡迎和我們交流和討論！MOSN 用戶交流群釘釘群號：33547952。

推薦閱讀

• MOSN 多協(xié)議擴展開發(fā)實踐

• MOSN 子項目 Layotto：開啟服務(wù)網(wǎng)格+應(yīng)用運行時新篇

• 金融級能力成核心競爭力，服務(wù)網(wǎng)格驅(qū)動企業(yè)創(chuàng)新

• Protocol Extension Base On Wasm——協(xié)議擴展篇

總結(jié)

以上是生活随笔為你收集整理的开启云原生 MOSN 新篇章 — 融合 Envoy 和 Golang 生态的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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