深入理解Dubbo核心概念,這篇文章你絕對不能錯過

什麼是 Dubbo?

Apache Dubbo |ˈdʌbəʊ| 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠程方法調用，智能容錯和負載均衡，以及服務自動註冊和發現。 可以和Spring 框架無縫集成。

Dubbo 的主要應用場景？

• 透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何 API 侵入。
• 軟負載均衡及容錯機制，可在內網替代 F5 等硬件負載均衡器，降低成本，減少單點。
• 服務自動註冊與發現，不再需要寫死服務提供方的地址，註冊中心基於接口名查詢服務提供者的 IP 地址，並且能夠平滑添加或刪除服務提供者。

Dubbo 的核心功能

• 主要就是如下 3 個核心功能：

Remoting

• 網絡通信框架，提供對多種 NIO 框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。

Cluster

• 服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。

Registry

• 服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo 的核心組件

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

Dubbo服務註冊與發現的流程？

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

• Dubbo 架構具有以下幾個特點，分別是連通性、健壯性、伸縮性、以及向未來架構的升級性。

Dubbo 的負載均衡

在集羣負載均衡時，Dubbo 提供了多種均衡策略，缺省爲 random 隨機調用。

負載均衡策略

Random LoadBalance

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

RoundRobin LoadBalance

• 輪詢，按公約後的權重設置輪詢比率。
• 存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

LeastActive LoadBalance

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

ConsistentHash LoadBalance

• 一致性 Hash，相同參數的請求總是發到同一提供者。
• 當某一臺提供者掛時，原本發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引起劇烈變動。
• 缺省只對第一個參數 Hash，如果要修改，請配置 <dubbo:parameter key=“hash.arguments” value=“0,1” />
• 缺省用 160 份虛擬節點，如果要修改，請配置 <dubbo:parameter key=“hash.nodes” value=“320” />

Dubbo大廠高頻面試題

Dubbo 有些哪些註冊中心？

• Nacos註冊中心：Nacos 是 Dubbo 生態系統中重要的註冊中心實現。
• Multicast 註冊中心： Multicast 註冊中心不需要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；
• Zookeeper 註冊中心： 基於分佈式協調系統 Zookeeper 實現，採用Zookeeper 的 watch 機制實現數據變更；
• redis 註冊中心： 基於 redis 實現，採用 key/Map 存儲，住 key 存儲服務名和類型，Map 中 key 存儲服務 URL，value 服務過期時間。基於 redis 的發佈/訂閱模式通知數據變更；
• Simple 註冊中心

Dubbo 的註冊中心集羣掛掉，發佈者和訂閱者之間還能通信麼？

• 可以通信的，啓動 dubbo 時，消費者會從 註冊中心拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用；註冊中心對等集羣，任意一臺宕機後，將會切換到另一臺；註冊中心全部宕機後，服務的提供者和消費者仍能通過本地緩存通訊。服務提供者無狀態，任一臺宕機後，不影響使用；服務提供者全部宕機，服務消費者會無法使用，並無限次重連等待服務者恢復；
• 掛掉是不要緊的，但前提是你沒有增加新的服務，如果你要調用新的服務，則是不能辦到的。
  

Dubbo 和 Spring Cloud 的關係？

• Dubbo 是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud 誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外由於依託了 Spirng、Spirng Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo定位服務治理,Spirng Cloud 是一個生態。
• Spring Cloud拋棄了Dubbo 的RPC通信，採用的是基於HTTP的REST方式。嚴格來說，這兩種方式各有優劣。雖然在一定程度上來說，後者犧牲了服務調用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更爲合適。
• Dubbo的定位始終是一款RPC框架，而Spring Cloud的目的是微服務架構下的一站式解決方案。

爲什麼需要服務治理？

• 過多的服務 URL 配置困難
• 負載均衡分配節點壓力過大的情況下也需要部署集羣
• 服務依賴混亂，啓動順序不清晰
• 過多服務導致性能指標分析難度較大，需要監控

dubbo 和 dubbox 之間的區別？

• dubbox 基於 dubbo 上做了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

Dubbo 超時時間怎樣設置？

• Dubbo 超時時間設置有兩種方式：
  • 服務提供者端設置超時時間，在 Dubbo 的用戶文檔中，推薦如果能在服務
    端多配置就儘量多配置，因爲服務提供者比消費者更清楚自己提供的服務特
    性。
  • 服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端
    爲主，即優先級更高。因爲服務調用方設置超時時間控制性更靈活。如果消
    費方超時，服務端線程不會定製，會產生警告。

Dubbo 支持哪些協議，每種協議的應用場景，優缺點？

• dubbo： 單一長連接和 NIO 異步通訊，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議 TCP，異步，Hessian 序列化；
• rmi： 採用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象需要實現Serializable 接口，使用 java 標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議 TCP。多個短連接，TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 rmi 互操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞；
• webservice： 基於 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操作。多個短連接，基於 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用；
• http： 基於 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短連接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多於消費者，需要給應用程序和瀏覽器 JS 調用；
• hessian： 集成 Hessian 服務，基於 HTTP 通訊，採用 Servlet 暴露服務，Dubbo 內嵌 Jetty 作爲服務器時默認實現，提供與 Hession 服務互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；
• memcache： 基於 memcached 實現的 RPC 協議
• redis： 基於 redis 實現的 RPC 協議

你知道的越多，你不知道的越多。
有道無術，術尚可求，有術無道，止於術。
如有其它問題，歡迎大家留言，我們一起討論，一起學習，一起進步