zOP28資訊網——每日最新資訊28at.com

Dubbo 是一款高性能、輕量級的開源 RPC（遠程過程調用）框架，主要用于構建分布式服務和微服務架構。那 Dubbo 又是如何運行的呢？讓我們一起來看。zOP28資訊網——每日最新資訊28at.com

1.核心組件

要說 Dubbo 運行流程就不得不先來了解一下 Dubbo 的核心組件了，因為 Dubbo 的交互流程是和核心組件息息相關的。zOP28資訊網——每日最新資訊28at.com

Dubbo 核心組件有以下幾個：zOP28資訊網——每日最新資訊28at.com

• 服務提供者（Provider）：暴露服務的應用，通過 Dubbo 框架將自身的服務接口及實現注冊到注冊中心。
• 服務消費者（Consumer）：調用遠程服務的應用，從注冊中心訂閱所需的服務，然后通過遠程調用消費服務。
• 注冊中心（Registry）：集中管理服務的地址信息，服務提供者和服務消費者均在此注冊或訂閱服務信息。常見的注冊中心有 ZooKeeper、Nacos 等。

2.運行流程

Dubbo 運行流程如下圖所示：zOP28資訊網——每日最新資訊28at.com

zOP28資訊網——每日最新資訊28at.com

它的執行流程如下：zOP28資訊網——每日最新資訊28at.com

• 服務提供者會將實例（URL 地址）注冊到注冊中心，注冊中心負責對數據進行聚合（健康檢測）。
• 消費者從注冊中心讀取地址列表并訂閱變更，每當地址列表發生變化，注冊中心將最新的列表通知到所有訂閱的消費者實例。
• 消費者得到服務實例之后，通過 Dubbo 內置的負載均衡策略，選擇其中的一個節點，之后使用 RPC 的方式與服務提供者建立連接，并進行通訊和服務調用。

更詳細的調用流程如下：zOP28資訊網——每日最新資訊28at.com

zOP28資訊網——每日最新資訊28at.com

3.支持的通訊協議

Dubbo 框架提供了自定義的高性能 RPC 通信協議：基于 HTTP/2 的 Triple 協議和基于 TCP 的 Dubbo2 協議。除此之外，Dubbo 框架支持任意第三方通信協議，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多協議可以通過自定義擴展實現。這對于微服務實踐中經常要處理的多協議通信場景非常有用。zOP28資訊網——每日最新資訊28at.com

Dubbo 框架不綁定任何通信協議，在實現上 Dubbo 對多協議的支持也非常靈活，它可以讓你在一個應用內發布多個使用不同協議的服務，并且支持用同一個 port 端口對外發布所有協議。zOP28資訊網——每日最新資訊28at.com

zOP28資訊網——每日最新資訊28at.com

通過 Dubbo 框架的多協議支持，你可以做到：zOP28資訊網——每日最新資訊28at.com

• 將任意通信協議無縫地接入 Dubbo 服務治理體系。Dubbo 體系下的所有通信協議，都可以享受到 Dubbo 的編程模型、服務發現、流量管控等優勢。比如 gRPC over Dubbo 的模式，服務治理、編程 API 都能夠零成本接入 Dubbo 體系。
• 兼容不同技術棧，業務系統混合使用不同的服務框架、RPC 框架。比如有些服務使用 gRPC 或者 Spring Cloud 開發，有些服務使用 Dubbo 框架開發，通過 Dubbo 的多協議支持可以很好的實現互通。
• 讓協議遷移變的更簡單。通過多協議、注冊中心的協調，可以快速滿足公司內協議遷移的需求。比如如從自研協議升級到 Dubbo 協議，Dubbo 協議自身升級，從 Dubbo 協議遷移到 gRPC，從 HTTP 遷移到 Dubbo 協議等。

4.Dubbo負載均衡策略

目前 Dubbo（3.X）內置了如下負載均衡策略：zOP28資訊網——每日最新資訊28at.com

• Weighted Random LoadBalance（加權隨機）：默認負載均衡算法，默認權重相同。按權重設置隨機概率。缺點：存在慢的提供者累積請求的問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。
• RoundRobin LoadBalance（加權輪詢）：借鑒于 Nginx 的平滑加權輪詢算法，默認權重相同，按公約后的權重設置輪詢比率，循環調用節點。缺點：同樣存在慢的提供者累積請求的問題。
• LeastActive LoadBalance（最少活躍優先+加權隨機）：背后是能者多勞的思想，活躍數越低，越優先調用，相同活躍數的進行加權隨機。活躍數指調用前后計數差（針對特定提供者：請求發送數 - 響應返回數），表示特定提供者的任務堆積量，活躍數越低，代表該提供者處理能力越強。使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數差會越大；相對的，處理能力越強的節點，處理更多的請求。
• Shortest-Response LoadBalance（最短響應優先+加權隨機）：更加關注響應速度，在最近一個滑動窗口中，響應時間越短，越優先調用。相同響應時間的進行加權隨機。使得響應時間越快的提供者，處理更多的請求。缺點：可能會造成流量過于集中于高性能節點的問題。
• ConsistentHash LoadBalance（一致性哈希）：確定的入參，確定的提供者，適用于有狀態請求。當某一臺提供者掛時，原本發往該提供者的請求，基于虛擬節點，平攤到其它提供者，不會引起劇烈變動。
• P2C LoadBalance（隨機選擇兩個節點+連接數較小）：隨機選擇兩個節點后，繼續選擇“連接數”較小的那個節點。對于每次調用，從可用的 provider 列表中做兩次隨機選擇，選出兩個節點 providerA 和 providerB，比較 providerA 和 providerB 兩個節點，選擇其“當前正在處理的連接數”較小的那個節點。
• Adaptive LoadBalance（自適應負載均衡）：在 P2C 算法基礎上，選擇二者中 load 最小的那個節點，是一種能根據后端實例負載自動調整流量分布的算法實現，它總是嘗試將請求轉發到負載最小的節點。

本文鏈接：http://www.tebozhan.com/showinfo-26-95165-0.html哈啰面試：說說Dubbo運行原理？

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。郵件：2376512515@qq.com

上一篇： .NET使用原生方法實現文件壓縮和解壓

下一篇： Git是如何工作的？你知道嗎？