分散式系統怎麼做服務治理

    服務治理框架。 SOA（面向服務的框架）

　　相關資料文件較為豐富的只有一個Dubbo。下面先羅列一下這些解決方案的架構設計（點選圖片可跳轉到圖片出處）。

　　大部分方案的設計風格非常相似，都是通過庫的方式在呼叫客戶端做的服務發現。那麼除了實際的RPC呼叫之外，主要多了這3個動作：註冊、訂閱、變更下發。除了這3個核心動作之外，其它的輔助操作還有統計上報、鑑權等等，這也是我們搭建一個服務治理框架需要實現的功能。從MVP的角度來說，註冊、訂閱、變更下發是最基礎的核心功能。

JSF

引入服務治理是為了對整體的RPC呼叫進行集中化管理。對我們來說其核心價值在於，減少重複勞動、避免手動配置物理檔案產生的問題、降低開發人員的技術運用成本。下面針對其中的功能點進行分別講解。

服務的自動註冊：

　　這是一個服務治理框架的基礎功能。大家運用WCF的時候應該感受更加明顯，我們要配置一個WCF服務端的時候需要在config檔案中做很多配置，甚至大部分公司其實配置都是一模一樣的到處複製黏貼，整個這個過程其實是價值較低的重複性勞動。

　　解決這個問題需要通過動態的感知到服務端的地址資訊，然後針對該地址資訊進行自動化配置或者模板化配置，讓其快速可用。那麼這些額外的資訊儲存在哪，就需要引入一個註冊中心的概念來進行集中化管理。

客戶端的自動發現：

　　當我們在config檔案中指定具體的IP和埠來定義遠端服務的地址，或者直接在程式裡硬編碼遠端服務地址時，本身就是一個端到端的訪問方式。無法靈活的在程式執行過程中去增加或減少後端的服務節點。

　　解決這個問題需要和服務註冊的實現方式配套。還可以針對於不同型別的應用制定一些負載均衡的策略進行切換。

變更下發：

　　客戶端的自動發現就依賴於此下發的資料，需要及時把提供服務的節點資訊變化下發到各個客戶端。它面向的場景如：當我們進行一個釋出的時候，先將需要釋出的節點從負載均衡列表中移除，然後再進行更新，最後再新增到負載均衡列表中。這個時候避免了訪問到正在釋出中的程式。

　　當然這點也可以基於狀態檢測模組去做，這樣可以對服務節點的健康狀態感知能力得到更好的加強。