分佈式服務框架原理之基礎

分佈式服務框架的產生並非偶然，當企業的業務發展到一定的規模，包括業務的膨脹，商業模式的改變等都有可能會使舊的技術架構無法支持業務的快速發展及變化，為了保障業務的正常的擴展和擴張，通過採用分佈式服務框架可以很好的解決以上的問題。

為什麼要採用分佈式的服務框架呢？

首先，企業的業務是會隨著業務的發展而越來越完善，越來越臃腫，應用的功能越來越多，當應用功能變得龐大時，維護的成本會很高，數據庫的連接數也會持續變高。

其次，在敏捷交付上將會面臨具大挑戰，任何一個系統架構師或者開發者，想要從一個無比龐大的業務中修改一個功能，其難度是非常大的，因為A業務可能依賴B業務，B業務可能依賴C業務，如果你修改了C的功能，可能會影響到B和A。冗長的業務調用對系統的維護簡直是惡夢一般。完成開發後，還要投入大量的人工成本來進行功能的迴歸，這將使研發和測試長時間的投入，而長時間的投入意味著系統功能的長時間的無法交付。

傳統的解決壓力問題，通常會採用不斷增加硬件的方式來滿足應用的低延時和高吞吐。而分佈式的服務架構設計通常會將業務儘可能的拆分，以達到更好的業務伸縮性、獨立擴展性、更好的容錯、更靈活的部署、以及更高的開發效率，這也符合軟件設計的開閉原則及單一職責原則。

對業務進行拆分後，小而微的服務數據會越來越多，一個可實時監控和介入這些服務的服務治理框架的就顯得格外重要了，服務框架可以有效的管控服務，監控服務質量，並使開發人員能夠及時的介入服務質量較差的那些服務。

那麼一個優秀的服務治理框架要考慮哪些功能呢？

首先，要有服務生命週期控制管理的能力：能夠支持服務上線前的審批，服務下線通知的功能。避免服務混雜而不可控。

其次，要有服務運行時治理的能力：在大促期間，系統核心業務訪問量可能會飆升，服務治理要能夠對非核心服務採取降級限流的措施。非核心業務發生故障時，要能不影響業務通行，可以不進行遠程服務調用，採取調用本地降級的邏輯等。強大的服務治理能力，可以確保服務運行的質量。比如筆者接觸到過的爬蟲功能。曾經有同事因將大量的資源（代理服務器ip）投入到非核心功能上，導致核心抓取功能不可用，作為開發人員，要具備服務管理的基本能力，切勿本末倒置。

當然，除此之外，服務框架還要有服務安全治理的能力，如防止非法請求，對不同訪問級別作出不同的權限控制等功能。還要有服務的容量監控能力。比如何時添加機器，加多少，何種配置等等。訪問的qps，時延、成功率、系統資源的佔用指標，歷史訪問數據比對等，能夠對容量規劃提供精確的數據支持。

如果您喜歡這篇文章，記得點關注哦。