首先，之所以談這個話題呢，是發現現在很多人對微服務的設計缺乏認識，所以寫一篇掃盲文。當然，考慮到目前大多微服務的文章都是口水文，煙哥爭取將實現方式講透，點清楚，讓大家有所收穫！
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提供的狀態轉換圖如下所示
業內目前流行的熔斷器很多，例如阿里出的sentinel,以及最多人使用的hystrix
在hystrix中，對應配置如下
//滑動視窗的大小，預設為20
circuitbreaker.requestvolumethreshold
//過多長時間，熔斷器再次檢測是否開啟，預設為5000，即5s鐘
circuitbreaker.sleepwindowinmilliseconds
//錯誤率，預設50%
circuitbreaker.errorthresholdpercentage
這些屬於框架層級的實現，我們只要實現對應介面就好！
那麼，什麼是服務降級呢？
這裡有兩種場景:
其實乍看之下，很多人還是不懂熔斷和降級的區別!
其實應該要這麼理解:
可能有的人不服，覺得熔斷是熔斷、降級是降級，分明是兩回事啊！其實不然，因為從實現上來說，熔斷和降級必定是一起出現。因為當發生下游服務不可用的情況，這個時候為了對終端使用者負責，就需要進入上游的降級邏輯了。因此，將熔斷降級視為降級方式的一種，也是可以說的通的！
我撇開框架，以最簡單的**來說明！上游**如下
trycatch(exception e)什麼，你跟我說你不捕捉異常，直接丟頁面？
ok，那我甘拜下風，當我理解錯誤!
服務降級大多是屬於一種業務級別的處理。當然，我這裡要講的是另一種降級方式，也就是開關降級
!這也是我們生產上常用的另一種降級方式！
做法很簡單，做個開關，然後將開關放配置中心！在配置中心更改開關，決定哪些服務進行降級。至於配置變動後，應用怎麼監控到配置發生了變動，這就不是本文該討論的範圍。
那麼，在應用程式中部下開關的這個過程，業內也有乙個名詞，稱為埋點！
那接下來最關鍵的乙個問題，哪些業務需要埋點？
一般有以下方法
(1)簡化執行流程
自己梳理出核心業務流程和非核心業務流程。然後在非核心業務流程上加上開關，一旦發現系統扛不住，關掉開關，結束這些次要流程。
(2)關閉次要功能
乙個微服務下肯定有很多功能，那自己區分出主要功能和次要功能。然後次要功能加上開關，需要降級的時候，把次要功能關了吧！
(3)降低一致性
假設，你在業務上發現執行流程沒法簡化了，愁啊！也沒啥次要功能可以關了，桑心啊！那只能降低一致性了，即將核心業務流程的同步改非同步，將強一致性改最終一致性！
可是這些都是手動降級，有辦法自動降級麼？
這裡我摸著良心說，我們在生產上沒弄自動降級！因為一般需要降級的場景，都是可以預見的，例如某某活動。假設，平時真的有突發事件，流量異常，也有監控系統發郵件通知，提醒我們去降級！
當然，這並不代表自動降級不能做，因此以下內容可以認為我在胡說八道，因為我在生產上沒實踐過，只是頭腦大概想了下，如果讓我來做自動降級我會怎麼實現：
SpringCloud 服務雪崩，降級 ，熔斷
有很多人將服務降級和服務熔斷混在一起，認為是一回事！為什麼有這樣的誤解呢？當服務a呼叫服務b，失敗多次達到一定閥值，服務a不會再去調服務b，而會去執行本地的降級方法！對於這麼一套機制 在spring cloud中結合hystrix,將其稱為熔斷降級 所以就以為是一回事了，畢竟熔斷和降級是一起發生的，...
服務雪崩 服務熔斷 服務降級 基礎概念
服務雪崩的概念簡單的理解為，一條服務鏈a 使用者服務 b 訂單服務 c 支付服務 三個服務，分別是a呼叫b，b呼叫c。一般而言任務量最大的是底層服務c。服務c如果掛了 宕機 導致b服務間接也不可用 b服務不可用又間接導致a不可用。這樣這條服務鏈a b c也就全部掛了，就像雪崩一樣，因為乙個服務不可用...
服務熔斷與降級
服務熔斷的作用類似於我們家用的保險絲，當某服務出現不可用或響應超時的情況時，為了防止整個系統出現雪崩，暫時停止對該服務的呼叫。服務降級是從整個系統的負荷情況出發和考慮的，對某些負荷會比較高的情況，為了預防某些功能 業務場景 出現負荷過載或者響應慢的情況，在其內部暫時捨棄對一些非核心的介面和資料的請求...