java架構師必備技能之微服務架構—雪崩效應

微服務化產品線，每個服務專心於本身的業務邏輯，並對外提供相應的接口，看上去彷佛很明瞭，其實還有不少的東西須要考慮，好比：服務的自動擴充，熔斷和限流等，隨着業務的擴展，服務的數量也會隨之增多，邏輯會更加複雜，一個服務的某個邏輯須要依賴多個其餘服務才能完成。一但一個依賴不能提供服務極可能會產生雪崩效應，最後致使整個服務不可訪問。

微服務之間進行rpc或者http調用時，咱們通常都會設置調用超時，失敗重試等機制來確保服務的成功執行，看上去很美，若是不考慮服務的熔斷和限流，就是雪崩的源頭。

假設咱們有兩個訪問量比較大的服務A和B，這兩個服務分別依賴C和D,C和D服務都依賴E服務

A和B不斷的調用C,D處理客戶請求和返回須要的數據。當E服務不能供服務的時候，C和D的超時和重試機制會被執行

因爲新的調用不斷的產生，會致使C和D對E服務的調用大量的積壓，產生大量的調用等待和重試調用，慢慢會耗盡C和D的資源好比內存或CPU，而後也down掉。

A和B服務會重複C和D的操做，資源耗盡，而後down掉，最終整個服務都不可訪問。

常見的致使雪崩的狀況有如下幾種：

• 程序bug致使服務不可用，或者運行緩慢
• 緩存擊穿，致使調用所有訪問某服務，致使down掉
• 訪問量的忽然激增。
• 硬件問題，這感受只能說是點背了⊙︿⊙。

雖然雪崩效應的產生千萬條，保證服務的不掛機，和流暢運行是咱們不可推卸的責任，對應雪崩效應仍是有不少保護方案的。

服務的橫向擴充

如今咱們能夠利用不少工具來保證服務不會掛掉，而後流量比較大的時候，能夠橫向擴充服務來保證業務的流暢。好比咱們最常使用k8s，能保證服務的運行狀態，也可讓服務自動的橫向擴充。對於用戶訪問量的激增狀況這樣處理仍是很不錯的，可是，橫向擴充也是有盡頭的，若是在必定環境下E服務的響應時間過長，依然有可能致使雪崩效應的產生。

限流

限制客戶端的調用來達到限流的作法是很常見的，好比，咱們限制每秒最大處理200個請求，超過個數量直接拒絕請求。常見的算法如令牌桶算法

以必定的速度在桶裏放令牌，當客戶端請求服務的時候，要先從桶裏獲得令牌，才能被處理，若是桶裏的令牌用完了，則拒絕訪問。

熔斷

在客戶端控制對依賴的訪問，若是調用的依賴不可用時，則再也不調用，直接返回錯誤，或者降級處理。開源的庫好比hystrix-go，也是我接下來要寫的源碼分析的一個庫。很好的實現了熔斷和降級的功能。他的主要思想是，設置一些閥值，好比，最大併發數，錯誤率百分比，熔斷嘗試恢復時間等。能過這些閥值來轉換熔斷器的狀態：

• 關閉狀態，容許調用依賴
• 打開狀態，不容許調用依賴，直接返回錯誤，或者調用fallback
• 半開狀態，根據熔斷嘗試恢復時間來開啓，容許調用依賴，若是調用成功則關閉失敗則繼續打開

本文到此結束!喜歡的朋友幫忙轉發文章和關注一下！感謝！！！

Java學習、面試；文檔、視頻資源免費獲取