RPC框架dubbo架構原理及使用說明

一、Dubbo是什麼

官方定義

DUBBO是一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，是阿里巴巴SOA服務化治理方案的核心框架，每天為2，000+個服務提供3，000，000，000+次訪問量支援，並被廣泛應用於阿里巴巴集團的各成員站點。

詳細理解，就是

Dubbo是阿里巴巴公司開源的一個高效能優秀的服務框架，使得應用可透過高效能的 RPC 實現服務的輸出和輸入功能，可以和spring框架無縫整合。是一個分散式服務框架，以及SOA治理方案。其功能主要包括：高效能NIO通訊及多協議整合，服務動態定址與路由，軟負載均衡與容錯，依賴分析與降級等。

這裡有幾個專業名詞：1。RPC，2。分散式，3。SOA，如果這幾個名詞有不懂的，可能理解起來就有點吃力，要回去做功課了。

通俗理解，就是在分散式系統中的一種RPC技術，透過Dubbo可以實現系統或應用之間的通訊，實現應用間的解耦合（或者最大限度地松耦合）等。

二、Dubbo的由來

1。背景

隨著網際網路的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

單一應用架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。

此時，用於簡化增刪改查工作量的 資料訪問框架（ORM） 是關鍵。

垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。

此時，用於加速前端頁面開發的 Web框架（MVC） 是關鍵。

分散式服務架構

當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。

此時，用於提高業務複用及整合的 分散式服務框架（RPC） 是關鍵。

流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。

此時，用於提高機器利用率的 資源排程和治理中心（SOA） 是關鍵。

2。需求

在大規模服務化之前，應用可能只是透過RMI或Hessian等工具，簡單的暴露和引用遠端服務，透過配置服務的URL地址進行呼叫，透過F5等硬體進行負載均衡。

（1） 當服務越來越多時，服務URL配置管理變得非常困難，F5硬體負載均衡器的單點壓力也越來越大。

此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。

並透過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬體負載均衡器的依賴，也能減少部分成本。

（2） 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。

這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。

（3） 接著，服務的呼叫量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？

為了解決這些問題，第一步，要將服務現在每天的呼叫量，響應時間，都統計出來，作為容量規劃的參考指標。

其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。

以上是Dubbo最基本的幾個需求，更多服務治理問題參見：

http：//

code。alibabatech。com/bl

og/experience_1402/service-governance-process。html

3。架構設計圖

節點角色說明：

Provider： 暴露服務的服務提供方。

Consumer： 呼叫遠端服務的服務消費方。

Registry： 服務註冊與發現的註冊中心。

Monitor： 統計服務的呼叫次調和呼叫時間的監控中心。

Container： 服務執行容器。

呼叫關係說明：

0。 服務容器負責啟動，載入，執行服務提供者。

1。 服務提供者在啟動時，向註冊中心註冊自己提供的服務。

2。 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。

3。 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。

4。 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。

5。 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。

4。Dubbo的總體架構

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分散式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。

下面，結合Dubbo官方文件，我們分別理解一下框架分層架構中，各個層次的設計要點：

服務介面層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。

配置層（Config）：對外配置介面，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以透過spring解析配置生成配置類。

服務代理層（Proxy）：服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton，以ServiceProxy為中心，擴充套件介面為ProxyFactory。

服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL為中心，擴充套件介面為RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。

叢集層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心，擴充套件介面為Cluster、Directory、Router和LoadBalance。

將多個服務提供方組合為一個服務提供方，實現對服務消費方來透明，只需要與一個服務提供方進行互動。

監控層（Monitor）：RPC呼叫次數和呼叫時間監控，以Statistics為中心，擴充套件介面為MonitorFactory、Monitor和MonitorService。

遠端呼叫層（Protocol）：封將RPC呼叫，以Invocation和Result為中心，擴充套件介面為Protocol、Invoker和Exporter。

Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。

Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke呼叫，它有可能是一個本地的實現，也可能是一個遠端的實現，也可能一個叢集實現。

資訊交換層（Exchange）：封裝請求響應模式，同步轉非同步，以Request和Response為中心，擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

網路傳輸層（Transport）：抽象mina和netty為統一介面，以Message為中心，擴充套件介面為Channel、Transporter、Client、Server和Codec。

資料序列化層（Serialize）：可複用的一些工具，擴充套件介面為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

從上圖可以看出，Dubbo對於服務提供方和服務消費方，從框架的10層中分別提供了各自需要關心和擴充套件的介面，構建整個服務生態系統（服務提供方和服務消費方本身就是一個以服務為中心的）。

根據官方提供的，對於上述各層之間關係的描述，如下所示：

> 在RPC中，Protocol是核心層，也就是隻要有Protocol + Invoker + Exporter就可以完成非透明的RPC呼叫，然後在Invoker的主過程上Filter攔截點。

> 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與伺服器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節點，保持統一概念。

> 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker偽裝成一個Invoker，這樣其它人只要關注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因為只有一個提供者時，是不需要Cluster的。

> Proxy層封裝了所有介面的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給使用者使用時，才用Proxy將Invoker轉成介面，或將介面實現轉成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那麼透明，不那麼看起來像調本地服務一樣調遠端服務。

> 而Remoting實現是Dubbo協議的實現，如果你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃為Transport傳輸層和Exchange資訊交換層，

Transport層只負責單向訊息傳輸，是對Mina、Netty、Grizzly的抽象，它也可以擴充套件UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。

> Registry和Monitor實際上不算一層，而是一個獨立的節點，只是為了全域性概覽，用層的方式畫在一起。

5。設計的優勢

（1） 連通性：

註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小

監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示

服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷

服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷

註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外

註冊中心透過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者

註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表

註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者

（2） 健狀性：

監控中心宕掉不影響使用，只是丟失部分取樣資料

資料庫宕掉後，註冊中心仍能透過快取提供服務列表查詢，但不能註冊新服務

註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺

註冊中心全部宕掉後，服務提供者和服務消費者仍能透過本地快取通訊

服務提供者無狀態，任意一臺宕掉後，不影響使用

服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復

（3） 伸縮性：

註冊中心為對等叢集，可動態增加機器部署例項，所有客戶端將自動發現新的註冊中心

服務提供者無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者資訊給消費者

（4） 升級性：

當服務叢集規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分散式服務架構不會帶來阻力：

三、如何使用Dubbo

由於Dubbo無縫的集成了spring，所以我們使用起來還是很方便的，

本地服務：（Spring配置）

local。xml

<！—— 增加暴露遠端服務配置 ——>

遠端服務：（Spring配置）

在本地服務的基礎上，只需做簡單配置，即可完成遠端化：

將上面的local。xml配置拆分成兩份，將服務定義部分放在服務提供方remote-provider。xml，將服務引用部分放在服務消費方remote-consumer。xml。

並在提供方增加暴露服務配置，在消費方增加引用服務配置。

如下：

服務提供者：remote-provider。xml

<！—— 和本地服務一樣實現遠端服務 ——>

服務消費者：remote-consumer。xml

<！—— 增加引用遠端服務配置 ——>

<！—— 和本地服務一樣使用遠端服務 ——>

Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring載入Dubbo的配置即可，Dubbo基於Spring的Schema擴充套件進行載入。

1。示例

服務提供者

定義服務介面： （該介面需單獨打包，在服務提供方和消費方共享）

package com。alibaba。dubbo。demo； public interface DemoService { String sayHello（String name）； }

在服務提供方實現介面：（對服務消費方隱藏實現）

package com。alibaba。dubbo。demo。provider；

import com。alibaba。dubbo。demo。DemoService；

public class DemoServiceImpl implements DemoService {

public String sayHello（String name） {

return “Hello ” + name；

}

}

用Spring配置宣告暴露服務：provider。xml

<？xml version=“1。0” encoding=“UTF-8”？>

xmlns：xsi=“http：//www。w3。org/2001/XMLSchema-instance”

xmlns：dubbo=“http：//code。alibabatech。com/schema/dubbo”

xsi：schemaLocation=“http：//www。springframework。org/schema/beans

http：//www。springframework。org/schema/beans/spring-beans。xsd

http：//code。alibabatech。com/schema/dubbo

http：//code。alibabatech。com/schema/dubbo/dubbo。xsd”>

<！—— 提供方應用資訊，用於計算依賴關係 ——>

<！—— 使用multicast廣播註冊中心暴露服務地址 ——>

<！—— 用dubbo協議在埠暴露服務 ——>

<！—— 宣告需要暴露的服務介面 ——>

<！—— 和本地bean一樣實現服務 ——>

載入Spring配置：

import org。springframework。context。support。ClassPathXmlApplicationContext；

public class Provider { public static void main（String［］ args） throws Exception {

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext（new String［］ {“http：//10。20。160。198/wiki/display/dubbo/provider。xml”}）；

context。start（）；

System。in。read（）；

// 按任意鍵退出 } }

服務消費者

透過Spring配置引用遠端服務：consumer。xml

<？xml version=“1。0” encoding=“UTF-8”？>

xmlns：xsi=“http：//www。w3。org/2001/XMLSchema-instance”

xmlns：dubbo=“http：//code。alibabatech。com/schema/dubbo”

xsi：schemaLocation=“http：//www。springframework。org/schema/beans

http：//www。springframework。org/schema/beans/spring-beans。xsd

http：//code。alibabatech。com/schema/dubbo

http：//code。alibabatech。com/schema/dubbo/dubbo。xsd”>

<！—— 消費方應用名，用於計算依賴關係，不是匹配條件，不要與提供方一樣 ——>

<！—— 使用multicast廣播註冊中心暴露發現服務地址 ——>

<！—— 生成遠端服務代理，可以和本地bean一樣使用demoService ——>

載入Spring配置，並呼叫遠端服務：（也可以使用IoC注入）

import org。springframework。context。support。ClassPathXmlApplicationContext；

import com。alibaba。dubbo。demo。DemoService；

public class Consumer {

public static void main（String［］ args） throws Exception {

ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext（new String［］ {“http：//10。20。160。198/wiki/display/dubbo/consumer。xml”}）；

context。start（）；

DemoService demoService = （DemoService）context。getBean（“demoService”）；

// 獲取遠端服務代理

String hello = demoService。sayHello（“world”）；

// 執行遠端方法

System。out。println（ hello ）；

// 顯示呼叫結果

}

}

2。其他廣播方式

示例中使用的是multicast廣播暴露和發現服務的，當然還有其他的方式，現在使用最多的是ZooKeeper

如果使用ZooKeeper則配置修改為：

替換為

或者

服務提供者和服務消費者做相同的修改

3。說明

以上是Dubbo的XML配置，Dubbo還支援屬性配置，註解配置，API配置，下面介紹下API配置，另外兩種配置方式，感興趣的朋友可以去Dubbo官網去看下：Dubbo

如果不想使用Spring配置，而希望透過API的方式進行呼叫（官方不推薦）則

（1） 服務提供者：

import com。alibaba。dubbo。rpc。config。ApplicationConfig；

import com。alibaba。dubbo。rpc。config。RegistryConfig；

import com。alibaba。dubbo。rpc。config。ProviderConfig；

import com。alibaba。dubbo。rpc。config。ServiceConfig；

import com。xxx。XxxService；

import com。xxx。XxxServiceImpl；

// 服務實現

XxxService xxxService = new XxxServiceImpl（）；

// 當前應用配置

ApplicationConfig application = new ApplicationConfig（）；

application。setName（“xxx”）；

// 連線註冊中心配置

RegistryConfig registry = new RegistryConfig（）；

registry。setAddress（“10。20。130。230：9090”）；

registry。setUsername（“aaa”）；

registry。setPassword（“bbb”）；

// 服務提供者協議配置

ProtocolConfig protocol = new ProtocolConfig（）；

protocol。setName（“dubbo”）；

protocol。setPort（）；

protocol。setThreads（）；

// 注意：ServiceConfig為重物件，內部封裝了與註冊中心的連線，以及開啟服務埠

// 服務提供者暴露服務配置

ServiceConfig service = new ServiceConfig（）；

// 此例項很重，封裝了與註冊中心的連線，請自行快取，否則可能造成記憶體和連線洩漏

service。setApplication（application）； service。setRegistry（registry）；

// 多個註冊中心可以用setRegistries（）

service。setProtocol（protocol）；

// 多個協議可以用setProtocols（）

service。setInterface（XxxService。class）；

service。setRef（xxxService）；

service。setVersion（“1。0。0”）；

// 暴露及註冊服務

service。export（）；

（2） 服務消費者：

import com。alibaba。dubbo。rpc。config。ApplicationConfig；

import com。alibaba。dubbo。rpc。config。RegistryConfig；

import com。alibaba。dubbo。rpc。config。ConsumerConfig；

import com。alibaba。dubbo。rpc。config。ReferenceConfig；

import com。xxx。XxxService；

// 當前應用配置

ApplicationConfig application = new ApplicationConfig（）；

application。setName（“yyy”）；

// 連線註冊中心配置

RegistryConfig registry = new RegistryConfig（）；

registry。setAddress（“10。20。130。230：9090”）；

registry。setUsername（“aaa”）； registry。setPassword（“bbb”）；

// 注意：ReferenceConfig為重物件，內部封裝了與註冊中心的連線，以及與服務提供方的連線

// 引用遠端服務

ReferenceConfig reference = new ReferenceConfig（）；

// 此例項很重，封裝了與註冊中心的連線以及與提供者的連線，請自行快取，否則可能造成記憶體和連線洩漏

reference。setApplication（application）； reference。setRegistry（registry）；

// 多個註冊中心可以用setRegistries（）

reference。setInterface（XxxService。class）；

reference。setVersion（“1。0。0”）；

// 和本地bean一樣使用xxxService

XxxService xxxService = reference。get（）；

// 注意：此代理物件內部封裝了所有通訊細節，物件較重，請快取複用

四、Dubbo的一些相關疑問

1。Dubbo適用於哪些場景？

當網站變大後，不可避免的需要拆分應用進行服務化，以提高開發效率，調優效能，節省關鍵競爭資源等。

當服務越來越多時，服務的URL地址資訊就會爆炸式增長，配置管理變得非常困難，F5硬體負載均衡器的單點壓力也越來越大。

當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。

接著，服務的呼叫量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？等等……

在遇到這些問題時，都可以用Dubbo來解決。

可參見：Dubbo的背景及需求

2。Dubbo的需求和依賴情況？

Dubbo執行JDK1。5之上，預設依賴javassist、netty、spring等包，但不是必須依賴，透過配置Dubbo可不依賴任何三方庫執行。

可參見：使用者指南 - 依賴

3。Dubbo的效能如何？

Dubbo透過長連線減少握手，透過NIO及執行緒池在單連線上併發拼包處理訊息，透過二進位制流壓縮資料，比常規HTTP等短連線協議更快。在阿里巴巴內部，每天支撐2000多個服務，30多億訪問量，最大單機支撐每天近1億訪問量。

可參見：Dubbo效能測試報告

4。和淘寶HSF相比，Dubbo的特點是什麼？

Dubbo比HSF的部署方式更輕量，HSF要求使用指定的JBoss等容器，還需要在JBoss等容器中加入sar包擴充套件，對使用者執行環境的侵入性大，如果你要執行在Weblogic或Websphere等其它容器上，需要自行擴充套件容器以相容HSF的ClassLoader載入，而Dubbo沒有任何要求，可執行在任何Java環境中。

Dubbo比HSF的擴充套件性更好，很方便二次開發，一個框架不可能覆蓋所有需求，Dubbo始終保持平等對待第三方理念，即所有功能，都可以在不修改Dubbo原生程式碼的情況下，在外圍擴充套件，包括Dubbo自己內建的功能，也和第三方一樣，是透過擴充套件的方式實現的，而HSF如果你要加功能或替換某部分實現是很困難的，比如支付寶和淘寶用的就是不同的HSF分支，因為加功能時改了核心程式碼，不得不拷一個分支單獨發展，HSF現階段就算開源出來，也很難複用，除非對架構重寫。

HSF依賴比較多內部系統，比如配置中心，通知中心，監控中心，單點登入等等，如果要開源還需要做很多剝離工作，而Dubbo為每個系統的整合都留出了擴充套件點，並已梳理幹清所有依賴，同時為開源社群提供了替代方案，使用者可以直接使用。

Dubbo比HSF的功能更多，除了ClassLoader隔離，Dubbo基本上是HSF的超集，Dubbo也支援更多協議，更多註冊中心的整合，以適應更多的網站架構。

5。Dubbo在安全機制方面是如何解決的？

Dubbo主要針對內部服務，對外的服務，阿里有開放平臺來處理安全和流控，所以Dubbo在安全方面實現的功能較少，基本上只防君子不防小人，只防止誤呼叫。

Dubbo透過Token令牌防止使用者繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的呼叫方。