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

1.核心組件

要說 Dubbo 運行流程就不得不先來了解一下 Dubbo 的核心組件了，因為 Dubbo 的交互流程是和核心組件息息相關的。

Dubbo 核心組件有以下幾個：

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

2.運行流程

Dubbo 運行流程如下圖所示：

它的執(zhí)行流程如下：

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

更詳細的調用流程如下：

3.支持的通訊協(xié)議

Dubbo 框架提供了自定義的高性能 RPC 通信協(xié)議：基于 HTTP/2 的 Triple 協(xié)議和基于 TCP 的 Dubbo2 協(xié)議。除此之外，Dubbo 框架支持任意第三方通信協(xié)議，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多協(xié)議可以通過自定義擴展實現(xiàn)。這對于微服務實踐中經(jīng)常要處理的多協(xié)議通信場景非常有用。

Dubbo 框架不綁定任何通信協(xié)議，在實現(xiàn)上 Dubbo 對多協(xié)議的支持也非常靈活，它可以讓你在一個應用內發(fā)布多個使用不同協(xié)議的服務，并且支持用同一個 port 端口對外發(fā)布所有協(xié)議。

通過 Dubbo 框架的多協(xié)議支持，你可以做到：

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

4.Dubbo負載均衡策略

目前 Dubbo（3.X）內置了如下負載均衡策略：

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