Proxyless Mesh 在 Dubbo 中的實踐

隨著 Dubbo 3.1 的 release，Dubbo 在雲原生的路上又邁出了重要的一步。在這個版本中添加了 Proxyless Mesh 的新特性，Dubbo Proxyless Mesh 直接實現 xDS 協議解析，實現 Dubbo 與 Control Plane 的直接通訊，進而實現控制面對流量管控、服務治理、可觀測性、安全等的統一管控，規避 Sidecar 模式帶來的效能損耗與部署架構複雜性。

Service Mesh 又譯作 “服務網格”，作為服務間通訊的基礎設施層。Buoyant 公司的 CEO Willian Morgan 在他的文章《WHAT’S A Service Mesh? AND WHY DO I NEED ONE? 》中解釋了什麼是 Service Mesh，為什麼雲原生應用需要 Service Mesh。

下面是 Willian Morgan 對 Service Mesh 的解釋：

A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

翻譯成中文是：

服務網格（Service Mesh）是處理服務間通訊的基礎設施層。它負責構成現代雲原生應用程式的複雜服務拓撲來可靠地交付請求。在實踐中，Service Mesh 通常以輕量級網路代理陣列的形式實現，這些代理與應用程式程式碼部署在一起，對應用程式來說無需感知代理的存在。

說到 Service Mesh 一定離不開 Sidecar 經典架構模式。它通過在業務 Pod 中注入 Sidecar 容器，接管業務容器的通訊流量，同時 Sidecar 容器與網格平臺的控制平面對接，基於控制平面下發的策略，對代理流量實施治理和管控，將原有服務框架的治理能力下層到 Sidecar 容器中，從而實現了基礎框架能力的下沉，與業務系統解耦。

經典的 Sidecar Mesh 部署架構有很多優勢，如平滑升級、多語言、業務侵入小等，但也帶來了一些額外的問題，比如：

• Proxy 帶來的效能損耗，在複雜拓撲的網路呼叫中將變得尤其明顯

• 流量攔截帶來的架構複雜性

• Sidecar 生命週期管理

• 部署環境受限，並不是所有環境都滿足 Sidecar 流量攔截條件

針對 Sidecar Mesh 模型的問題，Dubbo 社群自很早之前就做了 Dubbo 直接對接到控制面的設想與思考，並在國內開源社群率先提出了 Proxyless Mesh 的概念，當然就 Proxyless 概念的說法而言，最開始是谷歌提出來的。

Dubbo Proxyless 模式是指 Dubbo 直接與 Istiod 通訊，通過 xDS 協議實現服務發現和服務治理等能力。

Proxyless 模式使得微服務又回到了 2.x 時代的部署架構，同 Dubbo 經典服務治理模式非常相似，所以說這個模式並不新鮮， Dubbo 從最開始就是這樣的設計模式。這樣做可以極大的提升應用效能，降低網路延遲。有人說這種做法又回答了原始的基於 SDK 的微服務模式，其實非也，它依然使用了 Envoy 的 xDS API，但是因為不再需要嚮應用程式中注入 Sidecar 代理，因此可以減少應用程式效能的損耗。

Tips：對應的發現服務及其相應的 API 被稱作 xDS

但相比於 Mesh 架構，Dubbo 經典服務治理模式並沒有強調控制面的統一管控，而這點恰好是 Service Mesh 所強調的，強調對流量、可觀測性、證書等的標準化管控與治理，也是 Mesh 理念先進的地方。

在 Dubbo Proxyless 架構模式下，Dubbo 程序將直接與控制面通訊，Dubbo 程序之間也繼續保持直連通訊模式，我們可以看出 Proxyless 架構的優勢：

• 沒有額外的 Proxy 中轉損耗，因此更適用於效能敏感應用

• 更有利於遺留系統的平滑遷移

• 架構簡單，容易運維部署

• 適用於幾乎所有的部署環境

xDS 接入以註冊中心的模式對接，節點發現同其他註冊中心的服務自省模型一樣，對於 xDS 的負載均衡和路由配置通過 ServiceInstance 的動態執行時配置傳出，在構建 Invoker 的時候將配置引數傳入配置地址。

零信任架構下，需要嚴格區分工作負載的識別和信任，而簽發 X.509 證書是推薦的一種認證方式。在 Kubernetes 叢集中，服務間是通過 DNS 名稱互相訪問的，而網路流量可能被 DNS 欺騙、BGP/路由劫持、ARP 欺騙等手段劫持，為了將服務名稱（DNS 名稱）與服務身份強關聯起來，Istio 使用置於 X.509 證書中的安全命名機制。SPIFFE 是 Istio 所採用的安全命名的規範，它也是雲原生定義的一種標準化的、可移植的工作負載身份規範。

Secure Production Identity Framework For Everyone (SPIFFE) 是一套服務之間相互進行身份識別的標準，主要包含以下內容：

• SPIFFE ID 標準，SPIFFE ID 是服務的唯一標識，具體實現使用 URI 資源識別符號

• SPIFFE Verifiable Identity Document (SVID) 標準，將 SPIFFE ID 編碼到一個加密的可驗證的資料格式中

• 頒發與撤銷 SVID 的 API 標準（SVID 是 SPIFFE ID 的識別憑證）

SPIFFE ID 規定了形如 spiffe://<trust domain>/<workload identifier> 的 URI 格式，作為工作負載（Workload）的唯一標識。而 Istio 在自身的生態中只使用到了 SPIFFE ID 作為安全命名，其資料格式由自己實現，通訊格式採用 CNCF 支援的 xDS 協議規範（證書認證通訊更具體來說是 xDS 的 SDS）。

Istio 使用特定格式的 SPIFFE ID 作為安全命名，注入到 X.509 證書的 subjectAltName 擴充套件中。其中"trust_domain"引數通過 Istiod 環境變數 TRUST_DOMAIN 注入，用於在多叢集環境中互動。

特定格式 形 如：

spiffe://<trust_domain>/ns/<namespace>/sa/<service_account> 

以下是 Dubbo Proxyless Mesh 證書頒發的過程：

• 建立 RSA 私鑰

• 構建 CSR（Certificate signing request）模板

• 自簽名 CSR 生成證書

• 建立 Kubernetes Secret 資源儲存 CA 證書和私鑰（CA Service 處理）

接下來我將帶領大家通過一個例子使已有的專案快速跑在 Proxyless Mesh 模式下。

01

環境準備

• 安裝 docker

http://www.docker.com/

• 安裝 minikube

牆裂推薦：

http://kubernetes.io/zh-cn/docs/tutorials/hello-minikube/

• 安裝 istio

http://istio.io/latest/docs/setup/getting-started/

注：安裝 Istio 的時候需要開啟 first-party-jwt 支援（使用 istioctl 工具安裝的時候加上 --set values.global.jwtPolicy=first-party-jwt 引數），否則將導致客戶端認證失敗的問題。

參考命令如下：

curl -L http://istio.io/downloadIstio | sh -
cd istio-1.xx.x
export PATH=$PWD/bin:$PATH
istioctl install --set profile=demo --set values.global.jwtPolicy=first-party-jwt -y

02

程式碼準備

這裡我們直接複用官方提供的 sample，程式碼地址：

http://github.com/apache/dubbo-samples/tree/master/dubbo-samples-xds

到目前為止我們的環境和程式碼就全都準備完畢了！

03

構建映象

1. 啟動 docker

2. 啟動 minikube

因為 minikube 是一個本地的 K8s，他啟動需要一個虛擬引擎，這裡我們用 docker 來管理。我們通過如下命令啟動

minikube start

我們可以在 docker 裡看到 minikube

3. 檢查 istio 的狀態

4. 構建映象

在本地找到程式碼所在位置、依次執行以下命令：

# 找到provider所在路徑
cd ./dubbo-samples-xds-provider/
# 構建provider的映象
docker build -t apache/dubbo-demo:dubbo-samples-xds-provider_0.0.1 .

# 找到consumer所在路徑
cd ../dubbo-samples-xds-consumer/
# 構建consumer的映象
docker build -t apache/dubbo-demo:dubbo-samples-xds-consumer_0.0.1 .

<img data-backh="189" data-backw="578" data-ratio="0.3272532188841202" data-src="http://mmbiz.qpic.cn/sz_mmbiz_png/qdzZBE73hWukCrs0HwpU5kPfLepCJeiaKibxN7EHlTO011QXrP2n3cfnN6iatgeEt8jRxhdM4YW1LQGL1SQaeqXdg/640?wx_fmt=png" data-type="png" data-w="1864" style="width: 100%;height: auto;" width="932" />

5. 檢查本地映象

6. 建立 namespace

# 初始化名稱空間
kubectl apply -f http://raw.githubusercontent.com/apache/dubbo-samples/master/dubbo-samples-xds/deploy/Namespace.yml


# 切換名稱空間
kubens dubbo-demo

如果不建立 namespace，那麼會看到如下錯誤：

04

部署容器

# 找到provider所在路徑
cd ./dubbo-samples-xds-provider/src/main/resources/k8s
# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Deployment.yml
# dubbo-samples-xds/dubbo-samples-xds-provider/src/main/resources/k8s/Service.yml


# 部署provider的Deployment和Service
kubectl apply -f Deployment.yml
kubectl apply -f Service.yml

# 找到consumer所在路徑
cd ../../../../../dubbo-samples-xds-consumer/src/main/resources/k8s
# dubbo-samples-xds/dubbo-samples-xds-consumer/src/main/resources/k8s/Deployment.yml


# 部署consumer的Deployment
kubectl apply -f Deployment.yml

在 minikube dashboard 看到我們已經部署的 pod

05

觀察 consumer 效果

kubectl logs xxx

result: hello, xDS Consumer! from host: 172.17.0.5
result: hello, xDS Consumer! from host: 172.17.0.5
result: hello, xDS Consumer! from host: 172.17.0.6
result: hello, xDS Consumer! from host: 172.17.0.6

本文主要剖析了 Dubbo Proxyless Mesh 的架構、服務發現以及證書管理等核心流程，最後通過示例給大家演示瞭如何使用 Dubbo Proxyless。

隨著 Dubbo 3.1 的 release，Dubbo 在雲原生的路上又邁出了重要的一步。在今年年底，Dubbo Mesh 將釋出具有服務發現能力的版本，屆時將面向所有 Dubbo 使用者提供從低版本平滑遷移到 Mesh 架構的能力；在明年年初春季的時候將釋出帶有治理能力的版本；在明年年底前釋出帶熱外掛更新能力的版本，希望有興趣見證 Dubbo 雲原生之路的同學可以積極參與社群貢獻！

作者介紹

王程銘，螞蟻金服工程師、Apache Dubbo Committer、關注 RPC、Service Mesh 和雲原生等領域。