Dubbo應(yīng)用級服務(wù)是怎樣的

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

Kubernetes 是當(dāng)前全球最流行的容器服務(wù)平臺，在 Kubernetes 集群中，Dubbo 應(yīng)用的部署方式往往需要借助第三方注冊中心實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)。Dubbo 與 Kubernetes 的調(diào)度體系的結(jié)合，可以讓原本需要管理兩套平臺的運(yùn)維成本大大減低，而且 Dubbo 適配了 Kubernetes 原生服務(wù)也可以讓框架本身更加融入云原生體系?；?Dubbo 3.0 的全新應(yīng)用級服務(wù)發(fā)現(xiàn)模型可以更容易對齊 Kubernetes 的服務(wù)模型。

Kubernetes Native Service

在 Kubernetes 中，Pod 是可以在 Kubernetes 中創(chuàng)建和管理的、最小的可部署的計(jì)算單元。通常一個(gè) Pod 由一個(gè)或多個(gè)容器組成，應(yīng)用則部署在容器內(nèi)。

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

在 Kubernetes Service 內(nèi)，服務(wù)節(jié)點(diǎn)被稱為 Endpoint，這些 Endpoint 也就是對應(yīng)提供服務(wù)的應(yīng)用單元，通常一對一對應(yīng)了 Pod。

因此，我們可以將微服務(wù)中的應(yīng)用本身使用 Service 來進(jìn)行調(diào)度，而微服務(wù)間的調(diào)用通過 Service 的一系列機(jī)制來實(shí)現(xiàn)服務(wù)發(fā)現(xiàn)，進(jìn)而將微服務(wù)整合進(jìn) Kubernetes Service 的體系中。

Dubbo 應(yīng)用級服務(wù)發(fā)現(xiàn)

在 Dubbo 體系結(jié)構(gòu)內(nèi)，為了更好地符合 Java 開發(fā)人員的編程習(xí)慣，Dubbo 底層以接口粒度作為注冊對象。但是這個(gè)模型對現(xiàn)在主流的 Spring Cloud 注冊模型和 Kubernetes Service 注冊模型有很大的區(qū)別。

目前在非 Dubbo 體系外的注冊模型主要是以服務(wù)粒度作為注冊對象，為了打通 Dubbo 與其他體系之間的注冊發(fā)現(xiàn)壁壘，Dubbo 在 2.7.5 版本以后引入了服務(wù)自省的架構(gòu)，主要通過元數(shù)據(jù)服務(wù)實(shí)現(xiàn)從服務(wù)粒度到接口粒度的過渡。在 2.7.5 版本以后到 3.0 版本，服務(wù)自省模型進(jìn)行了很多方面的優(yōu)化，并且在生產(chǎn)環(huán)境下進(jìn)行了驗(yàn)證。

1. 元數(shù)據(jù)服務(wù)

元數(shù)據(jù)服務(wù)主要是存儲了服務(wù)（Instance）與接口（Interface）的映射關(guān)系，通過將原本的寫入到注冊中心的接口信息抽象到元數(shù)據(jù)進(jìn)行存儲，一方面可以大大減少注冊中心存儲的數(shù)據(jù)量、降低服務(wù)更新時(shí)集群的網(wǎng)絡(luò)通信壓力，另一方面，實(shí)現(xiàn)了注冊中心層面只存儲應(yīng)用粒度信息的目標(biāo)，對齊了其他注冊模型。

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

2. Revision 信息

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

如上圖所示，服務(wù)消費(fèi)者注冊中心的工作機(jī)制可以總結(jié)為：

• 服務(wù)消費(fèi)者向注冊中心獲取服務(wù)實(shí)例列表。

• 注冊中心向服務(wù)消費(fèi)者返回服務(wù)實(shí)例信息，在實(shí)例列表中包括了服務(wù)提供者向注冊中心寫入的 Revision 參數(shù)。

• 服務(wù)消費(fèi)者根據(jù)獲取到實(shí)例信息的 Revision 參數(shù)進(jìn)行分組，分別從每組實(shí)例中隨機(jī)選擇一臺獲取元數(shù)據(jù)服務(wù)。

• 服務(wù)消費(fèi)者通過 RPC 發(fā)起調(diào)用或者通過配置中心獲取得到指定實(shí)例的元數(shù)據(jù)信息。

• 服務(wù)消費(fèi)者根據(jù)獲取到的元數(shù)據(jù)信息組建接口粒度的服務(wù)信息。

關(guān)于應(yīng)用級服務(wù)發(fā)現(xiàn)更多的信息可以參考：《Dubbo 邁出云原生重要一步 - 應(yīng)用級服務(wù)發(fā)現(xiàn)解析》

對接實(shí)現(xiàn)方式

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

1. Kubernetes API Client

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

1）Provider 側(cè)細(xì)節(jié)

根據(jù)前文說到 Dubbo 應(yīng)用級服務(wù)發(fā)現(xiàn)模型，對于 Provider 側(cè)在應(yīng)用啟動(dòng)、接口更新時(shí)需要向注冊中心寫入 Revision 信息，因此大致的邏輯如上圖所示。

Label 標(biāo)簽作為 Selector 與 Service 進(jìn)行匹配，Annotation 中則主要存儲了 Revision 等信息，其中 Revision 信息需要由 Dubbo 應(yīng)用主動(dòng)向 Kubernetes API Server 發(fā)起更新請求寫入，這也對應(yīng)了服務(wù)注冊的流程。

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

2）Consumer 側(cè)細(xì)節(jié)

對于 Consumer 側(cè)的邏輯大致上與應(yīng)用級服務(wù)發(fā)現(xiàn)的模型設(shè)計(jì)的一樣，在通過 API 獲取到服務(wù)信息后通過獲取對應(yīng) Pod 的 Annotation 信息補(bǔ)齊 ServiceInstance  信息，后續(xù)邏輯與服務(wù)自省一致。

3）優(yōu)缺點(diǎn)

• 需要指出的是，讓應(yīng)用本身直接與 Kubernetes 管理平臺的 API 交互本身就存在一定安全隱患，如果配置不當(dāng)有一定可能性導(dǎo)致拖垮整個(gè) Kubernetes 集群。

• 當(dāng)應(yīng)用大量更新時(shí)會(huì)給 Kubernetes API Server 帶來一定壓力。

• 本方案直接將 Dubbo 的服務(wù)發(fā)現(xiàn)過程對接到 Kubernetes 集群的管理上，可以在 Kubernetes 環(huán)境下進(jìn)一步簡化管理的復(fù)雜度。

2. DNS Client

Kubernetes DNS 是 Kubernetes 提供的一種通過 DNS 查詢的方式獲取 Kubernetes Service 信息的機(jī)制，通過普通的 DNS 請求就可以獲取到服務(wù)的節(jié)點(diǎn)信息。

1）全去中心化的元數(shù)據(jù)服務(wù)

由于 DNS 協(xié)議本身限制，目前并沒有一個(gè)統(tǒng)一的較為簡單的方式向 DNS 附加更多的信息用于寫入 Revision 信息。對于 DNS 的實(shí)現(xiàn)方案我們將元數(shù)據(jù)服務(wù)進(jìn)行了改造，使其不再強(qiáng)依賴往注冊中心寫入 Revision 信息，實(shí)現(xiàn)只需要知道 Dubbo 應(yīng)用的 IP 即可以實(shí)現(xiàn)正常的服務(wù)發(fā)現(xiàn)功能。

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

2）Provider 側(cè)細(xì)節(jié)

與 Kubernetes API Client 實(shí)現(xiàn)方式類似的，組建服務(wù)的過程均需要由運(yùn)維側(cè)進(jìn)行，在服務(wù)提供者啟動(dòng)的時(shí)候會(huì)進(jìn)行元數(shù)據(jù)信息本地緩存、對外暴露元數(shù)據(jù)服務(wù)接口的機(jī)制。

這里需要特別注意的是，為了使服務(wù)發(fā)現(xiàn)過程與業(yè)務(wù)服務(wù)本身解耦，元數(shù)據(jù)服務(wù)接口與業(yè)務(wù)接口對應(yīng)的端口可以不一致，在使用 DNS 實(shí)現(xiàn)方案的時(shí)候全集群所有應(yīng)用的元數(shù)據(jù)服務(wù)端口都需要統(tǒng)一， 通過 metadataServicePort 參數(shù)進(jìn)行配置。這樣亦可以適配那些不支持通過 SRV 獲取端口的 DNS。

3）Consumer 側(cè)細(xì)節(jié)

對于 DNS 注冊中心來說，獲取實(shí)例的流程主要通過向 DNS 發(fā)起 A （或 AAAA）查詢請求來獲取，而 Kubernetes DNS 也提供了 SRV 記錄請求來獲取服務(wù)的信息。

結(jié)合前文說到的全去中心化的元數(shù)據(jù)服務(wù)機(jī)制，Consumer 會(huì)去主動(dòng)連接獲取到的每一個(gè)實(shí)例的元數(shù)據(jù)服務(wù)，獲取對應(yīng)的 Revision 信息，同時(shí)以參數(shù)回調(diào)的形式向提供者提交回調(diào)函數(shù)用于更新本地信息。

在獲取到 Revision 信息之后，對于具有相同 Revision 信息的實(shí)例，Dubbo 會(huì)隨機(jī)選擇其中一個(gè)獲取完整元數(shù)據(jù)信息，至此完成服務(wù)發(fā)現(xiàn)的全過程。

4）優(yōu)缺點(diǎn)

• 本方案與前一種方案對比起來避免了 Kubernetes API 的直接交互，避免了交互的安全問題。

• 由于 DNS 沒有像 API Watch 的通知機(jī)制，只能采用輪詢的方式判斷服務(wù)的變更，在沒有應(yīng)用變更時(shí)集群內(nèi)仍有一定量的 DNS 網(wǎng)絡(luò)查詢壓力。

• 本方案設(shè)計(jì)的時(shí)候目標(biāo)是對任何只要能夠通過 A （或 AAAA）查詢獲取到 Dubbo 應(yīng)用本身的 IP 的 DNS 都可以適配，對 Kubernetes DNS 并不是強(qiáng)依賴關(guān)系。

感謝各位的閱讀，以上就是“Dubbo應(yīng)用級服務(wù)是怎樣的”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對Dubbo應(yīng)用級服務(wù)是怎樣的這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識點(diǎn)的文章，歡迎關(guān)注！