作者 | 王程銘

一、背景

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

二、什么是 Service Mesh

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 概念的說法而言，最開始是谷歌提出來的。03?

三、Dubbo Proxyless Mesh

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 模式下。

1.環境準備

• 安裝 docker?

https://www.docker.com/

• 安裝 minikube?

墻裂推薦：https://kubernetes.io/zh-cn/docs/tutorials/hello-minikube/

• 安裝 istio?

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

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

參考命令如下：

curl -L https://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

2.代碼準備

這里我們直接復用官方提供的 sample，代碼地址：https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-xds到目前為止我們的環境和代碼就全都準備完畢了！03

3.構建鏡像

（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 .

（5）檢查本地鏡像?

（6）創建 namespace

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

# 切換命名空間
kubens dubbo-demo

如果不創建 namespace，那么會看到如下錯誤：

4.部署容器

# 找到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

5.觀察 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 和云原生等領域。?