Dubbo的設計理念是什么

這篇文章主要講解了“Dubbo的設計理念是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Dubbo的設計理念是什么”吧！

1、服務注冊與發現機制

Dubbo的服務注冊與發現機制如下圖所示：

在Dubbo中存在4類角色：

• Registry 注冊中心。

• Consumer 服務調用者、消費端。

• Provider 服務提供者。

• Monitor 監控中心。

具體的交互流程包括如下關鍵步驟：

1. 服務提供者在啟動的時候向注冊中心進行注冊。

2. 消息消費者在啟動的時候向注冊中心訂閱指定服務，注冊中心將以某種機制（推或拉）模式告知消費端服務提供者列表。

3. 當服務提供者數量變化（服務提供者擴容、縮容、宕機等因素），注冊中心需要以某種方式(推或拉)告知消費端，以便消費端進行正常的負載均衡。

4. 服務提供者、服務消費者向監控中心匯報TPS等調用數據，以便監控中心進行可視化展示等。

Dubbo官方提供了多種注冊中心，接下來將以使用最為普遍的Zookeeper進一步介紹注冊中心的原理。

首先我們來看一下Zookeeper注冊中心中的數據存儲目錄結構，從目錄結構來窺探其實現機制。

Dubbo Zookeeper注冊中心，其目錄組織結構為 /dubbo/{ServiceName}，再每一個服務名稱下會有4個目錄：

• providers 服務提供者列表。

• consumers 消費者列表

• routers 路由規則列表，關于一個服務可以設置多個路由規則。

• configurators 動態配置條目。在Dubbo中可以在不重啟消費者、服務提供者的前提下動態修改服務提供者、服務消費者的配置，例如修改線程的數量，超時時間等參數。

基于Zookeeper注冊中心的實現細節如下：

1. 服務提供者啟動時會向注冊中心注冊，主要是在對應服務的providers目錄下增加一條記錄(臨時節點)，同時監聽 configurators節點。

2. 服務消費者啟動時會向注冊中心訂閱，主要是在對應服務的consumers目錄下增加一條記錄(臨時節點)，同時監聽 configurators、routers 目錄。

3. 由于當有新的服務提供者上線后 providers 目錄會增加一條記錄，消費者能立馬收到一個服務提供者列表變化的通知，得以將最新的服務提供者列表推送給服務調用方(消費端)；如果一個服務提供者宕機，由于創建的節點是臨時節點，Zookeeper會將該節點移除，同樣會觸發事件，消費端得知最新的服務提供者列表，從而實現路由的動態注冊與發現。

4. 當Dubbo新版本上線后，如果需要進行灰度發布，可以通過dubbo-admin等管理平臺添加路由規則，最終會寫入到指定服務的router節點(持久節點)，服務調用方會監聽該節點的變化，從而感知最新的路由規則，將其用于服務提供者的篩選，從而實現灰度發布等功能。

5. configurators 節點的運作機制與 router 節點一樣，就不重復介紹。

擴展思考：

1、如果注冊中心全部宕機，對整個服務體系會有什么影響？

如果整個注冊中心全部宕機，整個服務調用能正常工作，不會影響現有的服務消費者調用，但消費端無法發現新注冊的服務提供者。

2、如果注冊中心內存溢出或頻繁發生 Full Gc，對整個集群又會帶來什么影響呢？

如果頻繁發生Full GC，并且如果Full GC的時間超過了Zookeeper會話的過期時間，將會造成非常嚴重的影響，會觸發所有臨時節點被刪除，消費端將無法感知服務提供者的存在，影響服務調用，將大面積拋出 No provider 等錯誤。正所謂成也臨時節點、敗也臨時節點。

為了避免Full Gc帶來的嚴重后果，用于Dubbo注冊中心的Zookeeper，一定會要獨享，并及時做好內存、CPU等的監控與告警。

2、服務調用

Dubbo的服務調用設計十分優雅，其實現原理如下圖所示：

服務調用，重點闡述客戶端發起一個RPC服務調用時的所有實現細節，包括服務發現、故障轉移、路由轉發、負載均衡等方面，是Dubbo實現灰度發布的理論基礎。

2.1 服務發現

客戶端在向服務端發起請求時，首先需要知道的是當前有哪些可用的服務提供者，通常有兩種服務發現機制：

• 靜態化配置 不妨回想一下，在Dubbo等微服務框架出現之前，一個模塊調用另外一個模塊通常的做法是使用一個配置文件，將服務提供的列表配置配置在配置文件中，客戶端從按照配置文件中的列表進行淪陷。

  其弊端也非常明顯：如果需要調用的服務眾多，配置文件會變得臃腫，對擴容縮容的管理、機器宕機等變更不友好，管理非常困難。

• 動態發現

  通常基于注冊中心實現服務的注冊與動態發現，由于上文已詳細介紹，在這里就不累述。

2.2 負載均衡

客戶端通過服務發現機制，能動態發現當前存活的服務提供者列表，接下來要考慮的是如果從服務提供者列表中選擇一個服務提供者發起調用，這就是所謂的負載均衡，即 LoadBalance。

在Dubbo中默認提供了隨機、加權隨機、最少活躍連接、一致性Hash等負載均衡算法。

2.3 路由機制

其實Dubbo中不僅提供了負載均衡機制，還提供了智能路由機制，這是實現Dubbo灰度發布的理論基礎。

所謂的路由機制，是在服務提供者列表中，再設置一定的規則，進行過濾選擇，負載均衡時只從路由過濾規則篩選出來的服務提供者列表中選擇，為了更加形象的闡述路由機制的工作原理，給出如下示意圖：

上述設置了一條路由規則，即查詢機構ID為102的查詢用戶請求信息，請發送到新版本，即192168.3.102上，那主要在進行負載均衡之前先執行路由規則，從原始的服務提供者列表者按照路由規則進行過濾，從中挑選出符合要求的提供者列表，然后再進行負載均衡。

路由機制的核心理念：在進行負載均衡之前先對服務提供者列表運用路由規則，得出一個參與負載均衡的提供者列表。

2.4 故障轉移

遠程服務調用通常涉及到網絡等因素，客戶端向服務提供者發起RPC請求調用時并不一定100%成功，當調用失敗后該采用何種策略呢？

Dubbo提供了如下策略：

• failover 失敗后選擇另外一臺服務提供者進行重試，重試次數可配置，通常適合實現冪等服務的場景。

• failfast

  快速失敗，失敗后立即返回錯誤。

• failsafe 調用失敗后打印錯誤日志，返回成功，通常用于記錄審計日志等場景。

• failback 調用失敗后，返回成功，但會在后臺定時無限次重試，重啟后不再重試。

• forking 并發調用，收到第一個響應結果后返回給客戶端。通常適合實時性要求比較高的場景，但浪費服務器資源，通常可以通過forks參數設置并發調用度。

3、線程派發機制

Dubbo的通信線程模型入下圖所示：

3.1 網絡通信協議

網絡傳輸通常需要自定義通信協議，通常采用 Header + Body 的協議設計理念，并且 Header 長度固定，并且包含一個長度字段，用于記錄整個協議包的大小。

網絡傳輸為了提高傳輸效率，可以采取對傳輸數據進行壓縮，通常是對 body 進行序列化與壓縮。

Dubbo支持目前支持 java、compactedjava、nativejava、fastjson、fst、hessian2、kryo等序列化協議。

3.2 線程派發機制

在Dubbo中默認會創建200個線程用于處理業務方法，所謂的線程派發機制就是IO線程如何決定何種請求轉發到哪類線程中執行。

目前Dubbo中所有的心跳包、網絡讀寫在IO線程中執行，無法通過配置進行修改。

Dubbo提供了如下幾種線程派發機制(Dispatcher)：

• all 所有的請求轉發到業務線程池中執行（除IO讀寫、心跳包）

• message 只有請求事件在線程池中執行，其他在IO線程上執行。

• connection 請求事件在線程池中執行，連接、斷開連接事件排隊執行（含一個線程的線程池）。

• direct

  所有請求直接在IO線程中執行。

> 溫馨提示：有關線程模型，網絡通信模式，可以參考筆者如下這篇文章。

線程派發機制之所有會有多種策略，主要是考慮線程切換帶來的開銷是否能容忍，即線程切換帶來的開銷小于多線程處理帶來的提升。

例如在Dubbo中，對心跳包只需直接返回PONG包（OK），邏輯非常簡單，如果將其轉換到業務線程池，并不能帶來性能提升，反而因為需要線程切換，帶來性能損耗，故在IO線程中直接發送響應包是一個非常可取的做法。

在網絡編程中需要遵循一條最佳實踐：IO線程中不能有阻塞操作，阻塞操作需要轉發到業務線程池。

感謝各位的閱讀，以上就是“Dubbo的設計理念是什么”的內容了，經過本文的學習后，相信大家對Dubbo的設計理念是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！