MOSN 多協(xié)議擴(kuò)展開發(fā)實(shí)踐

Service Mesh 是當(dāng)今云原生的關(guān)鍵部分，螞蟻已經(jīng)在生產(chǎn)環(huán)境完成了大規(guī)模的落地，但是業(yè)界整體 Service Mesh 改造程度還不高。其中平穩(wěn)的進(jìn)行 Mesh 化改造是可以對(duì)已上線的業(yè)務(wù)進(jìn)行 Mesh 化改造的前提，在平穩(wěn)改造過程中，協(xié)議的支持又是最基礎(chǔ)的部分。MOSN 提供的多協(xié)議擴(kuò)展開發(fā)框架旨在降低使用私有協(xié)議的場景進(jìn)行 Mesh 化改造的成本，幫助業(yè)務(wù)快速落地。

MOSN 是螞蟻?zhàn)匝械囊豢罡咝阅芫W(wǎng)絡(luò)代理，主要用于 Service Mesh 的數(shù)據(jù)面 Sidecar。Service Mesh，是近幾年來云原生方向比較熱門的話題，其主旨就是構(gòu)建一個(gè)基礎(chǔ)設(shè)施層，用來負(fù)責(zé)服務(wù)之間的通信。主要就是有一個(gè)和服務(wù)應(yīng)用共同部署的 Sidecar 來實(shí)現(xiàn)各種中間件的基礎(chǔ)能力，實(shí)現(xiàn)基礎(chǔ)設(shè)施的標(biāo)準(zhǔn)化、和業(yè)務(wù)邏輯解耦，做到業(yè)務(wù)無感知的基礎(chǔ)能力快速演進(jìn)。目前國內(nèi)很多公司都開始擁抱 Service Mesh，和螞蟻合作的一些企業(yè)，如中信銀行、江西農(nóng)信等也基于 MOSN 完成了 Mesh 化的改造。

Service Mesh 架構(gòu)的目的就是為了降低基礎(chǔ)設(shè)施改造升級(jí)對(duì)業(yè)務(wù)造成的影響，但是如何平滑的從傳統(tǒng)微服務(wù)架構(gòu)轉(zhuǎn)向 Service Mesh 架構(gòu)也是一個(gè)非常有挑戰(zhàn)的工作，這里涉及的細(xì)節(jié)很多，但是無論如何有一個(gè)最基礎(chǔ)的問題就是我們?cè)谶M(jìn)行灰度 Mesh 化改造的時(shí)候，已經(jīng) Mesh 化的節(jié)點(diǎn)需要能和沒有 Mesh 化的節(jié)點(diǎn)維持正常通信。而不同的公司選擇的通信協(xié)議都有所不同，這就直接導(dǎo)致在技術(shù)選型的時(shí)候，選擇的 Sidecar 需要能夠支持所使用的協(xié)議。一些受到廣泛應(yīng)用的協(xié)議可能還會(huì)被陸續(xù)的支持，而有的協(xié)議可能還是公司自己定制的，因此不可避免的是需要基于 Sidecar 的擴(kuò)展能力，進(jìn)行二次開發(fā)以支持私有的協(xié)議。

談到 Service Mesh 的 Sidecar，就不得不提到 Envoy，這是一款被廣泛應(yīng)用的 Service Mesh Sidecar 代理。Envoy 的擴(kuò)展框架支持開發(fā)者進(jìn)行二次開發(fā)擴(kuò)展，其中 Envoy 目前支持的不少協(xié)議就是基于其擴(kuò)展框架開發(fā)實(shí)現(xiàn)的。在 Envoy 的擴(kuò)展框架下，要擴(kuò)展一個(gè)協(xié)議可以參考 Envoy 中 HTTP 協(xié)議處理的流程，包括 4 層 Filter 實(shí)現(xiàn)編解碼部分與 Connection Manager 部分，在 Connection Manager 的基礎(chǔ)上再實(shí)現(xiàn) 7 層的 Filter 用于支持額外的業(yè)務(wù)擴(kuò)展、路由的能力、和 Upstream 的連接池能力?？梢钥吹揭粋€(gè)協(xié)議處理的流程幾乎是貫穿了各種模塊，實(shí)現(xiàn)一個(gè)協(xié)議擴(kuò)展成本還是比較高的。

再來看一下 MOSN 的框架。MOSN 在一次協(xié)議處理上可以劃分為四個(gè)層次，除開基本的從網(wǎng)絡(luò) IO 中獲取數(shù)據(jù)的網(wǎng)絡(luò)層以外，還可以劃分為 protocol 層、stream 層與 proxy 層。其中 protocol 層負(fù)責(zé)協(xié)議解析相關(guān)編解碼的工作，負(fù)責(zé)將數(shù)據(jù)流解析成 MOSN 可以理解的協(xié)議幀，或者將協(xié)議幀編碼成二進(jìn)制流；stream 層負(fù)責(zé)的內(nèi)容就比較多了，包括處理不同的請(qǐng)求類型，初始化請(qǐng)求的上下文，關(guān)聯(lián)事件，響應(yīng)與請(qǐng)求之間的關(guān)聯(lián)，還有 upstream 連接池相關(guān)的處理等，不同的協(xié)議處理的細(xì)節(jié)也會(huì)有所不同；proxy 層是一個(gè)協(xié)議無關(guān)的代理轉(zhuǎn)發(fā)層，負(fù)責(zé)請(qǐng)求的路由與負(fù)責(zé)均衡等能力，同時(shí)也具備七層的擴(kuò)展能力用于不同業(yè)務(wù)實(shí)現(xiàn)的擴(kuò)展。根據(jù)這個(gè)架構(gòu)，可以看到協(xié)議處理的核心就在于 protocol 層和 stream 層，相比于 Envoy 的設(shè)計(jì)來說，路由、七層擴(kuò)展等部分是具備多協(xié)議復(fù)用的能力的。但是同時(shí)也可以看到 stream 層涉及的細(xì)節(jié)比較多，實(shí)現(xiàn)起來難度也是比較大的，為此 MOSN 在此基礎(chǔ)上又提出了一個(gè)多協(xié)議擴(kuò)展的框架，用于簡化協(xié)議的實(shí)現(xiàn)。

MOSN 的多協(xié)議框架主要就是針對(duì) stream 層的復(fù)用擴(kuò)展能力，在 MOSN 的協(xié)議處理分層設(shè)計(jì)中， network 層和 proxy 層在設(shè)計(jì)上就是協(xié)議無關(guān)可復(fù)用的，如果能做到 stream 層也進(jìn)行復(fù)用，那么協(xié)議實(shí)現(xiàn)就只需要關(guān)注 protocol 層的編解碼本身，實(shí)現(xiàn)難度就會(huì)大大降低了。那么 stream 層是不是具備可復(fù)用的能力的呢，我們認(rèn)為對(duì)于大部分協(xié)議，尤其是 RPC 協(xié)議來說是可以的。首先我們對(duì)協(xié)議進(jìn)行一個(gè)抽象，定義成 XProtocol 接口，表示任意的協(xié)議。每個(gè)協(xié)議實(shí)現(xiàn)都是實(shí)現(xiàn)一個(gè) XProtocol 接口，它包括基礎(chǔ)的編解碼接口、一些特殊請(qǐng)求響應(yīng)的構(gòu)造接口（如心跳、異常）、還有協(xié)議的模型（如類似 HTTP 的 pingpong 模型，常見的 RPC 多路復(fù)用模型等），以及協(xié)議匹配的接口。所有的 XProtocol 協(xié)議實(shí)現(xiàn)通過 XProtocol Engine 關(guān)聯(lián)起來，除了通過配置指定使用哪種協(xié)議進(jìn)行處理以外，對(duì)于實(shí)現(xiàn)了協(xié)議匹配接口的協(xié)議來說，可以基于請(qǐng)求特征進(jìn)行自動(dòng)識(shí)別。然后我們對(duì)于 XProtocol 解析出的協(xié)議幀也進(jìn)行統(tǒng)一的抽象，包括多路復(fù)用相關(guān)的接口、協(xié)議類型的判斷（是請(qǐng)求，還是響應(yīng)，或者是類似 Goaway 一類的控制幀，請(qǐng)求又可以細(xì)分為心跳請(qǐng)求、無響應(yīng)的 oneway 請(qǐng)求等）、支持對(duì)協(xié)議幀的數(shù)據(jù)進(jìn)行修改（Header/Body 的修改）、還有統(tǒng)一的狀態(tài)碼管理映射等。

在 MOSN 的協(xié)議處理分層機(jī)制下，以及有了以 XProtocol 和 XFrame 的抽象定義為核心的多協(xié)議擴(kuò)展框架以后，我們?cè)?stream 層就可以完全基于接口進(jìn)行協(xié)議的處理，而不同的協(xié)議擴(kuò)展實(shí)現(xiàn)者只需要專注于協(xié)議編解碼本身，以及對(duì)編解碼后的結(jié)果進(jìn)行簡單的接口適配，就可以完成在 MOSN 中的接入，由此獲得 MOSN 中各種通用能力的支持，如限流擴(kuò)展、路由引流等。對(duì)比 Envoy 中擴(kuò)展協(xié)議實(shí)現(xiàn)部分可以看到是簡化了不少的。當(dāng)然 MOSN 這個(gè)多協(xié)議框架不能滿足所有的協(xié)議情況，但是對(duì)于目前我們看到的大部分 RPC 協(xié)議，在配合上 proxy 層中七層 stream filter 擴(kuò)展的基礎(chǔ)上，都是可以很好的滿足的。

下面以 MOSN 在社區(qū)合作伙伴中 Dubbo 協(xié)議落地的案例來詳細(xì)的了解 MOSN 的多協(xié)議擴(kuò)展。這里很多代碼也是 MOSN 社區(qū)的同學(xué)貢獻(xiàn)的。

在這個(gè)案例中，除了要求協(xié)議需要支持 Dubbo 以外，還希望使用像限流等這些基礎(chǔ)的擴(kuò)展能力，同時(shí)需要藍(lán)綠分組等路由的能力，選擇的控制面是 Istio，用于動(dòng)態(tài)配置的下發(fā)。那這些需求在 MOSN 中是如何實(shí)現(xiàn)的呢？

首先是協(xié)議解析部分，這里采用了基于開源的 dubbo-go 框架做協(xié)議實(shí)現(xiàn)，基于 dubbo-go 封裝出了 MOSN 的 XProtocol 和 XFrame 模型；限流、xDS 等能力直接復(fù)用 MOSN 已有的實(shí)現(xiàn)，無需額外實(shí)現(xiàn)。但是這里有一個(gè)問題點(diǎn)就是 Istio 動(dòng)態(tài)下發(fā)的路由配置是 HTTP 相關(guān)的，HTTP 的路由配置模型與 Dubbo 還是存在一定差異的，而修改 Istio 的成本會(huì)比較高，在這里就做了另外一層擴(kuò)展。基于 MOSN 七層的 StreamFilters，在進(jìn)行路由匹配之前對(duì) Dubbo 協(xié)議進(jìn)行定制化的處理，用來滿足 HTTP 的路由格式。主要有兩個(gè)點(diǎn)，一個(gè)是 HTTP 的 Host，使用 Dubbo 的 Service 對(duì)應(yīng)到 Host，另外一個(gè)是 HTTP 的 Path，這部分就直接添加一個(gè)默認(rèn)的 Path 進(jìn)行通配；同時(shí)在這個(gè)擴(kuò)展 Filter 中，還會(huì)獲取機(jī)器的 Labels 添加到 Header 中，用于匹配路由的藍(lán)綠分組功能。通過 MOSN Filter 擴(kuò)展的配合，我們?cè)趯?shí)現(xiàn)了標(biāo)準(zhǔn)的 Dubbo 協(xié)議支持的基礎(chǔ)上，滿足了使用 HTTP 路由配置方式滿足 Dubbo 路由的功能。

通過 MOSN 多協(xié)議框架的介紹，可以了解到當(dāng)一個(gè)場景需要接入 MOSN 還不支持的自定義協(xié)議的時(shí)候，就需要進(jìn)行擴(kuò)展實(shí)現(xiàn)，然后和 MOSN 的框架代碼一起進(jìn)行編譯，獲得一個(gè)支持自定義協(xié)議的 MOSN。雖然已經(jīng)盡量簡化了協(xié)議擴(kuò)展實(shí)現(xiàn)的復(fù)雜度，但是依然會(huì)存在一些問題，比如我們商業(yè)版的代碼中，不同的合作伙伴，對(duì)應(yīng)不同的場景，使用的都是不同的協(xié)議，那么隨著業(yè)務(wù)的發(fā)展，協(xié)議這部分相關(guān)的代碼就會(huì)越來越多，對(duì)應(yīng)的開發(fā)維護(hù)代價(jià)也會(huì)變大。這都還好說，還有一些場景，客戶協(xié)議一些細(xì)節(jié)出于某些需求可能并不想把相關(guān)的實(shí)現(xiàn)代碼提交到 MOSN 的倉庫中，而商業(yè)版代碼不同于開源的，可能也不能直接將源代碼交給客戶，那這里編譯就會(huì)遇到問題。為了解決這種矛盾，也為了更進(jìn)一步讓協(xié)議擴(kuò)展變得簡單，MOSN 還做了基于插件模式擴(kuò)展協(xié)議的能力。

MOSN 插件擴(kuò)展模式架構(gòu)如圖，MOSN 提供統(tǒng)一的插件擴(kuò)展框架能力，MOSN 獨(dú)立編譯成二進(jìn)制以后，利用插件機(jī)制動(dòng)態(tài)加載不同的協(xié)議擴(kuò)展插件，來獲得對(duì)應(yīng)的協(xié)議支持能力。這樣協(xié)議擴(kuò)展的實(shí)現(xiàn)也可以以插件的形式獨(dú)立維護(hù)，甚至更進(jìn)一步還可能支持非 Go 語言的擴(kuò)展，比如基于 WASM 擴(kuò)展能力對(duì)接其他語言實(shí)現(xiàn)的協(xié)議擴(kuò)展。MOSN 的插件擴(kuò)展能力有兩種模式，一個(gè)是基于 Go Plugin 機(jī)制的擴(kuò)展，一個(gè)是基于 WASM 的擴(kuò)展。

首先來看一下 Go Plugin 的機(jī)制。這是 Go 語言提供的一種 SO 的加載能力，我們可以把 Go 編寫的代碼編譯成 SO，然后可以被其他 Go 文件加載。但是這個(gè)機(jī)制有一些比較大的局限性，首先一點(diǎn)就是主程序與擴(kuò)展插件編譯的 Go 環(huán)境必須一致，包括 Go 的版本，GoPath 等環(huán)境變量；另外一點(diǎn)就是主程序與擴(kuò)展插件依賴的庫必須一致，這個(gè)是精確到 Hash 的，就是說不是兩個(gè)庫接口是兼容就可以，而是必須一模一樣，這個(gè)限制就比較大了。因?yàn)槲覀冾A(yù)期是 MOSN 的代碼和協(xié)議擴(kuò)展的代碼互相獨(dú)立維護(hù)，協(xié)議擴(kuò)展代碼是需要依賴 MOSN 框架的，按照 Go Plugin 的機(jī)制每次 MOSN 框架的代碼改動(dòng)都會(huì)要求插件的代碼也同步更新再重新編譯插件，這個(gè)太麻煩了。

為此，我們將 MOSN 框架進(jìn)行了拆解，拆分出一些相對(duì)穩(wěn)定的接口和通用能力，作為 MOSN 主程序和協(xié)議擴(kuò)展共同依賴的基礎(chǔ)，如 XProtocol 和 XFrame 相關(guān)的 interface 定義單獨(dú)定義到了 API 這個(gè)庫中，然后在插件加載的時(shí)候，只需要將對(duì)應(yīng)的一些接口注冊(cè)到 MOSN 框架中就可以了。由于 API 定義和工具變動(dòng)相對(duì)較少，協(xié)議擴(kuò)展插件依賴從 MOSN 框架變成 MOSN 的 API 定義，最大程度的減少 MOSN 框架代碼更新導(dǎo)致的插件代碼必須更新的情況。而對(duì)于編譯環(huán)境這個(gè)就好辦了，我們提供了一個(gè)統(tǒng)一的、用于編譯的 docker 環(huán)境，只需要讓 MOSN 和插件都基于同樣的 docker 編譯就可以。通過 Go Plugin 實(shí)現(xiàn)的插件擴(kuò)展和直接將代碼合并然后編譯的結(jié)果是一樣的，只是讓協(xié)議擴(kuò)展的代碼可以獨(dú)立進(jìn)行維護(hù)。

再來看一下 WASM 的擴(kuò)展機(jī)制。簡單介紹一下 WASM，它是一個(gè)開發(fā)、高效、安全，并且擁有社區(qū)統(tǒng)一標(biāo)準(zhǔn)的一種擴(kuò)展能力，WASM 理論上是語言無關(guān)的一種能力，而且有一個(gè)被廣泛認(rèn)可的網(wǎng)絡(luò)代理場景的 ABI 規(guī)范，因?yàn)?MOSN 也支持了 WASM 的擴(kuò)展能力，它也能用于 MOSN 的協(xié)議擴(kuò)展。

MOSN 的 WASM 擴(kuò)展詳細(xì)介紹可以參考【WebAssembly 在 MOSN 中的實(shí)踐 - 基礎(chǔ)框架篇】。

基于 WASM 的協(xié)議擴(kuò)展方式，與之前提到的協(xié)議擴(kuò)展有所區(qū)別。WASM 插件需要實(shí)現(xiàn)的是 proxy-wasm 的 ABI 標(biāo)準(zhǔn)，而不用關(guān)心 MOSN 的多協(xié)議框架，也就是說這個(gè) WASM 插件理論上是還可以被用于其他遵循 proxy-wasm ABI 規(guī)范的應(yīng)用的。而在 MOSN 側(cè)，則是實(shí)現(xiàn)了一個(gè)名為 WASM Protocol 的膠水層，這個(gè)膠水層實(shí)現(xiàn)了 MOSN 多協(xié)議框架的封裝，然后通過 WASM ABI 與 WASM 插件進(jìn)行交互。在 MOSN 多協(xié)議框架的視角下，看到的是一個(gè)由 WASM Protocol 封裝的 XProtocol 實(shí)現(xiàn)，多協(xié)議框架也不理解 WASM ABI 交互的部分。和 GoPlugin 擴(kuò)展不同，目前 MOSN 的 WASM 框架也還處于初級(jí)階段，基于 WASM 的協(xié)議擴(kuò)展也還只有 POC，而出于穩(wěn)定性、性能等多方面因素的考慮，還沒有正式應(yīng)用在生產(chǎn)環(huán)境中，還需要更多的優(yōu)化和測試。

最后談一下 MOSN 在協(xié)議支持上后續(xù)的一些展望和計(jì)劃，主要就是包括更多類型的協(xié)議支持，如存在流式、雙工形式的 gRPC 協(xié)議、消息類型的協(xié)議如卡夫卡、MQ 等，還有就是將 WASM 的協(xié)議擴(kuò)展在生產(chǎn)環(huán)境落地可用。