大型微服務架構穩定性建設策略

對於大型應用後臺系統來說，穩定性至關重要。目前越來越多的大型應用系統採用微服務架構，更加需要關注穩定性的技術能力建設。穩定性是服務系統基礎能力的體現。

針對我們業務後臺系統建設，任何大型業務後臺系統絕對不是一蹴而就。它是伴隨著業務不同階段，不斷進行演進的過程。如果經歷過從 0 到 1 建設一個業務後臺系統的同學，都會有類似的體會。

01

啟動階段

啟動階段，業務模型相對簡單，使用者量少，這時候我們可以將所有的系統模組耦合在一個工程裡面，進行單機部署。這時候可能僅僅需要將業務系統與資料庫進行隔離。

02

探索階段

探索階段，業務模型不斷演進，使用者量增加，單機服務能力瓶頸凸顯。這時候就需要由單機服務部署向叢集服務部署來優化，利用負載均衡將請求合理分配，減少單機服務壓力。另外一個方面，資料量不斷的增加，也需要考慮針對資料來進行水平的擴充套件(主從部署，讀寫分離)。

在這一階段，我們僅僅是做了叢集擴充套件，但所有的業務程式碼都在同一個工程維護，所有的資料資訊都在同一個資料庫中儲存。隨著團隊的擴充與業務互動不斷複雜化，在工程維護上存在很大的風險，工程研發效率受到制約，業務程式碼之間的耦合也難以清晰，系統可靠性存在很大風險，一個 bug 可能會造成整個應用的崩潰不可用。

03

發展階段

如果我們比較幸運，業務持續快速發展，對於業務角色模型理解越來越清晰，業務角色模型之間的互動越來越確定。這時候就需要我們基於對業務充分的理解前提下進行垂直拆分。不同的業務模型會部署到不同的系統工程中，工程之間通過介面來進行互動。

這樣工程內業務高度集中，工程間通過介面服務來進行解耦。這時候不管是系統維護，還是業務模組維護，都將大大的提高效率。資料部分同樣垂直拆分，不同業務資料拆分到不同的資料庫，從而提高單機資料庫的能力。

拿電商系統的結構來說，如下圖所示：

基於業務模型分為幾個大的系統服務，系統服務之間通過內部 RPC 介面來進行互動。

04

成熟階段

上面是基於大的業務模型進行劃分，隨著業務複雜度越來越高，我們必將對大業務模型，基於功能或者業務邊界進行更細粒度的拆分。比如說，我們可以將產品中心劃分為：基礎資訊中心，庫存管理中心，SKU 中心等。

這時候就涉及到微服務的拆分與治理工作。

微服務的拆分原則我們應該注意：業務功能單一；服務間業務邊界清晰；拆分粒度合理；分層劃分合理。

從研發的角度來說，微服務帶來的好處：研發效率提升；程式碼質量更優；能夠獨立部署；單模組複雜度降低。上面提到的產品中心我們可以拆分很多小的服務來提供，如下圖所示：

細粒度的拆分，也會帶來一定的挑戰：

• 微服務劃分單元越細，整體服務維護非常複雜；

• 微服務通過 RPC 介面互動，整個鏈路可能會不清晰；

• 單服務的修改或者優化會受到其他模組的牽制。

當然這些挑戰都是我們需要思考與解決的問題，並不能抹殺微服務的優點。在這篇 Chat 文章裡，我係統的梳理了一下大型網站後臺穩定性的技術策略，堪稱“行動指南”！！

掃描下方二維碼檢視完整全文

進入讀者圈與作者深入交流

▼

點選閱讀原文，訂閱本場 Chat ，檢視完整原文！