有很多人將服務降級和服務熔斷混在一起，認為是一回事！為什麼有這樣的誤解呢？
當服務a呼叫服務b，失敗多次達到一定閥值，服務a不會再去調服務b，而會去執行本地的降級方法！
對於這麼一套機制:在spring cloud中結合hystrix,將其稱為熔斷降級!
所以就以為是一回事了，畢竟熔斷和降級是一起發生的，而且這二者的概念太相近了！
而此時，service a的流量波動很大，流量經常會突然性增加！那麼在這種情況下，就算service a能扛得住請求，service b和service c未必能扛得住這突發的請求。
此時，如果service c因為抗不住請求，變得不可用。那麼service b的請求也會阻塞，慢慢耗盡service b的執行緒資源，service b就會變得不可用。緊接著，service a也會不可用，這一過程如下圖所示
如上圖所示，乙個服務失敗，導致整條鏈路的服務都失敗的情形，我們稱之為服務雪崩。
那麼，服務熔斷和服務降級就可以視為解決服務雪崩的手段之一。
服務熔斷：當下游的服務因為某種原因突然變得不可用或響應過慢，上游服務為了保證自己整體服務的可用性，不再繼續呼叫目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復呼叫。
需要說明的是熔斷其實是乙個框架級的處理，那麼這套熔斷機制的設計，基本上業內用的是斷路器模式，如martin fowler提供的狀態轉換圖如下所示
目前流行的熔斷器很多，例如阿里出的sentinel,以及最多人使用的hystrix,在hystrix中，對應配置如下
//滑動視窗的大小，預設為20
circuitbreaker.requestvolumethreshold
//過多長時間，熔斷器再次檢測是否開啟，預設為5000，即5s鐘
circuitbreaker.sleepwindowinmilliseconds
//錯誤率，預設50%
circuitbreaker.errorthresholdpercentage
這些屬於框架層級的實現，我們只要實現對應介面就好！
其實乍看之下，很多人還是不懂熔斷和降級的區別!其實應該要這麼理解:
可能有的人不服，覺得熔斷是熔斷、降級是降級，分明是兩回事啊！其實不然，因為從實現上來說，熔斷和降級必定是一起出現。
因為當發生下游服務不可用的情況，這個時候為了對終端使用者負責，就需要進入上游的降級邏輯了。因此，將熔斷降級視為降級方式的一種，也是可以說的通的！
我撇開框架，以最簡單的**來說明！上游**如下
try注意看，下游的helloworld服務因為熔斷而調不通。此時上游服務就會進入catch裡頭的**塊，那麼catch裡頭執行的邏輯，你就可以理解為降級邏輯!catch
(exception e)
服務雪崩效應
服務雪崩效應是一種因服務提供者的不可用導致服務呼叫者的不可用,並將不可用逐漸放大的過程。我把服務雪崩的參與者簡化為服務提供者和服務呼叫者,並將服務雪崩產生的過程分為以下三個階段來分析形成的原因 服務提供者不可用 重試加大流量 服務呼叫者不可用 服務雪崩的每個階段都可能由不同的原因造成,比如造成服務不...
SpringCloud服務調服務
org.springframework.cloud spring cloud starter feign enablefeignclients configuration public class mybatisplusconfig 資料許可權外掛程式 return datascopeinterce...
springcloud 服務降級
降級就是將一些不常用的服務停掉從而釋放更多的資源來 一些主要的服務使用 1.服務降級中有很多的方法，最好的方式就是利用 docker 來實現，當 需要對某個服務進行降級時可以直接將這個服務的容器停掉，等到需要使用時在把這個服務重啟就行。2.通過api閘道器的方式進行降級這樣我們的就可以將前台的一切請...