談談為什麼需要服務治理（Dubbo）

摘要: 針對Java開發人員建立自己的技術體系和技術認知！

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

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

隨著業務的增長，服務不能一味地隨之增長，需要管理、治理。沒有服務治理的分散式系統不一定會失敗，但是隨著業務的增長，這個系統一定會很痛苦。

服務治理的目標

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

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

下面講講三個時期需要完整的工作：

服務設計期：

方案評審、開發測試審查、簽發認證、服務可發現

策略管理

合約定義、商談

標準化服務質量協議

服務執行期：

系統記錄：記錄交換的資訊

服務管理系統：控管、配置服務以及執行階段的元件，根據異常狀況重新配置環境

服務監控系統：採集資料，視覺化，提供變配證據

服務質量保證系統：增強通訊中的訊息和執行階段策略、安全性、可靠性、事務性、稽核等

服務持續治理：

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

根據上述目標，我們可以確定：

服務治理貫穿了服務的整個生命週期，包括開發前的設計、開發以及測試、執行、以及後續管理。

服務設計期主要針對於服務的設計評審以及標準的制定。

服務治理執行期的重點放在管理和監控，為了執行良好的目標，通過資料分析執行狀況，通過自動化消除異常、變配等。

服務治理後期的重點放在消除冗餘。

服務治理平臺設計

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

結合Dubbo分析

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

Dubbo是一個高效能服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案，使得應用可通過高效能RPC實現服務的輸出和輸入功能，和Spring框架可以無縫整合。

問題分析

隨著業務不斷增長，為了追求更高的效能支撐業務，叢集的引入使得服務架構的複雜度大大提升。龐大的叢集容易出現各種各樣的問題：

過多的服務URL配置困難

負載均衡分配節點壓力過大的情況下也需要部署叢集

服務依賴混亂，啟動順序不清晰

過多服務導致效能指標分析難度較大，需要監控

架構分析

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

註冊中心的關鍵點：

服務提供者向註冊中心註冊其提供的服務

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

監控中心的關鍵點：

服務消費者和提供者累計呼叫次數和呼叫時間，定時傳送統計資料到監控中心

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

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

註冊中心當機情況下，消費者在本地快取了提供者列表，業務暫時不受影響，但是不能再註冊新的服務

監控中心當機情況下，不影響服務，隻影響部分取樣資料

服務提供方當機後，通過負載均衡演算法可將請求往別的同服務的提供方傳送，對健壯性起正面作用

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

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

可動態增加服務，由註冊中心統一動態分配

可動態增加消費方，由註冊中心統一動態分配

由此可見註冊中心的引入提高了伸縮性，對應了服務治理執行期所需工作。

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

覺得有收穫的話大家也可以加JAVA架構群：725633148 裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化、分散式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源，目前受益良多！

這些視訊幫助以下幾類程式設計師：

1.對現在的薪資不滿，想要跳槽，卻對自己的技術沒有信心，不知道如何面對面試官。

2.想從傳統行業轉行到網際網路行業，但沒有接觸過網際網路技術。

3.工作1 - 5年需要提升自己的核心競爭力，但學習沒有系統化，不知道自己接下來要學什麼才是正確的，踩坑後又不知道找誰，百度後依然不知所以然。

4.工作5 - 10年無法突破技術瓶頸（運用過很多技術，在公司一直寫著業務程式碼，卻依然不懂底層實現原理）