Dubbo應用級服務是怎樣的

這篇文章主要講解了“Dubbo應用級服務是怎樣的”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Dubbo應用級服務是怎樣的”吧！

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

Kubernetes Native Service

在 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. 元數據服務

元數據服務主要是存儲了服務（Instance）與接口（Interface）的映射關系，通過將原本的寫入到注冊中心的接口信息抽象到元數據進行存儲，一方面可以大大減少注冊中心存儲的數據量、降低服務更新時集群的網絡通信壓力，另一方面，實現了注冊中心層面只存儲應用粒度信息的目標，對齊了其他注冊模型。

在服務自省模型中，服務提供者不僅僅往注冊中心寫入當前實例的信息，還需要往（本地或者遠程的）元數據服務寫入暴露的服務 URL 信息等；而對于服務消費者，在從注冊中心獲取實例信息后，還需要（通過 RPC 請求內建或者中心化配置中心獲取）元數據服務獲取服務提供者的服務 URL 信息等來生成接口粒度體系下的接口信息。

2. Revision 信息

Revision 信息是元數據服務引入的一種數據緩存機制，對于同一組應用很多情況下暴露的接口其實都是一樣的，在進行服務（Instance）與接口（Interface）映射的時候會有許多重復的冗余數據，因此可以使用類似對元數據信息進行 MD5 計算的方式來對實例本身加上版本號，如果多個實例的版本號一致可以認為它們的元數據信息也一致，那么只需要隨機選擇一臺來獲取元數據信息即可，可以實現把通行量從一組實例都需要通信到只需要與一個實例通信的壓縮。

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

• 服務消費者向注冊中心獲取服務實例列表。

• 注冊中心向服務消費者返回服務實例信息，在實例列表中包括了服務提供者向注冊中心寫入的 Revision 參數。

• 服務消費者根據獲取到實例信息的 Revision 參數進行分組，分別從每組實例中隨機選擇一臺獲取元數據服務。

• 服務消費者通過 RPC 發起調用或者通過配置中心獲取得到指定實例的元數據信息。

• 服務消費者根據獲取到的元數據信息組建接口粒度的服務信息。

關于應用級服務發現更多的信息可以參考：《Dubbo 邁出云原生重要一步 - 應用級服務發現解析》

對接實現方式

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

1. Kubernetes API Client

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

1）Provider 側細節

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

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

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

2）Consumer 側細節

對于 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 即可以實現正常的服務發現功能。

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

2）Provider 側細節

與 Kubernetes API Client 實現方式類似的，組建服務的過程均需要由運維側進行，在服務提供者啟動的時候會進行元數據信息本地緩存、對外暴露元數據服務接口的機制。

這里需要特別注意的是，為了使服務發現過程與業務服務本身解耦，元數據服務接口與業務接口對應的端口可以不一致，在使用 DNS 實現方案的時候全集群所有應用的元數據服務端口都需要統一， 通過 metadataServicePort 參數進行配置。這樣亦可以適配那些不支持通過 SRV 獲取端口的 DNS。

3）Consumer 側細節

對于 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應用級服務是怎樣的”的內容了，經過本文的學習后，相信大家對Dubbo應用級服務是怎樣的這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！