Dubbo簡介

Apache Dubbo是一款RPC服務開發(fā)框架，那何為RPC呢？全稱為Remote Procedure Call，翻譯過來就是遠程過程調(diào)用。

使用 Dubbo 開發(fā)的微服務原生具備相互之間的遠程地址發(fā)現(xiàn)與通信能力， 利用 Dubbo 提供的豐富服務治理特性，可以實現(xiàn)諸如服務發(fā)現(xiàn)、負載均衡、流量調(diào)度等服務治理訴求。Dubbo 被設計為高度可擴展，用戶可以方便的實現(xiàn)流量攔截、選址的各種定制邏輯。

1，什么是dubbo

阿里巴巴開發(fā)的云原生微服務架構(gòu)框架，類似于springcloud，兩者之間各有優(yōu)勢。那什么又是云原生？很早之前就已經(jīng)提出了云原生的思想，在計算機領(lǐng)域中，思想重要，技術(shù)的變革，一定是思想先行。云原生是一種構(gòu)建和運行應用程序的方法，是一套技術(shù)體系和方法論。云原生（CloudNative）是一個組合詞，Cloud+Native。Cloud表示應用程序位于云中，而不是傳統(tǒng)的數(shù)據(jù)中心；Native表示應用程序從設計之初即考慮到云的環(huán)境，原生為云而設計，在云上以最佳姿勢運行，充分利用和發(fā)揮云平臺的彈性+分布式優(yōu)勢。

Dubbo開發(fā)相較于Springcloud具有一些優(yōu)勢：

• 開箱即用
  • 易用性高，如 Java 版本的面向接口代理特性能實現(xiàn)本地透明調(diào)用
  • 功能豐富，基于原生庫或輕量擴展即可實現(xiàn)絕大多數(shù)的微服務治理能力
• 面向超大規(guī)模微服務集群設計
  • 極致性能，高性能的 RPC 通信協(xié)議設計與實現(xiàn)
  • 橫向可擴展，輕松支持百萬規(guī)模集群實例的地址發(fā)現(xiàn)與流量治理
• 高度可擴展
  • 調(diào)用過程中對流量及協(xié)議的攔截擴展，如 Filter、Router、LB 等
  • 微服務治理組件擴展，如 Registry、Config Center、Metadata Center 等
• 企業(yè)級微服務治理能力
  • 國內(nèi)共有云廠商支持的事實標準服務框架

2，Dubbo的一些概念

RPC通信

在Dubbo3中，RPC通信主要是使用Triple協(xié)議，Triple協(xié)議構(gòu)建于HTTP/2協(xié)議上，兼容gRPC（gRPC協(xié)議是Google開發(fā)的基于HTPP/2和protobuf的RPC協(xié)議框架），提供提供 Request Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通信模型；從 Triple 協(xié)議開始，Dubbo 還支持基于 IDL 的服務定義。

此外，Dubbo 還集成了業(yè)界主流的大部分協(xié)議，使得用戶可以在 Dubbo 框架范圍內(nèi)使用這些通信協(xié)議，為用戶提供了統(tǒng)一的編程模型與服務治理模型，這些協(xié)議包括 rest、hessian2、jsonrpc、thrift 等，注意不同語言 SDK 實現(xiàn)支持的范圍會有一些差異。

服務發(fā)現(xiàn)

服務發(fā)現(xiàn)，是消費端自動發(fā)現(xiàn)服務地址列表的能力，是微服務框架需要具備的關(guān)鍵能力，借助于自動化的服務發(fā)現(xiàn)，微服務之間在無需感知對端部署位置與IP地址的情況下實現(xiàn)通信。

實現(xiàn)的方式有多種，一種是Dubbo提供的Client-Based服務發(fā)現(xiàn)機制，同時也需要第三方注冊中心來協(xié)調(diào)服務發(fā)現(xiàn)過程，比如Nacos/Zookeeper等。

基本原理圖：

流量治理

Dubbo2開始，Dubbo就提供了豐富的服務治理規(guī)則，包括路由規(guī)則/動態(tài)配置等。
一方面 Dubbo3 正在通過對接 xDS 對接到時下流行的 Mesh 產(chǎn)品如 Istio 中所使用的以 VirtualService、DestinationRule 為代表的治理規(guī)則，另一方面 Dubbo 正尋求設計一套自有規(guī)則以實現(xiàn)在不通部署場景下的流量治理，以及靈活的治理能力。

Dubbo Mesh

Mesh網(wǎng)絡可以理解為WiFi路由器覆蓋不到一些死角，可以在死角覆蓋得到的地方，放一臺中繼WIFI，形成MESH網(wǎng)絡，就可以覆蓋到死角。

Dubbo Mesh 的目標是提供適應 Dubbo 體系的完整 Mesh 解決方案，包含定制化控制面（Control Plane）、定制化數(shù)據(jù)面解決方案。Dubbo 控制面基于業(yè)界主流 Istio 擴展，支持更豐富的流量治理規(guī)則、Dubbo應用級服務發(fā)現(xiàn)模型等，Dubbo 數(shù)據(jù)面可以采用 Envoy Sidecar，即實現(xiàn) Dubbo SDK + Envoy 的部署方案，也可以采用 Dubbo Proxyless 模式，直接實現(xiàn) Dubbo 與控制面的通信。

3，Dubbo 架構(gòu)圖

dubbo-rpc

整體上來看，Dubbo首先是一款RPC框架，用戶在使用 Dubbo 時首先需要定義好 Dubbo 服務；其次，是在將 Dubbo 服務部署上線之后，依賴 Dubbo 的應用層通信協(xié)議實現(xiàn)數(shù)據(jù)交換，Dubbo 所傳輸?shù)臄?shù)據(jù)都要經(jīng)過序列化，而這里的序列化協(xié)議是完全可擴展的。 使用 Dubbo 的第一步就是定義 Dubbo 服務，服務在 Dubbo 中的定義就是完成業(yè)務功能的一組方法的集合，可以選擇使用與某種語言綁定的方式定義，如在 Java 中 Dubbo 服務就是有一組方法的 Interface 接口，也可以使用語言中立的 Protobuf Buffers IDL 定義服務。

定義好服務之后，服務端（Provider）需要提供服務的具體實現(xiàn)，并將其聲明為 Dubbo 服務，而站在服務消費方（Consumer）的視角，通過調(diào)用 Dubbo 框架提供的 API 可以獲得一個服務代理（stub）對象，然后就可以像使用本地服務一樣對服務方法發(fā)起調(diào)用了。

在消費端對服務方法發(fā)起調(diào)用后，Dubbo 框架負責將請求發(fā)送到部署在遠端機器上的服務提供方，提供方收到請求后會調(diào)用服務的實現(xiàn)類，之后將處理結(jié)果返回給消費端，這樣就完成了一次完整的服務調(diào)用。如圖中的 Request、Response 數(shù)據(jù)流程所示。

需要注意一點，在Dubbo中，服務指的是RPC粒度的，和讀者印象中的泛指的功能型服務不是同一概念。

在分布式系統(tǒng)中，服務越來越多，應用之間的部署越來越繁雜，用戶作為RPC的消費方，如何動態(tài)知道服務提供方地址，因此Dubbo引入了注冊中心來協(xié)調(diào)提供方和消費方的地址。提供者啟動之后向注冊中心注冊自身地址，消費方通過拉取或訂閱注冊中心特定節(jié)點，動態(tài)的感知提供方地址列表的變化。

注冊中心可以使用：

• 如 Nacos、Zookeeper、Consul、Etcd 等。
• 將服務的組織與注冊交給底層容器平臺，如 Kubernetes，這可以理解為更加云原生的使用方式。

Dubbo的部署架構(gòu)圖：

Dubbo微服務組件包含三個中心組件：

• 注冊中心，協(xié)調(diào)Consumer與Provider之間的地址與發(fā)現(xiàn)

• 配置中心

  • 存儲Dubbo啟動階段的全局配置，保證配置的跨環(huán)境共享與全局一致性
  • 負責服務治理規(guī)則（路由規(guī)則/動態(tài)配置等）的存儲與推送

• 元數(shù)據(jù)中心

  • 接收Provider上報的服務接口元數(shù)據(jù)，為Admin等控制臺提供運維能力（如服務測試/接口文檔等）
  • 也作為注冊中心的額外擴展，作為服務發(fā)現(xiàn)機制的補充，提供額外的接口/方法級別配置信息的同步能力

部署架構(gòu)圖

注冊中心

不依賴于配置中心和元數(shù)據(jù)中心，主要承載的作用是服務注冊和服務發(fā)現(xiàn)的職責，Dubbo支持接口級別和應用級別的兩種粒度的服務發(fā)現(xiàn)和服務注冊。

如果Dubbo僅僅是使用RPC直連服務，可以不部署注冊中心。在接口或者應用級別，可以選擇部署對應的注冊中心。在Dubbo + Mesh 的場景下，隨著 Dubbo 服務注冊能力的弱化，Dubbo內(nèi)的注冊中心也不再是必選項，其職責開始被控制面取代，如果采用了Dubbo + Mesh的部署方式，無論是ThinSDK的mesh方式還是Proxyless的mesh方式，都不再需要獨立部署注冊中心。

metadata(元數(shù)據(jù)中心)

1. 對于一個原先采用老版本Dubbo搭建的應用服務，在遷移到Dubbo 3時，Dubbo 3 會需要一個元數(shù)據(jù)中心來維護RPC服務與應用的映射關(guān)系（即接口與應用的映射關(guān)系），因為如果采用了應用級別的服務發(fā)現(xiàn)和服務注冊，在注冊中心中將采用“應用 —— 實例列表”結(jié)構(gòu)的數(shù)據(jù)組織形式，不再是以往的“接口 —— 實例列表”結(jié)構(gòu)的數(shù)據(jù)組織形式，而以往用接口級別的服務注冊和服務發(fā)現(xiàn)的應用服務在遷移到應用級別時，得不到接口與應用之間的對應關(guān)系，從而無法從注冊中心得到實例列表信息，所以Dubbo為了兼容這種場景，在Provider端啟動時，會往元數(shù)據(jù)中心存儲接口與應用的映射關(guān)系。
2. 為了讓注冊中心更加聚焦與地址的發(fā)現(xiàn)和推送能力，減輕注冊中心的負擔，元數(shù)據(jù)中心承載了所有的服務元數(shù)據(jù)、大量接口/方法級別配置信息等，無論是接口粒度還是應用粒度的服務發(fā)現(xiàn)和注冊，元數(shù)據(jù)中心都起到了重要的作用。

如果有以上兩種需求，都可以選擇部署元數(shù)據(jù)中心，并通過Dubbo的配置來集成該元數(shù)據(jù)中心。

元數(shù)據(jù)中心并不依賴于注冊中心和配置中心，用戶可以自由選擇是否集成和部署元數(shù)據(jù)中心，如下圖所示：

配置中心

整個部署架構(gòu)中，整個集群內(nèi)實例（無論是Provider還是Consumer）都會共享該配置中心集群中的配置。

三大中心不一定是Dubbo應用服務必須使用的，但是如果集成了三大部署中心，還是會遇到可用性問題，比如多個注冊中心，多個配置中心，多個元數(shù)據(jù)中心，系統(tǒng)該如何運行。

Dubbo對三大中心都支持了Multiple模式：

• 多注冊中心：Dubbo 支持多注冊中心，即一個接口或者一個應用可以被注冊到多個注冊中心中，比如可以注冊到ZK集群和Nacos集群中，Consumer也能夠從多個注冊中心中進行訂閱相關(guān)服務的地址信息，從而進行服務發(fā)現(xiàn)。通過支持多注冊中心的方式來保證其中一個注冊中心集群出現(xiàn)不可用時能夠切換到另一個注冊中心集群，保證能夠正常提供服務以及發(fā)起服務調(diào)用。這也能夠滿足注冊中心在部署上適應各類高可用的部署架構(gòu)模式。
• 多配置中心：Dubbo支持多配置中心，來保證其中一個配置中心集群出現(xiàn)不可用時能夠切換到另一個配置中心集群，保證能夠正常從配置中心獲取全局的配置、路由規(guī)則等信息。這也能夠滿足配置中心在部署上適應各類高可用的部署架構(gòu)模式。
• 多元數(shù)據(jù)中心：Dubbo 支持多元數(shù)據(jù)中心：用于應對容災等情況導致某個元數(shù)據(jù)中心集群不可用，此時可以切換到另一個元數(shù)據(jù)中心集群，保證元數(shù)據(jù)中心能夠正常提供有關(guān)服務元數(shù)據(jù)的管理能力。

如遇到多個注冊中心的話，部署架構(gòu)如下：

機房A，機房B，兩個Registry，Provider A會通過Dubbo SDK把地址注冊到Registry A，Consumer A會和注冊中心A進行一個互相訂閱地址。機房B原理和機房A原理一樣。機房AB中的注冊中心會進行數(shù)據(jù)同步，這樣機房A的consumer A也可以看作和機房B的Registry進行訂閱地址同步。

4，Dubbo可擴展性

為什么要在系統(tǒng)中強調(diào)可擴展性呢？一個很大的原因是，比如一個系統(tǒng)設計好之后，后期又需要加入一些功能代碼或者插件，如何最小化改變原有代碼加入功能代碼或者插件，這個就是擴展性，Dubbo在架構(gòu)時期也一直重視可擴展性。

在市面上，有成熟的可擴展技術(shù)，比如SPring的IOC容器，或者是Factory，Dubbo在設計之初，不想強依賴于Spring的IOC，又不想大費周章開發(fā)出來一個IOC容器，因此使用了最簡單的Factory。

Dubbo擴展加載流程如圖：

主要步驟為 4 個：

• 讀取并解析配置文件
• 緩存所有擴展實現(xiàn)
• 基于用戶執(zhí)行的擴展名，實例化對應的擴展實現(xiàn)
• 進行擴展實例屬性的 IOC 注入以及實例化擴展的包裝類，實現(xiàn) AOP 特性

歡迎關(guān)注我的公眾號：我只是個碼字的
本文由博客一文多發(fā)平臺 OpenWrite 發(fā)布！