談談爲何須要服務治理（Dubbo）

服務治理主要針對於當前分佈式架構下多服務、微服務等。

服務是分佈式系統下的一個不大不小的部分，有了服務的組成，整個系統才能活起來。

隨着業務的增加，服務不能一味地隨之增加，須要管理、治理。沒有服務治理的分佈式系統不必定會失敗，可是隨着業務的增加，這個系統必定會很痛苦。

服務治理的目標

服務治理嚴格意義上應該劃分爲三個階段，包含了服務的整個生命週期。

其中服務設計期主要針對於服務的設計期、開發期，而服務運行期主要針對於服務上線後等運行狀況，最後服務持續治理則是堅持了「分久必合」的理念，將淘汰制進行到底。

下面講講三個時期須要完整的工做：

服務設計期：

1. 方案評審、開發測試審查、簽發認證、服務可發現
2. 策略管理
3. 合約定義、商談
4. 標準化服務質量協議

服務運行期：

1. 系統記錄：記錄交換的信息
2. 服務管理系統：控管、配置服務以及運行階段的組件，根據異常情況從新配置環境
3. 服務監控系統：採集數據，可視化，提供變配證據
4. 服務質量保證系統：加強通信中的消息和運行階段策略、安全性、可靠性、事務性、稽覈等

服務持續治理：

1. 服務資產管理：評估、分析服務倉庫，識別服務可重用的機率、協助進行資產整合、減小冗餘的服務功能

根據上述目標，咱們能夠肯定：

1. 服務治理貫穿了服務的整個生命週期，包括開發前的設計、開發以及測試、運行、以及後續管理。
2. 服務設計期主要針對於服務的設計評審以及標準的制定。
3. 服務治理運行期的重點放在管理和監控，爲了運行良好的目標，經過數據分析運行情況，經過自動化消除異常、變配等。
4. 服務治理後期的重點放在消除冗餘。

服務治理平臺設計

結合如今大多架構的註冊中心、監控中心，可構設出大概的架構圖：

結合Dubbo分析

在服務治理平臺的開發過程當中，開發難點和設計服務複雜度應該放在了服務註冊、服務監控上。

Dubbo是一個高性能服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案，使得應用可經過高性能RPC實現服務的輸出和輸入功能，和Spring框架能夠無縫集成。

問題分析

隨着業務不斷增加，爲了追求更高的性能支撐業務，集羣的引入使得服務架構的複雜度大大提高。龐大的集羣容易出現各類各樣的問題：

1. 過多的服務URL配置困難
2. 負載均衡分配節點壓力過大的狀況下也須要部署集羣
3. 服務依賴混亂，啓動順序不清晰
4. 過多服務致使性能指標分析難度較大，須要監控

架構分析

Dubbo註冊中心和監控中心的引入是服務治理的關鍵。

註冊中心的關鍵點：

• 服務提供者向註冊中心註冊其提供的服務
• 服務消費者向註冊中心獲取服務提供者地址列表，同時加上負載均衡的算法選擇服務提供者

監控中心的關鍵點：

• 服務消費者和提供者累計調用次數和調用時間，定時發送統計數據到監控中心

業務引入架構後，必需要保證的是，對當前業務的穩定性的影響只能是正面影響或者無影響，不能是負面影響。

考慮該架構對穩定性的影響：

• 註冊中心宕機狀況下，消費者在本地緩存了提供者列表，業務暫時不受影響，可是不能再註冊新的服務
• 監控中心宕機狀況下，不影響服務，隻影響部分採樣數據
• 服務提供方宕機後，經過負載均衡算法可將請求往別的同服務的提供方發送，對健壯性起正面做用

註冊中心和監控中心的引入在很大程度上提升了運行期的穩定性，對應了服務治理的工做。

考慮架構對其餘方面的影響：

• 可動態增長服務，由註冊中心統一動態分配
• 可動態增長消費方，由註冊中心統一動態分配

因而可知註冊中心的引入提升了伸縮性，對應了服務治理運行期所需工做。

而監控中心的引入，數據的採集和分析獲得的收益也是明顯的，對應的是服務治理運行期的服務監控以及服務治理持續治理下的服務資產管理。

先這樣吧

如有錯誤之處請指出，更多地關注煎魚。