作者 | 王程銘

一、背景

隨著 Dubbo 3.1 的 release，Dubbo 在云原生的路上又邁出了重要的一步。在這個(gè)版本中添加了 Proxyless Mesh 的新特性，Dubbo Proxyless Mesh 直接實(shí)現(xiàn) xDS 協(xié)議解析，實(shí)現(xiàn) Dubbo 與 Control Plane 的直接通信，進(jìn)而實(shí)現(xiàn)控制面對(duì)流量管控、服務(wù)治理、可觀測(cè)性、安全等的統(tǒng)一管控，規(guī)避 Sidecar 模式帶來的性能損耗與部署架構(gòu)復(fù)雜性。02?

二、什么是 Service Mesh

Service Mesh 又譯作 “服務(wù)網(wǎng)格”，作為服務(wù)間通信的基礎(chǔ)設(shè)施層。Buoyant 公司的 CEO Willian Morgan 在他的文章《WHAT’S A Service Mesh? AND WHY DO I NEED ONE? 》中解釋了什么是 Service Mesh，為什么云原生應(yīng)用需要 Service Mesh。

下面是 Willian Morgan 對(duì) 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.

翻譯成中文是：服務(wù)網(wǎng)格（Service Mesh）是處理服務(wù)間通信的基礎(chǔ)設(shè)施層。它負(fù)責(zé)構(gòu)成現(xiàn)代云原生應(yīng)用程序的復(fù)雜服務(wù)拓?fù)鋪砜煽康亟桓墩?qǐng)求。在實(shí)踐中，Service Mesh 通常以輕量級(jí)網(wǎng)絡(luò)代理陣列的形式實(shí)現(xiàn)，這些代理與應(yīng)用程序代碼部署在一起，對(duì)應(yīng)用程序來說無需感知代理的存在。說到 Service Mesh 一定離不開 Sidecar 經(jīng)典架構(gòu)模式。它通過在業(yè)務(wù) Pod 中注入 Sidecar 容器，接管業(yè)務(wù)容器的通信流量，同時(shí) Sidecar 容器與網(wǎng)格平臺(tái)的控制平面對(duì)接，基于控制平面下發(fā)的策略，對(duì)代理流量實(shí)施治理和管控，將原有服務(wù)框架的治理能力下層到 Sidecar 容器中，從而實(shí)現(xiàn)了基礎(chǔ)框架能力的下沉，與業(yè)務(wù)系統(tǒng)解耦。

經(jīng)典的 Sidecar Mesh 部署架構(gòu)有很多優(yōu)勢(shì)，如平滑升級(jí)、多語言、業(yè)務(wù)侵入小等，但也帶來了一些額外的問題，比如：

• Proxy 帶來的性能損耗，在復(fù)雜拓?fù)涞木W(wǎng)絡(luò)調(diào)用中將變得尤其明顯
• 流量攔截帶來的架構(gòu)復(fù)雜性
• Sidecar 生命周期管理
• 部署環(huán)境受限，并不是所有環(huán)境都滿足 Sidecar 流量攔截條件 

針對(duì) Sidecar Mesh 模型的問題，Dubbo 社區(qū)自很早之前就做了 Dubbo 直接對(duì)接到控制面的設(shè)想與思考，并在國(guó)內(nèi)開源社區(qū)率先提出了 Proxyless Mesh 的概念，當(dāng)然就 Proxyless 概念的說法而言，最開始是谷歌提出來的。03?

三、Dubbo Proxyless Mesh

Dubbo Proxyless 模式是指 Dubbo 直接與 Istiod 通信，通過 xDS 協(xié)議實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)和服務(wù)治理等能力。

Proxyless 模式使得微服務(wù)又回到了 2.x 時(shí)代的部署架構(gòu)，同 Dubbo 經(jīng)典服務(wù)治理模式非常相似，所以說這個(gè)模式并不新鮮， Dubbo 從最開始就是這樣的設(shè)計(jì)模式。這樣做可以極大的提升應(yīng)用性能，降低網(wǎng)絡(luò)延遲。有人說這種做法又回答了原始的基于 SDK 的微服務(wù)模式，其實(shí)非也，它依然使用了 Envoy 的 xDS API，但是因?yàn)椴辉傩枰驊?yīng)用程序中注入 Sidecar 代理，因此可以減少應(yīng)用程序性能的損耗。

Tips：對(duì)應(yīng)的發(fā)現(xiàn)服務(wù)及其相應(yīng)的 API 被稱作 xDS

但相比于 Mesh 架構(gòu)，Dubbo 經(jīng)典服務(wù)治理模式并沒有強(qiáng)調(diào)控制面的統(tǒng)一管控，而這點(diǎn)恰好是 Service Mesh 所強(qiáng)調(diào)的，強(qiáng)調(diào)對(duì)流量、可觀測(cè)性、證書等的標(biāo)準(zhǔn)化管控與治理，也是 Mesh 理念先進(jìn)的地方。

在 Dubbo Proxyless 架構(gòu)模式下，Dubbo 進(jìn)程將直接與控制面通信，Dubbo 進(jìn)程之間也繼續(xù)保持直連通信模式，我們可以看出 Proxyless 架構(gòu)的優(yōu)勢(shì)：

• 沒有額外的 Proxy 中轉(zhuǎn)損耗，因此更適用于性能敏感應(yīng)用
• 更有利于遺留系統(tǒng)的平滑遷移
• 架構(gòu)簡(jiǎn)單，容易運(yùn)維部署
• 適用于幾乎所有的部署環(huán)境 

四、服務(wù)發(fā)現(xiàn)

xDS 接入以注冊(cè)中心的模式對(duì)接，節(jié)點(diǎn)發(fā)現(xiàn)同其他注冊(cè)中心的服務(wù)自省模型一樣，對(duì)于 xDS 的負(fù)載均衡和路由配置通過 ServiceInstance 的動(dòng)態(tài)運(yùn)行時(shí)配置傳出，在構(gòu)建 Invoker 的時(shí)候?qū)⑴渲脜?shù)傳入配置地址。

五、證書管理

零信任架構(gòu)下，需要嚴(yán)格區(qū)分工作負(fù)載的識(shí)別和信任，而簽發(fā) X.509 證書是推薦的一種認(rèn)證方式。在 Kubernetes 集群中，服務(wù)間是通過 DNS 名稱互相訪問的，而網(wǎng)絡(luò)流量可能被 DNS 欺騙、BGP/路由劫持、ARP 欺騙等手段劫持，為了將服務(wù)名稱（DNS 名稱）與服務(wù)身份強(qiáng)關(guān)聯(lián)起來，Istio 使用置于 X.509 證書中的安全命名機(jī)制。SPIFFE 是 Istio 所采用的安全命名的規(guī)范，它也是云原生定義的一種標(biāo)準(zhǔn)化的、可移植的工作負(fù)載身份規(guī)范。Secure Production Identity Framework For Everyone (SPIFFE) 是一套服務(wù)之間相互進(jìn)行身份識(shí)別的標(biāo)準(zhǔn)，主要包含以下內(nèi)容：

• SPIFFE ID 標(biāo)準(zhǔn)，SPIFFE ID 是服務(wù)的唯一標(biāo)識(shí)，具體實(shí)現(xiàn)使用 URI 資源標(biāo)識(shí)符
• SPIFFE Verifiable Identity Document (SVID) 標(biāo)準(zhǔn)，將 SPIFFE ID 編碼到一個(gè)加密的可驗(yàn)證的數(shù)據(jù)格式中
• 頒發(fā)與撤銷 SVID 的 API 標(biāo)準(zhǔn)（SVID 是 SPIFFE ID 的識(shí)別憑證）

SPIFFE ID 規(guī)定了形如 spiffe://<trust domain>/<workload identifier> 的 URI 格式，作為工作負(fù)載（Workload）的唯一標(biāo)識(shí)。而 Istio 在自身的生態(tài)中只使用到了 SPIFFE ID 作為安全命名，其數(shù)據(jù)格式由自己實(shí)現(xiàn)，通信格式采用 CNCF 支持的 xDS 協(xié)議規(guī)范（證書認(rèn)證通信更具體來說是 xDS 的 SDS）。Istio 使用特定格式的 SPIFFE ID 作為安全命名，注入到 X.509 證書的 subjectAltName 擴(kuò)展中。其中"trust_domain"參數(shù)通過 Istiod 環(huán)境變量 TRUST_DOMAIN 注入，用于在多集群環(huán)境中交互。?

特定格式形如：spiffe://<trust_domain>/ns/<namespace>/sa/<service_account> 

?以下是 Dubbo Proxyless Mesh 證書頒發(fā)的過程：

• 創(chuàng)建 RSA 私鑰
• 構(gòu)建 CSR（Certificate signing request）模板
• 自簽名 CSR 生成證書
• 創(chuàng)建 Kubernetes Secret 資源儲(chǔ)存 CA 證書和私鑰（CA Service 處理） 

六、案例實(shí)踐

接下來我將帶領(lǐng)大家通過一個(gè)例子使已有的項(xiàng)目快速跑在 Proxyless Mesh 模式下。

1.環(huán)境準(zhǔn)備

• 安裝 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 的時(shí)候需要開啟 first-party-jwt 支持（使用 istioctl 工具安裝的時(shí)候加上 --set values.global.jwtPolicy=first-party-jwt 參數(shù)），否則將導(dǎo)致客戶端認(rèn)證失敗的問題。

參考命令如下：

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.代碼準(zhǔn)備

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

3.構(gòu)建鏡像

（1）啟動(dòng) docker?

（2）啟動(dòng) minikube?

因?yàn)?minikube 是一個(gè)本地的 K8s，他啟動(dòng)需要一個(gè)虛擬引擎，這里我們用 docker 來管理。我們通過如下命令啟動(dòng)

minikube start

我們可以在 docker 里看到 minikube

（3）檢查 istio 的狀態(tài)?

（4）構(gòu)建鏡像?

在本地找到代碼所在位置、依次執(zhí)行以下命令：

# 找到provider所在路徑
cd ./dubbo-samples-xds-provider/
# 構(gòu)建provider的鏡像
docker build -t apache/dubbo-demo:dubbo-samples-xds-provider_0.0.1 .

# 找到consumer所在路徑
cd ../dubbo-samples-xds-consumer/
# 構(gòu)建consumer的鏡像
docker build -t apache/dubbo-demo:dubbo-samples-xds-consumer_0.0.1 .

（5）檢查本地鏡像?

（6）創(chuàng)建 namespace

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

# 切換命名空間
kubens dubbo-demo

如果不創(chuàng)建 namespace，那么會(huì)看到如下錯(cuò)誤：

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 看到我們已經(jīng)部署的 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

七、總結(jié)&展望

本文主要剖析了 Dubbo Proxyless Mesh 的架構(gòu)、服務(wù)發(fā)現(xiàn)以及證書管理等核心流程，最后通過示例給大家演示了如何使用 Dubbo Proxyless。

隨著 Dubbo 3.1 的 release，Dubbo 在云原生的路上又邁出了重要的一步。在今年年底，Dubbo Mesh 將發(fā)布具有服務(wù)發(fā)現(xiàn)能力的版本，屆時(shí)將面向所有 Dubbo 用戶提供從低版本平滑遷移到 Mesh 架構(gòu)的能力；在明年年初春季的時(shí)候?qū)l(fā)布帶有治理能力的版本；在明年年底前發(fā)布帶熱插件更新能力的版本，希望有興趣見證 Dubbo 云原生之路的同學(xué)可以積極參與社區(qū)貢獻(xiàn)！

作者介紹

王程銘，螞蟻金服工程師、Apache Dubbo Committer、關(guān)注 RPC、Service Mesh 和云原生等領(lǐng)域。?