作者 |  李志信 

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

1.Service Mesh 簡析

Istio 是當今最流行的開源服務網格。它由控制平面和數據平面構成，其架構如下(圖片摘自 Istio官網)。

位于圖中下半部分的控制平面負責配置、服務信息、證書等資源的下發。位于上半部分的數據平面關注業務之間的通信流量;傳統服務網格通過代理的方式攔截所有的業務網絡流量，代理需要感知到控制平面下發的配置資源，從而按照要求控制網絡流量的走向。

在 Istio 環境中，其控制平面是一個名為 istiod 的進程，網絡代理是 envoy 。istiod 通過監聽 K8S 資源 例如Service、Endpoint 等，獲取服務信息，并將這些資源統一通過 XDS 協議下發給位于數據平面的網絡代理。envoy 是一個獨立的進程，以 sidecar(邊車)的形式伴隨業務應用 Pod 運行，他與應用進程共用同一個主機網絡，并通過修改路由表的方式，劫持業務應用的網絡流量。

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

Istio 的 sidecar 通過容器注入的形式伴隨業務應用進程的整個生命周期，對于業務應用是毫無侵入的，這解決了業務應用可遷移、多語言、基礎架構耦合等問題。但這也帶來了高資源消耗、請求時延增長的問題。

Service 為服務治理提供了一個很好的思路，將基礎架構與業務邏輯解耦，讓應用開發人員只需關注業務。另一方面，由于 sidecar 的弊端，我們可以考慮使用 sdk 的形式，來替代 sidecar 支撐起數據平面。

2.Proxyless Service-Mesh

無代理服務網格，是2018年谷歌提出的一個新的概念，Isito、gRPC、brpc 等開源社區都在這一方向進行了探索和實踐。無代理服務網格框架以 SDK 的形式被業務應用引入，負責服務之間的通信、治理。來自控制平面的配置直接下發至服務框架，由服務框架代替上述 sidecar 的功能。

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

• 對接控制平面，監聽配置資源。
• 對接應用，為開發者提供方便的接口。
• 對接網絡，根據資源變動，響應流量規則。

3.Proxyless 的優缺點

我認為優點如下：

• 性能：無代理模式的網絡調用為點對點的直接通信，網絡時延會比代理模式小很多。
• 穩定性：proxyless 的模式是單進程，拓撲簡單，便于調試，穩定性高。
• 框架集成：市面上已有眾多 sdk 模式的服務框架，切換至 mesh 后便于復用框架已有能力
• 資源消耗：沒有 sidecar，資源消耗低。

當然，缺點也有很多：

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

總體來講，我認為 Proxyless 架構以其高性能、高穩定性的特點，更適合與生產環境使用。

二、Dubbo-go 與 Proxyless Service-Mesh

1.Dubbo-go 的能力

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

2.Dubbo-go 在 Proxyless Service-Mesh 場景的設計

服務注冊發現

Dubbo-go 本身擁有可擴展的服務注冊發現能力，我們為 service mesh 場景適配了注冊中心的實現。開發人員可以將 dubbo-go 應用的信息注冊在 istiod 控制平面上。客戶端應用可以查詢已經注冊的接口數據，完成服務發現過程。

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

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

熟悉 Dubbo-go、Dubbo 生態的用戶，不習慣于在編程的過程中指定下游主機名，更希望以接口引入的方式，直接發起 RPC 調用，而不需關心究竟這個接口被哪個應用實現，運行在哪臺主機、哪個虛擬集群上。

Dubbo-go 為了融入 Istio 體系，將擴展出來的注冊發現流程進行了特殊改造。在復用 Istio 提供的 EDS、CDS 主機發現的能力之外，增加了接口名到主機名的映射，作為源數據注冊在了控制平面上。客戶端在發起調用前持有接口名，通過查詢istiod 上的元數據信息，拿到接口名到主機名到映射，轉換為主機名;再通過EDS、CDS和路由，完成主機名到下游端點實例的轉換。完成服務發現流程。

下面用一個更詳細的例子來說明服務發現過程：

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

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

流量治理

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

云原生腳手架

dubbogo-cli 是 Apach/dubbo-go 生態的子項目，為開發者提供便利的應用模板創建、工具安裝、接口調試等功能，以提高用戶的研發效率。

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

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

dubbogo-cli 支持以下能力：

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

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

三、Dubbo-go-Mesh 的優勢

1.接口級服務發現

前文介紹到了通過接口級服務注冊發現的優勢，即開發人員無需關心下游主機名和端口號，只需要引入接口存根，或實現接口，通過框架啟動即可。

2.高性能

我們在 k8s 集群內部署 Istio 環境，分別測試了 sidecar 模式的 gRPC 服務調用和 Proxyless 模式的 dubbo-go 應用服務調用。發現 proxyless 在請求耗時方面比 sidecar 模式少一個數量級，即性能提升十倍左右。

3.跨生態

Dubbo-go 是一個橫跨多個生態的服務框架。

mesh 生態開發人員可以使用 Dubbo-go 進行應用開發的同時，使用 Istio 生態所提供的強大能力。

• gRPC 生態

Dubbo-go 支持與 gRPC 服務互通，HTTP2 協議棧。

Dubbo-go 默認使用 pb 序列化方式，高性能。

• Dubbo 生態

多語言優勢，可以實現 go-java 應用互通。

兼容 pixiu 網關，方便地進行服務的暴露和協議轉換。

使用 Dubbo-go 生態組件。

四、動手體驗 Dubbo-go-Mesh

Dubbo-go 目前已支持兼容 Istio 的服務治理能力。支持基于 Istio 的接口級服務發現能力，兼容 Istio 生態的流量控制和管理能力，并且提供了腳手架和應用模板以提高 Go 應用開發效率。

您可參考文檔 【Dubbo-go 文檔 - Mesh 任務】[2]，動手搭建一組 Dubbo-go Mesh 應用。

在這組任務中，開發者會從部署 Istio 環境開始，到創建應用模板、構建應用、發布應用、實現服務發現和 RPC、到最終完成流量規則動態配置，觀察流量切換。對框架用戶有較高的參考意義。

五、展望

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

Dubbo-go 也將繼續在云原生的方向前進，繼續發掘云計算時代技術紅利，與開發者同在。

[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