聊聊 Apache Dubbo

本文來自於個人我的主頁： Apache Dubbo，轉載請保留連接 ;)

在2011年10月27日，阿里巴巴開源了本身的SOA服務化治理方案的核心框架Dubbo，服務治理和SOA的設計理念開始逐漸在國內軟件行業中落地，並被普遍應用。

Dubbo做爲阿里巴巴內部的SOA服務化治理方案的核心框架，在2012年時已經天天爲2000+個服務提供3,000,000,000+次訪問量支持，並被普遍應用於阿里巴巴集團的各成員站點。Dubbo自2011年開源後，已被許多非阿里系公司使用，其中既有當當網、網易考拉等互聯網公司，也有中國人壽、青島海爾等傳統企業。本文是做者根據官方文檔以及本身平時的使用狀況，對 Dubbo 所作的一個總結。

Dubbo 官網：https://dubbo.apache.org/zh-cn/index.html

一 重要的概念

1.1 什麼是 Dubbo?

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

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

Dubbo 是由阿里開源，後來加入了 Apache 。正式因爲 Dubbo 的出現，才使得愈來愈多的公司開始使用以及接受分佈式架構。

咱們上面說了 Dubbo 其實是 RPC 框架，那麼什麼是 RPC呢？

1.2 什麼是 RPC?RPC原理是什麼?

什麼是 RPC？

RPC（Remote Procedure Call）—遠程過程調用，它是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。好比兩個不一樣的服務A,B部署在兩臺不一樣的機器上，那麼服務 A 若是想要調用服務 B 中的某個方法該怎麼辦呢？使用 HTTP請求 固然能夠，可是可能會比較慢並且一些優化作的並很差。 RPC 的出現就是爲了解決這個問題。

RPC原理是什麼？

我這裏這是簡單的提一下。詳細內容能夠查看下面這篇文章：

http://www.importnew.com/22003.html

1. 服務消費方（client）調用以本地調用方式調用服務；
2. client stub接收到調用後負責將方法、參數等組裝成可以進行網絡傳輸的消息體；
3. client stub找到服務地址，並將消息發送到服務端；
4. server stub收到消息後進行解碼；
5. server stub根據解碼結果調用本地的服務；
6. 本地服務執行並將結果返回給server stub；
7. server stub將返回結果打包成消息併發送至消費方；
8. client stub接收到消息，並進行解碼；
9. 服務消費方獲得最終結果。

下面再貼一個網上的時序圖：

說了這麼多，咱們爲何要用 Dubbo 呢？

1.3 爲何要用 Dubbo?

Dubbo 的誕生和 SOA 分佈式架構的流行有着莫大的關係。SOA 面向服務的架構（Service Oriented Architecture），也就是把工程按照業務邏輯拆分紅服務層、表現層兩個工程。服務層中包含業務邏輯，只須要對外提供服務便可。表現層只須要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。SOA架構中有兩個主要角色：服務提供者（Provider）和服務使用者（Consumer）。

若是你要開發分佈式程序，你也能夠直接基於 HTTP 接口進行通訊，可是爲何要用 Dubbo呢？

我以爲主要能夠從 Dubbo 提供的下面四點特性來講爲何要用 Dubbo：

1. 負載均衡——同一個服務部署在不一樣的機器時該調用那一臺機器上的服務
2. 服務調用鏈路生成——隨着系統的發展，服務愈來愈多，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。Dubbo 能夠爲咱們解決服務之間互相是如何調用的。
3. 服務訪問壓力以及時長統計、資源調度和治理——基於訪問壓力實時管理集羣容量，提升集羣利用率。
4. 服務降級——某個服務掛掉以後調用備用服務

另外，Dubbo 除了可以應用在分佈式系統中，也能夠應用在如今比較火的微服務系統中。不過，因爲 Spring Cloud 在微服務中應用更加普遍，因此，我以爲通常咱們提 Dubbo 的話，大部分是分佈式系統的狀況。

咱們剛剛提到了分佈式這個概念，下面再給你們介紹一下什麼是分佈式？爲何要分佈式？

1.4 什麼是分佈式?

分佈式或者說 SOA 分佈式重要的就是面向服務，說簡單的分佈式就是咱們把整個系統拆分紅不一樣的服務而後將這些服務放在不一樣的服務器上減輕單體服務的壓力提升併發量和性能。好比電商系統能夠簡單地拆分紅訂單系統、商品系統、登陸系統等等，拆分以後的每一個服務能夠部署在不一樣的機器上，若是某一個服務的訪問量比較大的話也能夠將這個服務同時部署在多臺機器上。

1.5 爲何要分佈式?

從開發角度來說單體應用的代碼都集中在一塊兒，而分佈式系統的代碼根據業務被拆分。因此，每一個團隊能夠負責一個服務的開發，這樣提高了開發效率。另外，代碼根據業務拆分以後更加便於維護和擴展。

另外，我以爲將系統拆分紅分佈式以後不光便於系統擴展和維護，更能提升整個系統的性能。你想想嘛?把整個系統拆分紅不一樣的服務/系統，而後每一個服務/系統 單獨部署在一臺服務器上，是否是很大程度上提升了系統性能呢？

二 Dubbo 的架構

2.1 Dubbo 的架構圖解

上述節點簡單說明：

• Provider： 暴露服務的服務提供方
• Consumer： 調用遠程服務的服務消費方
• Registry： 服務註冊與發現的註冊中心
• Monitor： 統計服務的調用次數和調用時間的監控中心
• Container： 服務運行容器

調用關係說明：

1. 服務容器負責啓動，加載，運行服務提供者。
2. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
3. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
4. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

重要知識點總結：

• 註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小
• 監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展現
• 註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外
• 註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者
• 註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
• 註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

2.2 Dubbo 工做原理

圖中從下至上分爲十層，各層均爲單向依賴，右邊的黑色箭頭表明層之間的依賴關係，每一層均可以剝離上層被複用，其中，Service 和 Config 層爲 API，其它各層均爲 SPI。

各層說明：

• 第一層：service層，接口層，給服務提供者和消費者來實現的
• 第二層：config層，配置層，主要是對dubbo進行各類配置的
• 第三層：proxy層，服務接口透明代理，生成服務的客戶端 Stub 和服務器端 Skeleton
• 第四層：registry層，服務註冊層，負責服務的註冊與發現
• 第五層：cluster層，集羣層，封裝多個服務提供者的路由以及負載均衡，將多個實例組合成一個服務
• 第六層：monitor層，監控層，對rpc接口的調用次數和調用時間進行監控
• 第七層：protocol層，遠程調用層，封裝rpc調用
• 第八層：exchange層，信息交換層，封裝請求響應模式，同步轉異步
• 第九層：transport層，網絡傳輸層，抽象mina和netty爲統一接口
• 第十層：serialize層，數據序列化層。網絡傳輸須要。

三 Dubbo 的負載均衡策略

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

先來個官方的解釋。

維基百科對負載均衡的定義：負載均衡改善了跨多個計算資源（例如計算機，計算機集羣，網絡連接，中央處理單元或磁盤驅動的的工做負載分佈。負載平衡旨在優化資源使用，最大化吞吐量，最小化響應時間，並避免任何單個資源的過載。使用具備負載平衡而不是單個組件的多個組件能夠經過冗餘提升可靠性和可用性。負載平衡一般涉及專用軟件或硬件

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

好比咱們的系統中的某個服務的訪問量特別大，咱們將這個服務部署在了多臺服務器上，當客戶端發起請求的時候，多臺服務器均可以處理這個請求。那麼，如何正確選擇處理該請求的服務器就很關鍵。假如，你就要一臺服務器來處理該服務的請求，那該服務部署在多臺服務器的意義就不復存在了。負載均衡就是爲了不單個服務器響應同一請求，容易形成服務器宕機、崩潰等問題，咱們從負載均衡的這四個字就能明顯感覺到它的意義。

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

在集羣負載均衡時，Dubbo 提供了多種均衡策略，默認爲 random 隨機調用。能夠自行擴展負載均衡策略，參見：負載均衡擴展。

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

3.2.1 Random LoadBalance(默認，基於權重的隨機負載均衡機制)

• 隨機，按權重設置隨機機率。
• 在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

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

• 輪循，按公約後的權重設置輪循比率。
• 存在慢的提供者累積請求的問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

3.2.3 LeastActive LoadBalance

• 最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。
• 使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

3.2.4 ConsistentHash LoadBalance

• 一致性 Hash，相同參數的請求老是發到同一提供者。(若是你須要的不是隨機負載均衡，是要一類請求都到一個節點，那就走這個一致性hash策略。)
• 當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。
• 算法參見：http://en.wikipedia.org/wiki/...
• 缺省只對第一個參數 Hash，若是要修改，請配置 <dubbo:parameter key="hash.arguments" value="0,1" />
• 缺省用 160 份虛擬節點，若是要修改，請配置 <dubbo:parameter key="hash.nodes" value="320" />

3.3 配置方式

xml 配置方式

服務端服務級別

<dubbo:service interface="..." loadbalance="roundrobin" />

客戶端服務級別

<dubbo:reference interface="..." loadbalance="roundrobin" />

服務端方法級別

<dubbo:service interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:service>

客戶端方法級別

<dubbo:reference interface="...">
    <dubbo:method name="..." loadbalance="roundrobin"/>
</dubbo:reference>

註解配置方式：

消費方基於基於註解的服務級別配置方式：

@Reference(loadbalance = "roundrobin")
HelloService helloService;

四 zookeeper宕機與dubbo直連的狀況

zookeeper宕機與dubbo直連的狀況在面試中可能會被常常問到，因此要引發重視。

在實際生產中，假如zookeeper註冊中心宕掉，一段時間內服務消費方仍是可以調用提供方的服務的，實際上它使用的本地緩存進行通信，這只是dubbo健壯性的一種提現。

dubbo的健壯性表現：

1. 監控中心宕掉不影響使用，只是丟失部分採樣數據
2. 數據庫宕掉後，註冊中心仍能經過緩存提供服務列表查詢，但不能註冊新服務
3. 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另外一臺
4. 註冊中心所有宕掉後，服務提供者和服務消費者仍能經過本地緩存通信
5. 服務提供者無狀態，任意一臺宕掉後，不影響使用
6. 服務提供者所有宕掉後，服務消費者應用將沒法使用，並沒有限次重連等待服務提供者恢復

咱們前面提到過：註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。因此，咱們能夠徹底能夠繞過註冊中心——採用 dubbo 直連 ，即在服務消費方配置服務提供方的位置信息。

xml配置方式：

<dubbo:reference id="userService" interface="com.zang.gmall.service.UserService" url="dubbo://localhost:20880" />

註解方式：

@Reference(url = "127.0.0.1:20880")   
 HelloService helloService;