Dubbo 是一款高性能、輕量級的開源 RPC（遠程過程調用）框架，主要用于構建分布式服務和微服務架構。那 Dubbo 又是如何運行的呢？讓我們一起來看。
1.核心組件要說 Dubbo 運行流程就不得不先來了解一下 Dubbo 的核心組件了，因爲 Dubbo 的交互流程是和核心組件息息相關的。
Dubbo 核心組件有以下幾個：
服務提供者（Provider）：暴露服務的應用，通過 Dubbo 框架將自身的服務接口及實現注冊到注冊中心。服務消費者（Consumer）：調用遠程服務的應用，從注冊中心訂閱所需的服務，然後通過遠程調用消費服務。注冊中心（Registry）：集中管理服務的地址信息，服務提供者和服務消費者均在此注冊或訂閱服務信息。常見的注冊中心有 ZooKeeper、Nacos 等。2.運行流程Dubbo 運行流程如下圖所示：
它的執行流程如下：
服務提供者會將實例（URL 地址）注冊到注冊中心，注冊中心負責對數據進行聚合（健康檢測）。消費者從注冊中心讀取地址列表並訂閱變更，每當地址列表發生變化，注冊中心將最新的列表通知到所有訂閱的消費者實例。消費者得到服務實例之後，通過 Dubbo 內置的負載均衡策略，選擇其中的一個節點，之後使用 RPC 的方式與服務提供者建立連接，並進行通訊和服務調用。更詳細的調用流程如下：
3.支持的通訊協議Dubbo 框架提供了自定義的高性能 RPC 通信協議：基于 HTTP/2 的 Triple 協議和基于 TCP 的 Dubbo2 協議。除此之外，Dubbo 框架支持任意第三方通信協議，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2 等，更多協議可以通過自定義擴展實現。這對于微服務實踐中經常要處理的多協議通信場景非常有用。
Dubbo 框架不綁定任何通信協議，在實現上 Dubbo 對多協議的支持也非常靈活，它可以讓你在一個應用內發布多個使用不同協議的服務，並且支持用同一個 port 端口對外發布所有協議。
通過 Dubbo 框架的多協議支持，你可以做到：
將任意通信協議無縫地接入 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）內置了如下負載均衡策略：
Weighted Random LoadBalance（加權隨機）：默認負載均衡算法，默認權重相同。按權重設置隨機概率。缺點：存在慢的提供者累積請求的問題，比如：第二台機器很慢，但沒挂，當請求調到第二台時就卡在那，久而久之，所有請求都卡在調到第二台上。RoundRobin LoadBalance（加權輪詢）：借鑒于 Nginx 的平滑加權輪詢算法，默認權重相同，按公約後的權重設置輪詢比率，循環調用節點。缺點：同樣存在慢的提供者累積請求的問題。LeastActive LoadBalance（最少活躍優先+加權隨機）：背後是能者多勞的思想，活躍數越低，越優先調用，相同活躍數的進行加權隨機。活躍數指調用前後計數差（針對特定提供者：請求發送數 - 響應返回數），表示特定提供者的任務堆積量，活躍數越低，代表該提供者處理能力越強。使慢的提供者收到更少請求，因爲越慢的提供者的調用前後計數差會越大；相對的，處理能力越強的節點，處理更多的請求。Shortest-Response LoadBalance（最短響應優先+加權隨機）：更加關注響應速度，在最近一個滑動窗口中，響應時間越短，越優先調用。相同響應時間的進行加權隨機。使得響應時間越快的提供者，處理更多的請求。缺點：可能會造成流量過于集中于高性能節點的問題。ConsistentHash LoadBalance（一致性哈希）：確定的入參，確定的提供者，適用于有狀態請求。當某一台提供者挂時，原本發往該提供者的請求，基于虛擬節點，平攤到其它提供者，不會引起劇烈變動。P2C LoadBalance（隨機選擇兩個節點+連接數較小）：隨機選擇兩個節點後，繼續選擇“連接數”較小的那個節點。對于每次調用，從可用的 provider 列表中做兩次隨機選擇，選出兩個節點 providerA 和 providerB，比較 providerA 和 providerB 兩個節點，選擇其“當前正在處理的連接數”較小的那個節點。Adaptive LoadBalance（自適應負載均衡）：在 P2C 算法基礎上，選擇二者中 load 最小的那個節點，是一種能根據後端實例負載自動調整流量分布的算法實現，它總是嘗試將請求轉發到負載最小的節點。課後思考具體說說 RPC 調用的執行流程？
本文已收錄到我的面試小站 [www.javacn.site](https://www.javacn.site)，其中包含的內容有：Redis、JVM、並發、並發、MySQL、Spring、Spring MVC、Spring Boot、Spring Cloud、MyBatis、設計模式、消息隊列等模塊。
