引言

作為分布式服務框架的標桿，Dubbo憑借其高性能RPC通信、靈活的服務治理能力和豐富的容錯機制，成為Java技術棧中微服務領域的核心考點。本文系統梳理Dubbo高頻面試核心知識點，涵蓋容錯策略、負載均衡、注冊中心原理、服務上下線感知等關鍵技術細節，助您深入理解Dubbo設計思想，從容應對分布式服務架構面試挑戰。無論是服務注冊發現流程，還是ZooKeeper節點監聽機制，這里提供清晰的技術脈絡與場景化解析。

Dubbo 容錯策略（調用失敗處理方式）

1. 默認額外重試2次。
2. 只請求一次，失敗直接拋異常。
3. 只請求一次，失敗吞掉異常 不做任何處理。
4. 記錄失敗請求，后臺定時任務進行重發。
5. 廣播給服務提供者集群 ，只要有一個節點返回，則成功。
6. 逐個調用服務提供者集群，只要有一個節點失敗，則失敗。

Dubbo 核心功能

1. 面向接口的高性能RPC調用。
2. 服務自動注冊和發現。
3. 負載均衡策略。
4. 多樣的容錯策略。
5. 可視化服務治理和運維。

Dubbo 負載均衡策略

1. 隨機
2. 輪詢
3. 加權隨機
4. 加權輪詢
5. 一致性hash
6. 最小活躍數：當一個新的請求到達時，負載均衡器會檢查所有可用服務實例的活躍請求數，并選擇活躍請求數最少的實例來處理該請求。如果有多個服務實例的活躍請求數相同且都是最少的，負載均衡器會在這些實例中隨機選擇一個來處理請求，以避免所有請求都集中到某一個實例上。

Dubbo 工作流程

1. 服務啟動后，provider和consumer根據配置信息，連接到注冊中心，分別進行服務注冊和服務訂閱。
2. 注冊中心根據訂閱關系，將provider信息發送給consumer，consumer會將provider信息緩存再本地。如果信息有變化，consumer會收到注冊中心的消息推送。
3. 服務調用時，consumer會生成代理對象，根據負載均衡策略，選擇一臺provider進行接口調用，同時定時向monitor發送接口調用次數以及耗時。
4. provider收到請求后對數據進行反序列化，通過代理對象調用具體接口。

Dubbo 如何感知服務下線？

1. Dubbo通過ZK來實現服務注冊和發現，通過ZK來維護提供者和消費者的地址。
2. /dubbo/services/providers和/dubbo/services/consumers節點維護提供者和消費者地址。
3. ZK通過心跳檢測機制（客戶端主動定期向ZooKeeper服務器發送心跳消息，也稱為Ping請求），判斷Dubbo的服務提供者的運行狀態，來決定是否從服務列表中移除，當出現故障時ZK會剔除這個服務地址。
4. Dubbo的服務消費端通過Watch機制來對/providers節點進行監控，一旦節點下的子節點發生變化，ZK就會發送事件通知Dubbo的服務消費端，消費端收到后會將變更本地緩存的服務地址。

Dubbo 注冊中心Zookeeper結構

/dubbo└── com.example.DemoService├── providers├── consumers├── configurators└── routers

1. /dubbo/com.example.DemoService：這個節點是具體的服務接口節點，以服務接口的全限定類名命名。每個服務對應一個這樣的節點。
2. /dubbo/com.example.DemoService/providers：這個節點下存儲的是所有提供該服務的提供者信息。節點的內容通常是 URL 格式，包含服務提供者的 IP、端口、協議、版本、方法等信息。
3. /dubbo/com.example.DemoService/consumers：這個節點下存儲的是所有訂閱了該服務的消費者信息。節點內容也是 URL 格式，包含消費者的 IP、端口、應用名、版本、時間戳等信息。

---

感謝您的閱讀！如果文章中有任何問題或不足之處，歡迎及時指出，您的反饋將幫助我不斷改進與完善。期待與您共同探討技術，共同進步！