> Kubernetes 是當前全球最流行的容器服務平臺，在 Kubernetes 叢集中，Dubbo 應用的部署方式往往需要藉助第三方註冊中心實現服務發現。Dubbo 與 Kubernetes 的排程體系的結合，可以讓原本需要管理兩套平臺的運維成本大大減低，而且 Dubbo 適配了 Kubernetes 原生服務也可以讓框架本身更加融入雲原生體系。基於 Dubbo 3.0 的全新應用級服務發現模型可以更容易對齊 Kubernetes 的服務模型。

## Kubernetes Native Service

![1.png](https://ucc.alicdn.com/pic/developer-ecology/a89564b47ee849b7b85f7910b3601141.png)

在 Kubernetes 中，Pod 是可以在 Kubernetes 中建立和管理的、最小的可部署的計算單元。通常一個 Pod 由一個或多個容器組成，應用則部署在容器內。

對於一組具有相同功能的 Pod，Kubernetes 透過 Service 的概念定義了這樣一組 Pod 的策略的抽象，也即是 Kubernetes Service。這些被 Kubernetes Service 標記的 Pod 一般都是透過 Label Selector 決定的。

在 Kubernetes Service 內，服務節點被稱為 Endpoint，這些 Endpoint 也就是對應提供服務的應用單元，通常一對一對應了 Pod。

因此，我們可以將微服務中的應用本身使用 Service 來進行排程，而微服務間的呼叫透過 Service 的一系列機制來實現服務發現，進而將微服務整合進 Kubernetes Service 的體系中。

## Dubbo 應用級服務發現

在 Dubbo 體系結構內，為了更好地符合 Java 開發人員的程式設計習慣，Dubbo 底層以介面粒度作為註冊物件。但是這個模型對現在主流的 Spring Cloud 註冊模型和 Kubernetes Service 註冊模型有很大的區別。

目前在非 Dubbo 體系外的註冊模型主要是以服務粒度作為註冊物件，為了打通 Dubbo 與其他體系之間的註冊發現壁壘，Dubbo 在 2.7.5 版本以後引入了服務自省的架構，主要透過後設資料服務實現從服務粒度到介面粒度的過渡。在 2.7.5 版本以後到 3.0 版本，服務自省模型進行了很多方面的最佳化，並且在生產環境下進行了驗證。

### 1. 後設資料服務

![2.png](https://ucc.alicdn.com/pic/developer-ecology/9c2715143b1b40a086c052c0f413d17d.png)

後設資料服務主要是儲存了服務（Instance）與介面（Interface）的對映關係，透過將原本的寫入到註冊中心的介面資訊抽象到後設資料進行儲存，一方面可以大大減少註冊中心儲存的資料量、降低服務更新時叢集的網路通訊壓力，另一方面，實現了註冊中心層面只儲存應用粒度資訊的目標，對齊了其他註冊模型。

在服務自省模型中，服務提供者不僅僅往註冊中心寫入當前例項的資訊，還需要往（本地或者遠端的）後設資料服務寫入暴露的服務 URL 資訊等；而對於服務消費者，在從註冊中心獲取例項資訊後，還需要（透過 RPC 請求內建或者中心化配置中心獲取）後設資料服務獲取服務提供者的服務 URL 資訊等來生成介面粒度體系下的介面資訊。

### 2. Revision 資訊

![3.png](https://ucc.alicdn.com/pic/developer-ecology/37a0047a9ad447eaa3e69c207822760b.png)

Revision 資訊是後設資料服務引入的一種資料快取機制，對於同一組應用很多情況下暴露的介面其實都是一樣的，在進行服務（Instance）與介面（Interface）對映的時候會有許多重複的冗餘資料，因此可以使用類似對後設資料資訊進行 MD5 計算的方式來對例項本身加上版本號，如果多個例項的版本號一致可以認為它們的後設資料資訊也一致，那麼只需要隨機選擇一臺來獲取後設資料資訊即可，可以實現把通行量從一組例項都需要通訊到只需要與一個例項通訊的壓縮。

如上圖所示，服務消費者註冊中心的工作機制可以總結為：

- 服務消費者向註冊中心獲取服務例項列表。
- 註冊中心向服務消費者返回服務例項資訊，在例項列表中包括了服務提供者向註冊中心寫入的 Revision 引數。
- 服務消費者根據獲取到例項資訊的 Revision 引數進行分組，分別從每組例項中隨機選擇一臺獲取後設資料服務。
- 服務消費者透過 RPC 發起呼叫或者透過配置中心獲取得到指定例項的後設資料資訊。
- 服務消費者根據獲取到的後設資料資訊組建介面粒度的服務資訊。

關於應用級服務發現更多的資訊可以參考：《[Dubbo 邁出雲原生重要一步 - 應用級服務發現解析](https://mp.weixin.qq.com/s?__biz=MzU4NzU0MDIzOQ==&mid=2247489653&idx=1&sn=445692c491f68aed3f649730d3d9ba96&scene=21#wechat_redirect)》
![image.gif](https://intranetproxy.alipay.com/skylark/lark/0/2021/gif/285843/1611649527466-6924fd21-e14c-40e9-872f-3ab1faaedc97.gif#align=left&display=inline&height=1&margin=%5Bobject%20Object%5D&name=image.gif&originHeight=1&originWidth=1&size=70&status=done&style=none&width=1)

## 對接實現方式

本次實現的與 Kubernetes 對接的方式有兩種，一種是透過 Kubernetes API Client 的形式獲取資訊，另外一種是透過 DNS Client 的形式獲取。

### 1. Kubernetes API Client

Kubernetes 控制平面的核心是 API Server，API Server 提供了 HTTP API，以供使用者、叢集中的不同部分和叢集外部元件相互通訊。對於 Dubbo 來說，透過使用 Kubernetes API Client 便可以做到與 Kubernetes 控制平面通訊。

#### 1）Provider 側細節

![4.png](https://ucc.alicdn.com/pic/developer-ecology/edc29422ccd6458b98f16afcc035cb09.png)

根據前文說到 Dubbo 應用級服務發現模型，對於 Provider 側在應用啟動、介面更新時需要向註冊中心寫入 Revision 資訊，因此大致的邏輯如上圖所示。

Label 標籤作為 Selector 與 Service 進行匹配，Annotation 中則主要儲存了 Revision 等資訊，其中 Revision 資訊需要由 Dubbo 應用主動向 Kubernetes API Server 發起更新請求寫入，這也對應了服務註冊的流程。

在目前版本的實現中，Kubernetes Service 的建立工作是交由運維側實現的，也即是 Label Selector 是由運維側去管理的，在 Dubbo 應用啟動前就已經配置完畢了，Service 的名字也即是對應介面註解中的 Services 欄位（對於不依賴任何第三方配置中心的需要在介面級別手動配置此欄位）。

#### 2）Consumer 側細節

![5.png](https://ucc.alicdn.com/pic/developer-ecology/ac34cd1d4c264424b5c99ecd1a140f08.png)

對於 Consumer 側的邏輯大致上與應用級服務發現的模型設計的一樣，在透過 API 獲取到服務資訊後透過獲取對應 Pod 的 Annotation 資訊補齊 ServiceInstance  資訊，後續邏輯與服務自省一致。

#### 3）優缺點

- 需要指出的是，讓應用本身直接與 Kubernetes 管理平臺的 API 互動本身就存在一定安全隱患，如果配置不當有一定可能性導致拖垮整個 Kubernetes 叢集。
- 當應用大量更新時會給 Kubernetes API Server 帶來一定壓力。
- 本方案直接將 Dubbo 的服務發現過程對接到 Kubernetes 叢集的管理上，可以在 Kubernetes 環境下進一步簡化管理的複雜度。

### 2. DNS Client

Kubernetes DNS 是 Kubernetes 提供的一種透過 DNS 查詢的方式獲取 Kubernetes Service 資訊的機制，透過普通的 DNS 請求就可以獲取到服務的節點資訊。

#### 1）全去中心化的後設資料服務

由於 DNS 協議本身限制，目前並沒有一個統一的較為簡單的方式向 DNS 附加更多的資訊用於寫入 Revision 資訊。對於 DNS 的實現方案我們將後設資料服務進行了改造，使其不再強依賴往註冊中心寫入 Revision 資訊，實現只需要知道 Dubbo 應用的 IP 即可以實現正常的服務發現功能。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/948ca6cf2d7646e1810c621b04ff3410.png)

改造後的後設資料服務可以分為兩大功能，一個是基於 revision 的獲取 URL 資訊等的能力，另外一個是獲取對應 revision 的能力。Dubbo 服務消費者在透過註冊中心獲取到例項 IP 後會主動去與每一個例項的後設資料服務進行連線，獲取 revision 資訊後，對於 revision 資訊一致的例項隨機選擇一個去獲取完整的後設資料資訊。
由於 Revision 資訊採用了點對點的方式獲取，當這個資訊更新時要及時通知給消費者端進行更新。在當前版本的實現中，我們依賴了 引數回撥 機制實現服務者主動推送給消費者。未來會基於 3.0 的全新 Triple 協議，實現流式推送。

#### 2）Provider 側細節

與 Kubernetes API Client 實現方式類似的，組建服務的過程均需要由運維側進行，在服務提供者啟動的時候會進行後設資料資訊本地快取、對外暴露後設資料服務介面的機制。

這裡需要特別注意的是，為了使服務發現過程與業務服務本身解耦，後設資料服務介面與業務介面對應的埠可以不一致，在使用 DNS 實現方案的時候全叢集所有應用的後設資料服務埠都需要統一， 透過 metadataServicePort 引數進行配置。這樣亦可以適配那些不支援透過 SRV 獲取埠的 DNS。

#### 3）Consumer 側細節

![7.png](https://ucc.alicdn.com/pic/developer-ecology/66fa4ab5c5384efea8cf7018905c0642.png)

對於 DNS 註冊中心來說，獲取例項的流程主要透過向 DNS 發起 A （或 AAAA）查詢請求來獲取，而 Kubernetes DNS 也提供了 SRV 記錄請求來獲取服務的資訊。

結合前文說到的全去中心化的後設資料服務機制，Consumer 會去主動連線獲取到的每一個例項的後設資料服務，獲取對應的 Revision 資訊，同時以引數回撥的形式向提供者提交回撥函式用於更新本地資訊。

在獲取到 Revision 資訊之後，對於具有相同 Revision 資訊的例項，Dubbo 會隨機選擇其中一個獲取完整後設資料資訊，至此完成服務發現的全過程。

#### 4）優缺點

- 本方案與前一種方案對比起來避免了 Kubernetes API 的直接互動，避免了互動的安全問題。
- 由於 DNS 沒有像 API Watch 的通知機制，只能採用輪詢的方式判斷服務的變更，在沒有應用變更時叢集內仍有一定量的 DNS 網路查詢壓力。
- 本方案設計的時候目標是對任何只要能夠透過 A （或 AAAA）查詢獲取到 Dubbo 應用本身的 IP 的 DNS 都可以適配，對 Kubernetes DNS 並不是強依賴關係。

## 總結

本次 Dubbo 對接 Kubernetes 原生服務是 Dubbo 往雲原生化發展的一次嘗試，未來我們將基於 xDS 協議實現與 Service Mesh 控制平面的互動，相關功能正在緊鑼密鼓的籌劃中。同時，在未來 Dubbo 3.0 的發版上，Java 社群和 Dubbo-go 社群將同步發版，本次 Kubernetes 的功能也將對齊上線。

系列文章推薦：

- [《Dubbo 雲原生之路：ASF 畢業一週年、3.0 可期》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494485&idx=1&sn=3c5c813461d936e55684ecd80bfab464&chksm=fae6e09acd91698c50347614445577eb9e0990e163fab928b12d09dfed5bab15cbe9de52b971&scene=21#wechat_redirect)

- [《Dubbo 邁出雲原生重要一步 - 應用級服務發現解析》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491122&idx=1&sn=6c5529e6321a68ff107a5c7894eab599&chksm=fae515fdcd929cebe9928703a06c12435d5362d3f12f420d1f3f53c1d847710209cd1db4937c&scene=21#wechat_redirect)

- [《Dubbo 3.0 前瞻：重塑 Spring Cloud 服務治理》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494958&idx=1&sn=9867803e22cd031444eb25ff444fac16&chksm=fae6e6e1cd916ff793f3c2a74ded05d4402edc9a12be42799ae8db527ccfe0c416c54b469027&scene=21#wechat_redirect)

- [《Dubbo 3.0 前瞻：常用協議對比及 RPC 協議新形態探索》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247494967&idx=1&sn=7dd2e30ba6f1d58d289372b8503fe423&chksm=fae6e6f8cd916feeb1686f8da8fec422dd8b39683c1c022e1f8593c8ae2337438f3ce84dc77d&scene=21#wechat_redirect)

- [《2020 雙11，Dubbo3.0 在考拉的超大規模實踐》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496779&idx=1&sn=a6fc7074dea01f5f6e52ae8d5faddb51&chksm=fae6ff84cd91769238703260207e37f1741e176cb1262e742ffebdde1a51d4e03b9d336d2982&scene=21#wechat_redirect)

- [《Dubbo 3.0 前瞻系列：服務發現支援百萬叢集，帶來可伸縮微服務架構》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247498425&idx=1&sn=6da6ff05e92c2c822a141dc8dcd3dd55&chksm=fae6f176cd917860f27bcd85f83a7f3d4b1133ebc1ae2bf954ca00a2aeebac8047f54be19b7e&scene=21#wechat_redirect)

- [《Dubbo 版 Swagger 來啦！Dubbo-Api-Docs 釋出》](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247499708&idx=1&sn=8620234c748374eb8c086860aed6d300&chksm=fae6f473cd917d65778d74aa36ff199c3ce0a468b208d0db34c0dd8c83472a08ab883859ef9f&scene=21#wechat_redirect)

#### 作者簡介

**江河清**，Github 賬號 AlbumenJ，Apache Dubbo Committer。在讀本科生，目前主要參與 Dubbo 社群雲原生 Kubernetes 和 Service Mesh 模組對接。

Dubbo 3.0 前瞻之對接 Kubernetes 原生服務

相關文章