在2011年10月27日，阿里巴巴開源了自己的SOA服務(wù)化治理方案的核心框架Dubbo，服務(wù)治理和SOA的設(shè)計理念開始逐漸在國內(nèi)軟件行業(yè)中落地，并被廣泛應(yīng)用。

[[281524]]

Dubbo作為阿里巴巴內(nèi)部的SOA服務(wù)化治理方案的核心框架，在2012年時已經(jīng)每天為2000+個服務(wù)提供3,000,000,000+次訪問量支持，并被廣泛應(yīng)用于阿里巴巴集團的各成員站點。Dubbo自2011年開源后，已被許多非阿里系公司使用，其中既有當當網(wǎng)、網(wǎng)易考拉等互聯(lián)網(wǎng)公司，也有中國人壽、青島海爾等傳統(tǒng)企業(yè)。本文是作者根據(jù)官方文檔以及自己平時的使用情況，對 Dubbo 所做的一個總結(jié)。

一 重要的概念

1.1 什么是 Dubbo?

Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、輕量級的開源Java RPC 框架，它提供了三大核心能力：面向接口的遠程方法調(diào)用，智能容錯和負載均衡，以及服務(wù)自動注冊和發(fā)現(xiàn)。簡單來說 Dubbo 是一個分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。

Dubbo 目前已經(jīng)有接近 25k 的 Star ，Dubbo的Github 地址：https://github.com/apache/incubator-dubbo 。 另外，在開源中國舉行的2018年度最受歡迎中國開源軟件這個活動的評選中，Dubbo 更是憑借其超高人氣僅次于 vue.js 和 ECharts 獲得第三名的好成績。

Dubbo 是由阿里開源，后來加入了 Apache 。正式由于 Dubbo 的出現(xiàn)，才使得越來越多的公司開始使用以及接受分布式架構(gòu)。

我們上面說了 Dubbo 實際上是 RPC 框架，那么什么是 RPC呢?

1.2 什么是 RPC?RPC原理是什么?

什么是 RPC?

RPC(Remote Procedure Call)—遠程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。比如兩個不同的服務(wù)A,B部署在兩臺不同的機器上，那么服務(wù) A 如果想要調(diào)用服務(wù) B 中的某個方法該怎么辦呢?使用 HTTP請求 當然可以，但是可能會比較慢而且一些優(yōu)化做的并不好。 RPC 的出現(xiàn)就是為了解決這個問題。

RPC原理是什么?

我這里這是簡單的提一下。詳細內(nèi)容可以查看下面這篇文章：

http://dubbo.apache.org/zh-cn/blog/rpc-introduction.html

RPC原理圖

• 服務(wù)消費方(client)調(diào)用以本地調(diào)用方式調(diào)用服務(wù);
• client stub接收到調(diào)用后負責將方法、參數(shù)等組裝成能夠進行網(wǎng)絡(luò)傳輸?shù)南Ⅲw;
• client stub找到服務(wù)地址，并將消息發(fā)送到服務(wù)端;
• server stub收到消息后進行解碼;
• server stub根據(jù)解碼結(jié)果調(diào)用本地的服務(wù);
• 本地服務(wù)執(zhí)行并將結(jié)果返回給server stub;
• server stub將返回結(jié)果打包成消息并發(fā)送至消費方;
• client stub接收到消息，并進行解碼;
• 服務(wù)消費方得到最終結(jié)果。

下面再貼一個網(wǎng)上的時序圖：

RPC原理時序圖

說了這么多，我們?yōu)槭裁匆?Dubbo 呢?

1.3 為什么要用 Dubbo?

Dubbo 的誕生和 SOA 分布式架構(gòu)的流行有著莫大的關(guān)系。SOA 面向服務(wù)的架構(gòu)(Service Oriented Architecture)，也就是把工程按照業(yè)務(wù)邏輯拆分成服務(wù)層、表現(xiàn)層兩個工程。服務(wù)層中包含業(yè)務(wù)邏輯，只需要對外提供服務(wù)即可。表現(xiàn)層只需要處理和頁面的交互，業(yè)務(wù)邏輯都是調(diào)用服務(wù)層的服務(wù)來實現(xiàn)。SOA架構(gòu)中有兩個主要角色：服務(wù)提供者(Provider)和服務(wù)使用者(Consumer)。

為什么要用 Dubbo

如果你要開發(fā)分布式程序，你也可以直接基于 HTTP 接口進行通信，但是為什么要用 Dubbo呢?

我覺得主要可以從 Dubbo 提供的下面四點特性來說為什么要用 Dubbo：

1. 負載均衡——同一個服務(wù)部署在不同的機器時該調(diào)用那一臺機器上的服務(wù)
2. 服務(wù)調(diào)用鏈路生成——隨著系統(tǒng)的發(fā)展，服務(wù)越來越多，服務(wù)間依賴關(guān)系變得錯蹤復雜，甚至分不清哪個應(yīng)用要在哪個應(yīng)用之前啟動，架構(gòu)師都不能完整的描述應(yīng)用的架構(gòu)關(guān)系。Dubbo 可以為我們解決服務(wù)之間互相是如何調(diào)用的。
3. 服務(wù)訪問壓力以及時長統(tǒng)計、資源調(diào)度和治理——基于訪問壓力實時管理集群容量，提高集群利用率。
4. 服務(wù)降級——某個服務(wù)掛掉之后調(diào)用備用服務(wù)

另外，Dubbo 除了能夠應(yīng)用在分布式系統(tǒng)中，也可以應(yīng)用在現(xiàn)在比較火的微服務(wù)系統(tǒng)中。不過，由于 Spring Cloud 在微服務(wù)中應(yīng)用更加廣泛，所以，我覺得一般我們提 Dubbo 的話，大部分是分布式系統(tǒng)的情況。

我們剛剛提到了分布式這個概念，下面再給大家介紹一下什么是分布式?為什么要分布式?

1.4 什么是分布式?

分布式或者說 SOA 分布式重要的就是面向服務(wù)，說簡單的分布式就是我們把整個系統(tǒng)拆分成不同的服務(wù)然后將這些服務(wù)放在不同的服務(wù)器上減輕單體服務(wù)的壓力提高并發(fā)量和性能。比如電商系統(tǒng)可以簡單地拆分成訂單系統(tǒng)、商品系統(tǒng)、登錄系統(tǒng)等等，拆分之后的每個服務(wù)可以部署在不同的機器上，如果某一個服務(wù)的訪問量比較大的話也可以將這個服務(wù)同時部署在多臺機器上。

1.5 為什么要分布式?

從開發(fā)角度來講單體應(yīng)用的代碼都集中在一起，而分布式系統(tǒng)的代碼根據(jù)業(yè)務(wù)被拆分。所以，每個團隊可以負責一個服務(wù)的開發(fā)，這樣提升了開發(fā)效率。另外，代碼根據(jù)業(yè)務(wù)拆分之后更加便于維護和擴展。

另外，我覺得將系統(tǒng)拆分成分布式之后不光便于系統(tǒng)擴展和維護，更能提高整個系統(tǒng)的性能。你想一想嘛?把整個系統(tǒng)拆分成不同的服務(wù)/系統(tǒng)，然后每個服務(wù)/系統(tǒng) 單獨部署在一臺服務(wù)器上，是不是很大程度上提高了系統(tǒng)性能呢?

二 Dubbo 的架構(gòu)

2.1 Dubbo 的架構(gòu)圖解

Dubbo 架構(gòu)

上述節(jié)點簡單說明：

Provider： 暴露服務(wù)的服務(wù)提供方

Consumer： 調(diào)用遠程服務(wù)的服務(wù)消費方

Registry： 服務(wù)注冊與發(fā)現(xiàn)的注冊中心

Monitor： 統(tǒng)計服務(wù)的調(diào)用次數(shù)和調(diào)用時間的監(jiān)控中心

Container： 服務(wù)運行容器

調(diào)用關(guān)系說明：

服務(wù)容器負責啟動，加載，運行服務(wù)提供者。

服務(wù)提供者在啟動時，向注冊中心注冊自己提供的服務(wù)。

服務(wù)消費者在啟動時，向注冊中心訂閱自己所需的服務(wù)。

注冊中心返回服務(wù)提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者。

服務(wù)消費者，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調(diào)用，如果調(diào)用失敗，再選另一臺調(diào)用。

服務(wù)消費者和提供者，在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心。

重要知識點總結(jié)：

注冊中心負責服務(wù)地址的注冊與查找，相當于目錄服務(wù)，服務(wù)提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉(zhuǎn)發(fā)請求，壓力較小

監(jiān)控中心負責統(tǒng)計各服務(wù)調(diào)用次數(shù)，調(diào)用時間等，統(tǒng)計先在內(nèi)存匯總后每分鐘一次發(fā)送到監(jiān)控中心服務(wù)器，并以報表展示

注冊中心，服務(wù)提供者，服務(wù)消費者三者之間均為長連接，監(jiān)控中心除外

注冊中心通過長連接感知服務(wù)提供者的存在，服務(wù)提供者宕機，注冊中心將立即推送事件通知消費者

注冊中心和監(jiān)控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表

注冊中心和監(jiān)控中心都是可選的，服務(wù)消費者可以直連服務(wù)提供者

服務(wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用

服務(wù)提供者全部宕掉后，服務(wù)消費者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復

2.2 Dubbo 工作原理

Dubbo 工作原理

圖中從下至上分為十層，各層均為單向依賴，右邊的黑色箭頭代表層之間的依賴關(guān)系，每一層都可以剝離上層被復用，其中，Service 和 Config 層為 API，其它各層均為 SPI。

各層說明：

• 第一層：service層，接口層，給服務(wù)提供者和消費者來實現(xiàn)的
• 第二層：config層，配置層，主要是對dubbo進行各種配置的
• 第三層：proxy層，服務(wù)接口透明代理，生成服務(wù)的客戶端 Stub 和服務(wù)器端 Skeleton
• 第四層：registry層，服務(wù)注冊層，負責服務(wù)的注冊與發(fā)現(xiàn)
• 第五層：cluster層，集群層，封裝多個服務(wù)提供者的路由以及負載均衡，將多個實例組合成一個服務(wù)
• 第六層：monitor層，監(jiān)控層，對rpc接口的調(diào)用次數(shù)和調(diào)用時間進行監(jiān)控
• 第七層：protocol層，遠程調(diào)用層，封裝rpc調(diào)用
• 第八層：exchange層，信息交換層，封裝請求響應(yīng)模式，同步轉(zhuǎn)異步
• 第九層：transport層，網(wǎng)絡(luò)傳輸層，抽象mina和netty為統(tǒng)一接口
• 第十層：serialize層，數(shù)據(jù)序列化層。網(wǎng)絡(luò)傳輸需要。

三 Dubbo 的負載均衡策略

3.1 先來解釋一下什么是負載均衡

先來個官方的解釋。

維基百科對負載均衡的定義：負載均衡改善了跨多個計算資源(例如計算機，計算機集群，網(wǎng)絡(luò)鏈接，中央處理單元或磁盤驅(qū)動的的工作負載分布。負載平衡旨在優(yōu)化資源使用，最大化吞吐量，最小化響應(yīng)時間，并避免任何單個資源的過載。使用具有負載平衡而不是單個組件的多個組件可以通過冗余提高可靠性和可用性。負載平衡通常涉及專用軟件或硬件

上面講的大家可能不太好理解，再用通俗的話給大家說一下。

比如我們的系統(tǒng)中的某個服務(wù)的訪問量特別大，我們將這個服務(wù)部署在了多臺服務(wù)器上，當客戶端發(fā)起請求的時候，多臺服務(wù)器都可以處理這個請求。那么，如何正確選擇處理該請求的服務(wù)器就很關(guān)鍵。假如，你就要一臺服務(wù)器來處理該服務(wù)的請求，那該服務(wù)部署在多臺服務(wù)器的意義就不復存在了。負載均衡就是為了避免單個服務(wù)器響應(yīng)同一請求，容易造成服務(wù)器宕機、崩潰等問題，我們從負載均衡的這四個字就能明顯感受到它的意義。

3.2 再來看看 Dubbo 提供的負載均衡策略

在集群負載均衡時，Dubbo 提供了多種均衡策略，默認為 random 隨機調(diào)用。可以自行擴展負載均衡策略，參見：負載均衡擴展。

備注:下面的圖片來自于：尚硅谷2018Dubbo 視頻。

3.2.1 Random LoadBalance(默認，基于權(quán)重的隨機負載均衡機制)

隨機，按權(quán)重設(shè)置隨機概率。

在一個截面上碰撞的概率高，但調(diào)用量越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動態(tài)調(diào)整提供者權(quán)重。

基于權(quán)重的隨機負載均衡機制

3.2.2 RoundRobin LoadBalance(不推薦，基于權(quán)重的輪詢負載均衡機制)

• 輪循，按公約后的權(quán)重設(shè)置輪循比率。
• 存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調(diào)到第二臺時就卡在那，久而久之，所有請求都卡在調(diào)到第二臺上。

基于權(quán)重的輪詢負載均衡機制

3.2.3 LeastActive LoadBalance

最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機，活躍數(shù)指調(diào)用前后計數(shù)差。

使慢的提供者收到更少請求，因為越慢的提供者的調(diào)用前后計數(shù)差會越大。

3.2.4 ConsistentHash LoadBalance

• 一致性 Hash，相同參數(shù)的請求總是發(fā)到同一提供者。(如果你需要的不是隨機負載均衡，是要一類請求都到一個節(jié)點，那就走這個一致性hash策略。)
• 當某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。
• 算法參見：http://en.wikipedia.org/wiki/Consistent_hashing
• 缺省只對第一個參數(shù) Hash，如果要修改，請配置
• 缺省用 160 份虛擬節(jié)點，如果要修改，請配置

3.3 配置方式

xml 配置方式

服務(wù)端服務(wù)級別

客戶端服務(wù)級別

服務(wù)端方法級別

客戶端方法級別

注解配置方式：

消費方基于基于注解的服務(wù)級別配置方式：

四 zookeeper宕機與dubbo直連的情況

zookeeper宕機與dubbo直連的情況在面試中可能會被經(jīng)常問到，所以要引起重視。

在實際生產(chǎn)中，假如zookeeper注冊中心宕掉，一段時間內(nèi)服務(wù)消費方還是能夠調(diào)用提供方的服務(wù)的，實際上它使用的本地緩存進行通訊，這只是dubbo健壯性的一種提現(xiàn)。

dubbo的健壯性表現(xiàn)：

• 監(jiān)控中心宕掉不影響使用，只是丟失部分采樣數(shù)據(jù)
• 數(shù)據(jù)庫宕掉后，注冊中心仍能通過緩存提供服務(wù)列表查詢，但不能注冊新服務(wù)
• 注冊中心對等集群，任意一臺宕掉后，將自動切換到另一臺
• 注冊中心全部宕掉后，服務(wù)提供者和服務(wù)消費者仍能通過本地緩存通訊
• 服務(wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用
• 服務(wù)提供者全部宕掉后，服務(wù)消費者應(yīng)用將無法使用，并無限次重連等待服務(wù)提供者恢復

我們前面提到過：注冊中心負責服務(wù)地址的注冊與查找，相當于目錄服務(wù)，服務(wù)提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉(zhuǎn)發(fā)請求，壓力較小。所以，我們可以完全可以繞過注冊中心——采用 dubbo 直連 ，即在服務(wù)消費方配置服務(wù)提供方的位置信息。