某日中午，午睡正香的時候，接到系統的報警電話，提示生產某物理機異常宕機了，目前該物理機已恢復，需要重啟上面部署的應用。 這時瞬間沒有了睡意，登上堡壘機，快速重啟了應用，系統恢復正常。本想著繼續午睡，但是已經沒有了睡意。 旁邊的小師弟（*我們叫他小灰吧*）剛才在我們邊上，目睹這一切，然後向我請教個問題。 **小灰：** 黑哥，剛才應用突然宕機，會不會對交易有影響啊？ **小黑：** 影響確實會有，不過也不大，就當時應用正在執行那些那些交易會受到影響。 **小灰：** 不對啊，我們現在系統架構是下面這樣。  我們這次宕機的是業務邏輯層，那按照目前使用 Dubbo 輪詢的負載均衡方式，不是還會有交易分發到宕機那臺應用上，這些交易請求顯然會異常。 運氣差點，不是會有一半交易請求都會有問題嗎？ **小黑：** 沒錯，我們的系統架構圖確實如說的一樣。 不過你說的這個問題，它是不存在的。 這是因為 Dubbo 內部會自動幫我們的摘除宕機的應用節點。 **小灰：** 啥？Dubbo 內部還有這功能啊？黑哥你給我講講原理唄！ **小黑：** 可以啊，不過講這個原理之前，我們首先需要了解 Dubbo 服務註冊發現流程。 我看你最近一直在看『深入理解 Apache Dubbo 與實戰』，這本書確實不錯，裡面框架原理，程式碼細節都講的很透徹。 你應該已經瞭解了 Dubbo 服務註冊發現流程，那你先跟我簡單講講原理吧。 **小灰拿起紙筆，在上面畫了個圖：**  恩，我當前瞭解的還不是很深，那我先聊聊目前我知道的。 我們目前使用 **ZooKeeper** 當做服務註冊中心，**ZooKeeper** 可以簡單理解成是一個 **KV**系統，內部是一個樹形的資料結構。 Dubbo 預設將會在 **ZooKeeper** 中建立一個四層的資料結構，從上到下分別為： - Root - Service - Category - URL 其中 **Root** 層是註冊中心分組，預設命名為 dubbo。我們可以通過修改 `` 中的 group 屬性修改預設值，這樣修改之後不同分組的 dubbo 服務不會互相影響，也不會互相呼叫，可以用於環境隔離。 接下來 **Service** 就是服務類的全路徑，包括包路徑。 **Service** 層下面就是 **Category** 層，這其中總共有四類目錄（上面圖形只畫了兩種），分別為: - providers：包含服務提供者 URL 元資料資訊 - consumers：包含消費者 URL 元資料資訊 - routers：包含消費者路由策略的 URL 元資料資訊 - configurators：包含動態配置元資料資訊 最後一層就是具體 Dubbo 服務 URL，類似如下： ```html dubbo://2.0.1.13:12345/com.dubbo.example.DemoService?xx=xx ``` **小黑：** 沒錯，這個內部結構你理還是蠻清晰的麼！ 平常使用的情況下，我們重點關注 **providers** 以及 **consumers** 就好了。如果我們需要配置服務路由資訊以及動態配置，那我們需要在 Dubbo-Admin 服務治理中心下發配置。這時 `routers` 與 `configurators` 就會增加相關配置。 **小灰：** 嘿嘿