引言
首先，之所以談這個話題呢，是發現現在很多人對微服務的設計缺乏認識，所以寫一篇掃盲文。當然，考慮到目前大多微服務的文章都是口水文，煙哥爭取將實現方式講透，點清楚，讓大家有所收穫！
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)改完配置中心的配置後，應用就可以自動檢測到配置的變化，進行降級！(這句不瞭解的，瞭解一下配置中心的熱刷新功能)