談談服務雪崩、降級與熔斷
引言
首先，之所以談這個話題呢，是發現現在很多人對微服務的設計缺乏認識，所以寫一篇掃盲文。當然，考慮到目前大多微服務的文章都是口水文，煙哥爭取將實現方式講透，點清楚，讓大家有所收穫！
OK，我要先說明一下，我有很長一段時間將 服務降級 和 服務熔斷 混在一起，認為是一回事！
為什麼我會有這樣的誤解呢？
針對下面的情形，如圖所示
當 Service A 呼叫 Service B ，失敗多次達到一定閥值， Service A 不會再去調 Service B ，而會去執行本地的降級方法！
對於這麼一套機制:在Spring cloud中結合Hystrix,將其稱為熔斷降級!
所以我當時就以為是一回事了，畢竟熔斷和降級是一起發生的，而且這二者的概念太相近了！後面接觸了多了，發現自己理解的還是太狹隘了，因此本文中帶著點我自己的見解，大家如果有不同意見，請輕噴！畢竟還有很多人認為兩者是一致的！
正文
服務雪崩
OK，我們從服務雪崩開始講起！假設存在如下呼叫鏈
而此時， Service A 的流量波動很大，流量經常會突然性增加！那麼在這種情況下，就算 Service A 能扛得住請求， Service B 和 Service C 未必能扛得住這突發的請求。
此時，如果 Service C 因為抗不住請求，變得不可用。那麼 Service B 的請求也會阻塞，慢慢耗盡 Service B 的執行緒資源， Service B 就會變得不可用。緊接著， Service A 也會不可用，這一過程如下圖所示
如上圖所示，一個服務失敗，導致整條鏈路的服務都失敗的情形，我們稱之為服務雪崩。
ps： 誰發明的這個詞，真是面試裝13必備！
那麼，服務熔斷和服務降級就可以視為解決服務雪崩的手段之一。
服務熔斷
那麼，什麼是服務熔斷呢？
服務熔斷：當下遊的服務因為某種原因突然 變得不可用 或 響應過慢 ，上游服務為了保證自己整體服務的可用性，不再繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。
需要說明的是熔斷其實是一個框架級的處理，那麼這套熔斷機制的設計，基本上業內用的是 斷路器模式 ，如 Martin Fowler 提供的狀態轉換圖如下所示
- 最開始處於
closed狀態，一旦檢測到錯誤到達一定閾值，便轉為open狀態； - 這時候會有個 reset timeout，到了這個時間了，會轉移到
half open狀態； - 嘗試放行一部分請求到後端，一旦檢測成功便迴歸到
closed狀態，即恢復服務；
業內目前流行的熔斷器很多，例如阿里出的Sentinel,以及最多人使用的Hystrix
在Hystrix中，對應配置如下
//滑動視窗的大小，預設為20 circuitBreaker.requestVolumeThreshold //過多長時間，熔斷器再次檢測是否開啟，預設為5000，即5s鍾 circuitBreaker.sleepWindowInMilliseconds //錯誤率，預設50% circuitBreaker.errorThresholdPercentage
每當20個請求中，有50%失敗時，熔斷器就會開啟，此時再呼叫此服務，將會直接返回失敗，不再調遠端服務。直到5s鍾之後，重新檢測該觸發條件，判斷是否把熔斷器關閉，或者繼續開啟。
這些屬於框架層級的實現，我們只要實現對應介面就好！
服務降級
那麼，什麼是服務降級呢？
這裡有兩種場景:
- 當下遊的服務因為某種原因 響應過慢 ，下游服務主動停掉一些不太重要的業務，釋放出伺服器資源，增加響應速度！
- 當下遊的服務因為某種原因 不可用 ，上游主動呼叫本地的一些降級邏輯，避免卡頓，迅速返回給使用者！
其實乍看之下，很多人還是不懂熔斷和降級的區別!
其實應該要這麼理解:
- 服務降級有很多種降級方式！如開關降級、限流降級、熔斷降級!
- 服務熔斷屬於降級方式的一種！
可能有的人不服，覺得熔斷是熔斷、降級是降級，分明是兩回事啊！其實不然，因為從實現上來說，熔斷和降級必定是一起出現。因為當發生 下游服務不可用 的情況，這個時候為了對終端使用者負責，就需要 進入上游的降級邏輯 了。因此，將熔斷降級視為降級方式的一種，也是可以說的通的！
我撇開框架，以最簡單的程式碼來說明！上游程式碼如下
try{
//呼叫下游的helloWorld服務
xxRpc.helloWorld();
}catch(Exception e){
//因為熔斷，所以調不通
doSomething();
}
注意看，下游的helloWorld服務因為熔斷而調不通。此時上游服務就會進入catch裡頭的程式碼塊，那麼catch裡頭執行的邏輯，你就可以理解為降級邏輯!
什麼，你跟我說你不捕捉異常，直接丟頁面？
OK，那我甘拜下風，當我理解錯誤!
服務降級大多是屬於一種業務級別的處理，
當然，我這裡要講的是另一種降級方式，也就是 開關降級 !這也是我們生產上常用的另一種降級方式！
做法很簡單，做個開關，然後將開關放配置中心！在配置中心更改開關，決定哪些服務進行降級。至於配置變動後，應用怎麼監控到配置發生了變動，這就不是本文該討論的範圍。
那麼，在應用程式中部下開關的這個過程，業內也有一個名詞，稱為 埋點 ！
那接下來最關鍵的一個問題，哪些業務需要埋點？
一般有以下方法
(1)簡化執行流程
自己梳理出核心業務流程和非核心業務流程。然後在非核心業務流程上加上開關，一旦發現系統扛不住，關掉開關，結束這些次要流程。
(2)關閉次要功能
一個微服務下肯定有很多功能，那自己區分出主要功能和次要功能。然後次要功能加上開關，需要降級的時候，把次要功能關了吧！
(3)降低一致性
假設，你在業務上發現執行流程沒法簡化了，愁啊！也沒啥次要功能可以關了，桑心啊！那隻能降低一致性了，即將核心業務流程的同步改非同步，將強一致性改最終一致性！
可是這些都是手動降級，有辦法自動降級麼？
這裡我摸著良心說，我們在生產上沒弄自動降級！因為一般需要降級的場景，都是可以預見的，例如某某活動。假設，平時真的有突發事件，流量異常，也有監控系統發郵件通知，提醒我們去降級！
當然，這並不代表自動降級不能做，因此以下內容可以認為我在胡說八道，因為我在生產上沒實踐過，只是頭腦大概想了下，如果讓我來做自動降級我會怎麼實現：
- (1)自己設一個閾值，例如幾秒內失敗多少次，就啟動降級
- (2)自己做介面監控(有興趣的可以瞭解一下Rxjava)，達到閾值就走推送邏輯。怎麼推呢？比如你配置是放在git上，就用jgit去改配置中心的配置。如果配置放資料庫，就用jdbc去改。
- (3)改完配置中心的配置後，應用就可以自動檢測到配置的變化，進行降級！(這句不瞭解的，瞭解一下配置中心的熱重新整理功能)