微服務化產品線，每一個服務專心於自己的業務邏輯，並對外提供相應的介面，看上去似乎很明瞭，其實還有很多的東西需要考慮，比如：服務的自動擴充，熔斷和限流等，隨著業務的擴充套件，服務的數量也會隨之增多，邏輯會更加複雜，一個服務的某個邏輯需要依賴多個其他服務才能完成。一但一個依賴不能提供服務很可能會產生雪崩效應，最後導致整個服務不可訪問。
微服務之間進行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
- 半開狀態，根據
熔斷嘗試恢復時間來開啟，允許呼叫依賴，如果呼叫成功則關閉失敗則繼續開啟
具體的實現方式和對hystrix-go原始碼的分析，我在後續的帖子會詳細給大家介紹。