作者 |  李志信 

一、什么是 Proxyless Service-Mesh (無代理服務(wù)網(wǎng)格) ?

1.Service Mesh 簡析

Istio 是當(dāng)今最流行的開源服務(wù)網(wǎng)格。它由控制平面和數(shù)據(jù)平面構(gòu)成，其架構(gòu)如下(圖片摘自 Istio官網(wǎng))。

位于圖中下半部分的控制平面負(fù)責(zé)配置、服務(wù)信息、證書等資源的下發(fā)。位于上半部分的數(shù)據(jù)平面關(guān)注業(yè)務(wù)之間的通信流量;傳統(tǒng)服務(wù)網(wǎng)格通過代理的方式攔截所有的業(yè)務(wù)網(wǎng)絡(luò)流量，代理需要感知到控制平面下發(fā)的配置資源，從而按照要求控制網(wǎng)絡(luò)流量的走向。

在 Istio 環(huán)境中，其控制平面是一個(gè)名為 istiod 的進(jìn)程，網(wǎng)絡(luò)代理是 envoy 。istiod 通過監(jiān)聽 K8S 資源 例如Service、Endpoint 等，獲取服務(wù)信息，并將這些資源統(tǒng)一通過 XDS 協(xié)議下發(fā)給位于數(shù)據(jù)平面的網(wǎng)絡(luò)代理。envoy 是一個(gè)獨(dú)立的進(jìn)程，以 sidecar(邊車)的形式伴隨業(yè)務(wù)應(yīng)用 Pod 運(yùn)行，他與應(yīng)用進(jìn)程共用同一個(gè)主機(jī)網(wǎng)絡(luò)，并通過修改路由表的方式，劫持業(yè)務(wù)應(yīng)用的網(wǎng)絡(luò)流量。

Service Mesh 可以解決微服務(wù)場景下的眾多問題，隨著集群規(guī)模的擴(kuò)大與業(yè)務(wù)復(fù)雜度的增長，基于原生 k8s 的容器編排方案將會難以應(yīng)付，開發(fā)人員不得不面對巨大的服務(wù)治理挑戰(zhàn)。而 Service Mesh 很好地解決了這一問題，它將服務(wù)治理需求封裝在了控制平面與代理中，業(yè)務(wù)開發(fā)人員只需要關(guān)注于業(yè)務(wù)邏輯。在應(yīng)用部署之后，只需要運(yùn)維人員通過修改配置，即可實(shí)現(xiàn)例如故障恢復(fù)、負(fù)載均衡、灰度發(fā)布等功能，這極大地提高了研發(fā)和迭代效率。

Istio 的 sidecar 通過容器注入的形式伴隨業(yè)務(wù)應(yīng)用進(jìn)程的整個(gè)生命周期，對于業(yè)務(wù)應(yīng)用是毫無侵入的，這解決了業(yè)務(wù)應(yīng)用可遷移、多語言、基礎(chǔ)架構(gòu)耦合等問題。但這也帶來了高資源消耗、請求時(shí)延增長的問題。

Service 為服務(wù)治理提供了一個(gè)很好的思路，將基礎(chǔ)架構(gòu)與業(yè)務(wù)邏輯解耦，讓應(yīng)用開發(fā)人員只需關(guān)注業(yè)務(wù)。另一方面，由于 sidecar 的弊端，我們可以考慮使用 sdk 的形式，來替代 sidecar 支撐起數(shù)據(jù)平面。

2.Proxyless Service-Mesh

無代理服務(wù)網(wǎng)格，是2018年谷歌提出的一個(gè)新的概念，Isito、gRPC、brpc 等開源社區(qū)都在這一方向進(jìn)行了探索和實(shí)踐。無代理服務(wù)網(wǎng)格框架以 SDK 的形式被業(yè)務(wù)應(yīng)用引入，負(fù)責(zé)服務(wù)之間的通信、治理。來自控制平面的配置直接下發(fā)至服務(wù)框架，由服務(wù)框架代替上述 sidecar 的功能。

在無代理服務(wù)網(wǎng)格場景下，服務(wù)框架(SDK)的主要能力可以概括為以下三點(diǎn)：

• 對接控制平面，監(jiān)聽配置資源。
• 對接應(yīng)用，為開發(fā)者提供方便的接口。
• 對接網(wǎng)絡(luò)，根據(jù)資源變動，響應(yīng)流量規(guī)則。

3.Proxyless 的優(yōu)缺點(diǎn)

我認(rèn)為優(yōu)點(diǎn)如下：

• 性能：無代理模式的網(wǎng)絡(luò)調(diào)用為點(diǎn)對點(diǎn)的直接通信，網(wǎng)絡(luò)時(shí)延會比代理模式小很多。
• 穩(wěn)定性：proxyless 的模式是單進(jìn)程，拓?fù)浜唵危阌谡{(diào)試，穩(wěn)定性高。
• 框架集成：市面上已有眾多 sdk 模式的服務(wù)框架，切換至 mesh 后便于復(fù)用框架已有能力
• 資源消耗：沒有 sidecar，資源消耗低。

當(dāng)然，缺點(diǎn)也有很多：

• 語言綁定：需要開發(fā)多種語言的 sdk
• 可遷移性低：無法通過切換 sidecar 的形式來無侵入地升級基礎(chǔ)設(shè)施。

總體來講，我認(rèn)為 Proxyless 架構(gòu)以其高性能、高穩(wěn)定性的特點(diǎn)，更適合與生產(chǎn)環(huán)境使用。

二、Dubbo-go 與 Proxyless Service-Mesh

1.Dubbo-go 的能力

Apache/Dubbo-go (github.com/apache/dubbo-go)，是一款分布式 RPC 框架，是 Apache/Dubbo 的 Go 語言實(shí)現(xiàn)。旨在為開發(fā)者提供便利的微服務(wù)應(yīng)用開發(fā)體驗(yàn)。Dubbo-go 生態(tài)為 Go 開發(fā)者提供了敏捷的微服務(wù)編程接口、配置管理方案、服務(wù)治理方案、以及一系列工具與腳手架，開發(fā)人員可以使用框架提供的能力快速開發(fā)自己的微服務(wù)應(yīng)用。

2.Dubbo-go 在 Proxyless Service-Mesh 場景的設(shè)計(jì)

服務(wù)注冊發(fā)現(xiàn)

Dubbo-go 本身擁有可擴(kuò)展的服務(wù)注冊發(fā)現(xiàn)能力，我們?yōu)?service mesh 場景適配了注冊中心的實(shí)現(xiàn)。開發(fā)人員可以將 dubbo-go 應(yīng)用的信息注冊在 istiod 控制平面上?？蛻舳藨?yīng)用可以查詢已經(jīng)注冊的接口數(shù)據(jù)，完成服務(wù)發(fā)現(xiàn)過程。

歸因于 Java 的編程習(xí)慣，Dubbo-go 生態(tài)框架的服務(wù)注冊方式都是接口級別的。即客戶端只需要引入接口，即可發(fā)起調(diào)用，而無需關(guān)心下游的應(yīng)用名、主機(jī)名、IP 地址等信息。與之相對的是應(yīng)用級別的服務(wù)注冊發(fā)現(xiàn)，主流微服務(wù)框架更多這種形式的服務(wù)調(diào)用方式，例如 gRPC、K8S、Istio，應(yīng)用級服務(wù)發(fā)現(xiàn)對應(yīng)到 mesh 場景下，我認(rèn)為叫 “主機(jī)級別服務(wù)發(fā)現(xiàn)”更合適，這種調(diào)用方式需要客戶端在引入接口的同時(shí)，還需引入下游的主機(jī)名和端口號。熟悉 gRPC-go 的同學(xué)一定很清楚，除了引入 pb 接口，還需要在創(chuàng)建客戶端時(shí)調(diào)用 gRPC.Dial("xxx") 建立網(wǎng)絡(luò)連接。而這里的 xxx 就是下游的主機(jī)名和端口號，這種服務(wù)發(fā)現(xiàn)的類型和用戶編程習(xí)慣，導(dǎo)致了 gRPC 較為輕松地實(shí)踐了 Proxyless Service Mesh。

關(guān)于應(yīng)用級服務(wù)發(fā)現(xiàn)與接口級服務(wù)發(fā)現(xiàn)的區(qū)別和 dubbo 生態(tài)的解決方案，本文中不多贅述，可以參考劉軍前輩寫的文章文章《Dubbo 邁出云原生重要一步 應(yīng)用級服務(wù)發(fā)現(xiàn)解析》簡單來說，應(yīng)用級服務(wù)發(fā)現(xiàn)需要開發(fā)者關(guān)心接口之外還要關(guān)心應(yīng)用名，注冊中心的冗余信息較少;接口級服務(wù)發(fā)現(xiàn)開發(fā)者只需要引入接口名，但注冊中心的冗余信息較多。

熟悉 Dubbo-go、Dubbo 生態(tài)的用戶，不習(xí)慣于在編程的過程中指定下游主機(jī)名，更希望以接口引入的方式，直接發(fā)起 RPC 調(diào)用，而不需關(guān)心究竟這個(gè)接口被哪個(gè)應(yīng)用實(shí)現(xiàn)，運(yùn)行在哪臺主機(jī)、哪個(gè)虛擬集群上。

Dubbo-go 為了融入 Istio 體系，將擴(kuò)展出來的注冊發(fā)現(xiàn)流程進(jìn)行了特殊改造。在復(fù)用 Istio 提供的 EDS、CDS 主機(jī)發(fā)現(xiàn)的能力之外，增加了接口名到主機(jī)名的映射，作為源數(shù)據(jù)注冊在了控制平面上?？蛻舳嗽诎l(fā)起調(diào)用前持有接口名，通過查詢istiod 上的元數(shù)據(jù)信息，拿到接口名到主機(jī)名到映射，轉(zhuǎn)換為主機(jī)名;再通過EDS、CDS和路由，完成主機(jī)名到下游端點(diǎn)實(shí)例的轉(zhuǎn)換。完成服務(wù)發(fā)現(xiàn)流程。

下面用一個(gè)更詳細(xì)的例子來說明服務(wù)發(fā)現(xiàn)過程：

• 開發(fā)人員使用 dubbogo-cli 工具創(chuàng)建應(yīng)用模板，發(fā)布 Deployment / Service pair 到集群中。
• 服務(wù)端拉取全量 CDS 和 EDS 數(shù)據(jù)，比對本機(jī) IP，拿到當(dāng)前應(yīng)用的的主機(jī)名。并將本應(yīng)用的所有接口名到主機(jī)名的映射，注冊在 Istiod 上面。
• 客戶端從 istiod 拉取全量接口名到主機(jī)名的映射，緩存在本地。當(dāng)需要發(fā)起調(diào)用時(shí)，查詢本地緩存，將接口名轉(zhuǎn)換為主機(jī)名，再通過CDS 和 EDS 拉取到當(dāng)前 cluster 所對應(yīng)的全量端點(diǎn)。
• 全量端點(diǎn)經(jīng)過 Dubbo-go 內(nèi)置的 Mesh Router，篩選出最終的端點(diǎn)子集，并按照配置的負(fù)載均衡策略進(jìn)行請求。
• 開發(fā)人員或者第三方組件，通過操作 K8S 資源，控制 Dubbo-go 流量。

縱觀這一過程，開發(fā)人員全程只需要關(guān)注接口即可，完全無需關(guān)心主機(jī)名和端口信息。即服務(wù)端開發(fā)者只需要實(shí)現(xiàn)pb接口，使用框架暴露出來;客戶端開發(fā)者只需要引入pb接口，直接發(fā)起調(diào)用即可，可以跟隨本文第四部分的教程來動手實(shí)驗(yàn)一下。

流量治理

Dubbo-go 擁有路由能力，通過 xds 協(xié)議客戶端從 istiod 訂閱路由配置，并實(shí)時(shí)更新至本地路由規(guī)則，從而實(shí)現(xiàn)服務(wù)的管理。Dubbo-go 兼容 Istio 生態(tài)的流量治理規(guī)則，可以通過配置 Virtual Service 和 Destination Rule，將打標(biāo)的流量路由至指定子集，也可以在灰度發(fā)布、切流等場景進(jìn)行更深入地使用。

云原生腳手架

dubbogo-cli 是 Apach/dubbo-go 生態(tài)的子項(xiàng)目，為開發(fā)者提供便利的應(yīng)用模板創(chuàng)建、工具安裝、接口調(diào)試等功能，以提高用戶的研發(fā)效率。

可以執(zhí)行以下指令安裝dubbogo-cli 至 $GOPATH/bin

go install github.com/dubbogo/dubbogo-cli@latest

dubbogo-cli 支持以下能力：

• 應(yīng)用模板創(chuàng)建
• Demo 創(chuàng)建
• 編譯、調(diào)試工具安裝
• 查看 dubbo-go 應(yīng)用注冊信息
• 調(diào)試 dubbo-go 應(yīng)用接口
• 使用應(yīng)用模板的開發(fā)流程
• 通過 dubbogo-cli 生成模板
• 修改api/api.proto
• make proto-gen
• 開發(fā)接口
• 修改 makefile 內(nèi)鏡像名和發(fā)布名
• 打鏡像并推送
• 修改chart/app/values 內(nèi)與部署相關(guān)的value配置
• make deploy, 使用 helm 發(fā)布應(yīng)用。

詳情可以參閱 dubbogo-cli 文檔[1]。

三、Dubbo-go-Mesh 的優(yōu)勢

1.接口級服務(wù)發(fā)現(xiàn)

前文介紹到了通過接口級服務(wù)注冊發(fā)現(xiàn)的優(yōu)勢，即開發(fā)人員無需關(guān)心下游主機(jī)名和端口號，只需要引入接口存根，或?qū)崿F(xiàn)接口，通過框架啟動即可。

2.高性能

我們在 k8s 集群內(nèi)部署 Istio 環(huán)境，分別測試了 sidecar 模式的 gRPC 服務(wù)調(diào)用和 Proxyless 模式的 dubbo-go 應(yīng)用服務(wù)調(diào)用。發(fā)現(xiàn) proxyless 在請求耗時(shí)方面比 sidecar 模式少一個(gè)數(shù)量級，即性能提升十倍左右。

3.跨生態(tài)

Dubbo-go 是一個(gè)橫跨多個(gè)生態(tài)的服務(wù)框架。

mesh 生態(tài)開發(fā)人員可以使用 Dubbo-go 進(jìn)行應(yīng)用開發(fā)的同時(shí)，使用 Istio 生態(tài)所提供的強(qiáng)大能力。

• gRPC 生態(tài)

Dubbo-go 支持與 gRPC 服務(wù)互通，HTTP2 協(xié)議棧。

Dubbo-go 默認(rèn)使用 pb 序列化方式，高性能。

• Dubbo 生態(tài)

多語言優(yōu)勢，可以實(shí)現(xiàn) go-java 應(yīng)用互通。

兼容 pixiu 網(wǎng)關(guān)，方便地進(jìn)行服務(wù)的暴露和協(xié)議轉(zhuǎn)換。

使用 Dubbo-go 生態(tài)組件。

四、動手體驗(yàn) Dubbo-go-Mesh

Dubbo-go 目前已支持兼容 Istio 的服務(wù)治理能力。支持基于 Istio 的接口級服務(wù)發(fā)現(xiàn)能力，兼容 Istio 生態(tài)的流量控制和管理能力，并且提供了腳手架和應(yīng)用模板以提高 Go 應(yīng)用開發(fā)效率。

您可參考文檔 【Dubbo-go 文檔 - Mesh 任務(wù)】[2]，動手搭建一組 Dubbo-go Mesh 應(yīng)用。

在這組任務(wù)中，開發(fā)者會從部署 Istio 環(huán)境開始，到創(chuàng)建應(yīng)用模板、構(gòu)建應(yīng)用、發(fā)布應(yīng)用、實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和 RPC、到最終完成流量規(guī)則動態(tài)配置，觀察流量切換。對框架用戶有較高的參考意義。

五、展望

Proxyless Service Mesh 能力將跟隨 Dubbo-go 下一版本發(fā)布，穩(wěn)定的性能需要社區(qū)成員們共同的關(guān)注與建設(shè)。在此基礎(chǔ)之上，我們還會進(jìn)一步探索輕量級 sdk + sidecar的模型;探索基于第三方流量治理組件的金絲雀發(fā)布能力;探索基于 dubbo 服務(wù)框架的多語言 sevice mesh、與更豐富的 mesh 生態(tài)組件兼容。

Dubbo-go 也將繼續(xù)在云原生的方向前進(jìn)，繼續(xù)發(fā)掘云計(jì)算時(shí)代技術(shù)紅利，與開發(fā)者同在。

[1]:https://dubbogo.github.io/zh-cn/docs/user/refer/use_dubbogo_cli.html[2]:https://dubbogo.github.io/zh-cn/docs/user/tasks/mesh/app.html