Dubbo理论知识
本文是作者根據官方文檔以及自己平時的使用情況，對 Dubbo 所做的一個總結。如果不懂 Dubbo 的使用的話，可以參考我的這篇文章《超詳細，新手都能看懂 ！使用SpringBoot+Dubbo 搭建一個簡單的分布式服務》
Dubbo 官網：http://dubbo.apache.org/zh-cn/index.html
Dubbo 中文文檔：?http://dubbo.apache.org/zh-cn/index.html
- 一 重要的概念
- 1.1 什么是 Dubbo?
- 1.2 什么是 RPC?RPC原理是什么?
- 1.3 為什么要用 Dubbo?
- 1.4 什么是分布式?
- 1.5 為什么要分布式?
- 二 Dubbo 的架構
- 2.1 Dubbo 的架構圖解
- 2.2 Dubbo 工作原理
- 三 Dubbo 的負載均衡策略
- 3.1 先來解釋一下什么是負載均衡
- 3.2 再來看看 Dubbo 提供的負載均衡策略
- 3.2.1 Random LoadBalance(默認，基于權重的隨機負載均衡機制)
- 3.2.2 RoundRobin LoadBalance(不推薦，基于權重的輪詢負載均衡機制)
- 3.2.3 LeastActive LoadBalance
- 3.2.4 ConsistentHash LoadBalance
- 3.3 配置方式
- 四 zookeeper宕機與dubbo直連的情況
一 重要的概念
1.1 什么是 Dubbo?
Apache Dubbo (incubating) |?d?b??| 是一款高性能、輕量級的開源Java RPC 框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動注冊和發現。簡單來說 Dubbo 是一個分布式服務框架，致力于提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。
Dubbo 目前已經有接近 23k 的 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
下面再貼一個網上的時序圖：
說了這么多，我們為什么要用 Dubbo 呢？
1.3 為什么要用 Dubbo?
Dubbo 的誕生和 SOA 分布式架構的流行有著莫大的關系。SOA 面向服務的架構（Service Oriented Architecture），也就是把工程按照業務邏輯拆分成服務層、表現層兩個工程。服務層中包含業務邏輯，只需要對外提供服務即可。表現層只需要處理和頁面的交互，業務邏輯都是調用服務層的服務來實現。SOA架構中有兩個主要角色：服務提供者（Provider）和服務使用者（Consumer）。
如果你要開發分布式程序，你也可以直接基于 HTTP 接口進行通信，但是為什么要用 Dubbo呢？
我覺得主要可以從 Dubbo 提供的下面四點特性來說為什么要用 Dubbo：
另外，Dubbo 除了能夠應用在分布式系統中，也可以應用在現在比較火的微服務系統中。不過，由于 Spring Cloud 在微服務中應用更加廣泛，所以，我覺得一般我們提 Dubbo 的話，大部分是分布式系統的情況。
我們剛剛提到了分布式這個概念，下面再給大家介紹一下什么是分布式？為什么要分布式？
1.4 什么是分布式?
分布式或者說 SOA 分布式重要的就是面向服務，說簡單的分布式就是我們把整個系統拆分成不同的服務然后將這些服務放在不同的服務器上減輕單體服務的壓力提高并發量和性能。比如電商系統可以簡單地拆分成訂單系統、商品系統、登錄系統等等，拆分之后的每個服務可以部署在不同的機器上，如果某一個服務的訪問量比較大的話也可以將這個服務同時部署在多臺機器上。
1.5 為什么要分布式?
從開發角度來講單體應用的代碼都集中在一起，而分布式系統的代碼根據業務被拆分。所以，每個團隊可以負責一個服務的開發，這樣提升了開發效率。另外，代碼根據業務拆分之后更加便于維護和擴展。
另外，我覺得將系統拆分成分布式之后不光便于系統擴展和維護，更能提高整個系統的性能。你想一想嘛？把整個系統拆分成不同的服務/系統，然后每個服務/系統 單獨部署在一臺服務器上，是不是很大程度上提高了系統性能呢？
二 Dubbo 的架構
2.1 Dubbo 的架構圖解
上述節點簡單說明：
- Provider：?暴露服務的服務提供方
- Consumer：?調用遠程服務的服務消費方
- Registry：?服務注冊與發現的注冊中心
- Monitor：?統計服務的調用次數和調用時間的監控中心
- Container：?服務運行容器
調用關系說明：
重要知識點總結：
- 注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉發請求，壓力較小
- 監控中心負責統計各服務調用次數，調用時間等，統計先在內存匯總后每分鐘一次發送到監控中心服務器，并以報表展示
- 注冊中心，服務提供者，服務消費者三者之間均為長連接，監控中心除外
- 注冊中心通過長連接感知服務提供者的存在，服務提供者宕機，注冊中心將立即推送事件通知消費者
- 注冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表
- 注冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
- 服務提供者無狀態，任意一臺宕掉后，不影響使用
- 服務提供者全部宕掉后，服務消費者應用將無法使用，并無限次重連等待服務提供者恢復
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/Consistent_hashing
- 缺省只對第一個參數 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的健壯性表現：
我們前面提到過：注冊中心負責服務地址的注冊與查找，相當于目錄服務，服務提供者和消費者只在啟動時與注冊中心交互，注冊中心不轉發請求，壓力較小。所以，我們可以完全可以繞過注冊中心——采用?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;轉載于:https://www.cnblogs.com/iwenwen/p/11052085.html
總結
- 上一篇： 【文章】一副对联，便写尽了人生
- 下一篇： SWT folder ‘..\frame