服務熔斷
熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。我們在各種場景下都會接觸到熔斷這兩個字。高壓電路中，如果某個地方的電壓過高，熔斷器就會熔斷，對電路進行保護。股票交易中，如果股票指數過高，也會採用熔斷機制，暫停股票的交易。同樣，在微服務架構中，熔斷機制也是起著類似的作用。當扇出鏈路的某個微服務不可用或者響應時間太長時，熔斷該節點微服務的呼叫，進行服務的降級，快速返回錯誤的響應資訊。當檢測到該節點微服務呼叫響應正常後，恢復呼叫鏈路。
注意：
1）服務熔斷重點在“斷”，切斷對下游服務的呼叫
2）服務熔斷和服務降級往往是一起使用的，Hystrix就是這樣。

服務降級
通俗講就是整體資源不夠用了，先將一些不關緊的服務停掉（呼叫我的時候，給你返回一個預留的值，也叫做兜底資料），待渡過難關高峰過去,再把那些服務開啟。
服務降級一般是從整體考慮，就是當某個服務熔斷之後，伺服器將不再被呼叫，此刻客戶端可以自己準備一個本地的fallback回撥，返回一個預設值，這樣做，雖然服務水平下降，但好歹可用，比直接掛掉要強。

服務限流
服務降級是當服務出問題或者影響到核心流程的效能時，暫時將服務遮蔽掉，待高峰或者問題解決後再開啟；但是有些場景並不能用服務降級來解決，比如秒殺業務這樣的核心功能，這個時候可以結合服務限流來限制這些場景的併發/請求量
限流措施也很多，比如
限制總併發數（比如資料庫連線池、執行緒池）
限制瞬時併發數（如nginx限制瞬時併發連線數）
限制時間視窗內的平均速率（如Guava的RateLimiter、nginx的limit_req模組，限制每秒的平均速率）
限制遠端介面呼叫速率、限制MQ的消費速率等

Hystrix艙壁模式

即：執行緒池隔離策略
如果不進行任何設定，所有熔斷方法使用一個Hystrix執行緒池（10個執行緒），那麼這樣的話會導致問題，這個問題並不是扇出鏈路微服務不可用導致的，而是我們的執行緒機制導致的，如果方法A的請求把10個執行緒都用了，方法2請求處理的時候壓根都沒法去訪問B，因為沒有執行緒可用，並不是B服務不可用。

 為了避免問題服務請求過多導致正常服務無法訪問，Hystrix 不是採用增加執行緒數，而是單獨的為每一個控制方法建立一個執行緒池的方式，這種模式叫做“艙壁模式"，也是執行緒隔離的手段。

Hystrix工作流程與高階應用

1）當調用出現問題時，開啟一個時間窗（10s）
2）在這個時間窗內，統計呼叫次數是否達到最小請求數？
如果沒有達到，則重置統計資訊，回到第1步
如果達到了，則統計失敗的請求數佔所有請求數的百分比，是否達到閾值？
如果達到，則跳閘（不再請求對應服務）
如果沒有達到，則重置統計資訊，回到第1步
3）如果跳閘，則會開啟一個活動視窗（預設5s），每隔5s，Hystrix會讓一個請求通過,到達那個問題服務，看是否呼叫成功，如果成功，重置斷路器回到第1步，如果失敗，回到第3步