概述
高可用三劍客 限流，熔斷和削峰 終於來到第二篇, 熔斷降級專題了，想回顧限流相關內容的童鞋,可以檢視一下，下面文章，歡迎點贊，收藏，關注三連，感謝！
限流系列文章：
僅以兩張圖來初步形容一下 熔斷 適用的場景:
- 雪崩
- 股災
什麼是熔斷
來自 wiki 的 熔斷機制 描述：
熔斷機制（英語：Circuit breaker / Trading curb）指的是在股票市場的交易時間中，
當價格波動的幅度達到某一個限定的目標（熔斷點）時，對其暫停交易一段時間的機制。
此機制如同保險絲在電流過大時候熔斷，故而得名。
熔斷機制推出的目的是為了防範系統性風險，給市場更多的冷靜時間，避免恐慌情緒蔓延導致市場波動，
從而防止大規模股價下跌現象的發生。
然而熔斷機制也因切斷了資金的流通性，同樣會造成市場情緒加大，並令市場風險在熔斷期結束後繼續擴大。
轉換成網際網路語言可以這麼理解:
- 當
異常幅度達到設定的閥值後觸發的系統保護機制 - 保護機制會將某
部分能力關閉，以保證大部分能力的正常 - 這種機制是有損的，但是
利大於端
熔斷機制的特點，在關閉一段時間後，會自動觸發恢復檢測，如果發現服務正常，則將服務逐漸開放。
1、雪崩效應
在分散式服務部署的架構下，整體鏈路可以參考為：
如果在大促期間， DB_2 由於 機器負載過高，sql執行緩慢，連結數打滿 或網路抖動等情況，導致 DB_2 不可用，那麼整體鏈路的影響就會變成：
服務雪崩的每個階段都可能由不同的原因造成, 比如造成 服務不可用 的原因有:
- 硬體故障
- 程式Bug
- 快取擊穿
- 使用者大量請求
2、雪崩處理策略
- 流量控制：
限流和削峰都屬於流量控制的一種策略 - 快取優化： 在上述案例中，
DB由於壓力過大導致的雪崩，可以引入快取，減輕DB壓力 - 服務降級： 通過異常
分支鏈路的快速失敗，確保主鏈路正常提供服務 - 應用擴容： 針對
機器壓力過大，負載過高，可以通過機器擴容來解決，緩解流量壓力
斷路器模式
熔斷器模式（Circuit Breaker Pattern），是一個現代軟體開發的設計模式。用以偵測錯誤，並避免不斷地觸發相同的錯誤（如維護時服務不可用、暫時性的系統問題或是未知的系統錯誤）。
狀態描述：
關閉：熔斷器預設處於關閉狀態，熔斷器本身帶有計數能力（如滑動視窗實現）,當失敗數量達到預設閥值後，觸發狀態變更，熔斷器被開啟開啟：在一定時間內，所有請求都會被拒絕，或採用備用鏈路處理。半開啟： 在重新整理時間視窗後，會進入半開啟狀態,熔斷器嘗試接受請求，如果這階段出現請求失敗，直接恢復到開啟狀態。
隔離策略
1、執行緒隔離
Hystrix 採用了 Bulkhead Partition 艙壁隔離技術，來將外部依賴進行資源隔離，進而避免任何外部依賴的故障導致本服務崩潰。
艙壁隔離，是說將船體內部空間區隔劃分成若干個隔艙，一旦某幾個隔艙發生破損進水，水流不會在其間相互流動，如此一來船舶在受損時，依然能具有足夠的浮力和穩定性，進而減低立即沉船的危險。
圖片來源： 《防雪崩利器：熔斷器 Hystrix 的原理與使用》
Hystrix 線上程池隔離實現主要解決一下場景：
在商品詳情繫統中，如果沒有對服務做降級措施，那麼當評論服務出現異常時，整個商品詳情繫統都會受到影響，最終導致使用者無法檢視商品詳情。
在這個例子中，商品詳情服務，從請求入口分配執行緒處理，對每個服務使用同一個執行緒進行處理（同步），在評論服務出現異常時（響應緩慢，處理超時，服務異常等）,導致整個執行緒阻塞，服務端響應超時，觸發使用者重試重新整理請求，最終導致服務雪崩，系統崩潰。
Hystrix 執行緒池隔離方案；
hystrix把每個依賴都進行隔離，對依賴的呼叫全部包裝成HystrixCommand或者HystrixObservableCommand 在服務呼叫時，分配獨立的執行緒池進行資源隔離呼叫，如下圖中的評論服務出現不可用時，商品詳情繫統還是能夠將商品資訊，大促資訊封裝好返回給使用者。評論服務的異常，並不會影響其他依賴的呼叫。
執行緒隔離特點
優點：
- 一個依賴可以給予一個執行緒池，這個依賴的異常不會影響其他的依賴。
- 使用執行緒可以完全隔離第三方程式碼,請求執行緒可以快速放回。
- 當一個失敗的依賴再次變成可用時，執行緒池將清理，並立即恢復可用，而不是一個長時間的恢復。
- 可以完全模擬非同步呼叫，方便非同步程式設計。
- 使用執行緒池，可以有效的進行實時監控、統計和封裝。
缺點：
- 使用執行緒池的缺點主要是增加了計算的開銷。每一個依賴呼叫都會涉及到佇列，排程，上下文切換，而這些操作都有可能在不同的執行緒中執行。
執行緒切換的效能損耗問題
Netflix在使用過程中詳細評估了使用非同步執行緒和同步執行緒帶來的效能差異，結果表明在99%的情況下，非同步執行緒帶來的幾毫秒延遲的完全可以接受的
2、訊號量隔離
Hystrix 的訊號量隔離限制對某個資源呼叫的異常比例。
Sentinel 在訊號量隔離的限制上提供了更多的策略選擇，基於慢呼叫比例、異常比例和異常數。
訊號量隔離實現原理
Sentinel 底層採用高效能的滑動視窗資料結構 LeapArray 來統計實時的秒級指標資料，在 訊號量隔離的底層實現中， 通過根據不同的策略，如 異常數 策略，統計在 滑動視窗區間內， 異常請求量的比例，來決定對服務進行熔斷降級處理。
滑動視窗示意圖：
1、慢呼叫比例 (SLOW_REQUEST_RATIO)
設定允許的慢呼叫 RT（即最大的響應時間），請求的響應時間大於該值則統計為慢呼叫。當呼叫請求數量大於閥值，觸發熔斷。閥值設定，100ms響應，10個請求 如下圖所示：
2、異常比例 (ERROR_RATIO
當單位統計時長內請求數目大於設定的最小請求數目，並且異常的比例大於閾值，則接下來的熔斷時長內請求會自動被熔斷。閥值設定 20% 如下圖所示：
3、異常數 (ERROR_COUNT)
當單位統計時長內的異常數目超過閾值之後會自動進行熔斷。閥值設定 5 如圖所示：
熔斷降級元件對比
Sentinel
Sentinel是阿里中介軟體團隊開源的，面向分散式服務架構的輕量級高可用流量控制元件，主要以流量為切入點，從流量控制、熔斷降級、系統負載保護等多個維度來幫助使用者保護服務的穩定性。
Sentinel 的側重點在於：
- 多樣化的流量控制
- 熔斷降級
- 系統負載保護
- 實時監控和控制檯
Hystrix
Hystrix是Netflix開源的一款容錯系統，能幫助使用者碼出具備強大的容錯能力和魯棒性的程式。提供降級，熔斷等功能。在2018年底，Hystrix在其Github主頁宣佈，不再開放新功能，推薦開發者使用其他仍然活躍的開源專案。
官方 wiki 描述：
Hystrix is designed to do the following:
Give protection from and control over latency and failure from dependencies accessed (typically over the network) via third-party client libraries.
Stop cascading failures in a complex distributed system.
Fail fast and rapidly recover.
Fallback and gracefully degrade when possible.
Enable near real-time monitoring, alerting, and operational control.
- 對通過第三方客戶端庫訪問的依賴項（通常是通過網路）的延遲和故障進行保護和控制。
- 在複雜的分散式系統中阻止級聯故障。
- 快速失敗，快速恢復。
- 回退，儘可能優雅地降級。
- 啟用近實時監控、警報和操作控制。
resilience4j
resilience4j是一個輕量、易用、可組裝的高可用框架，支援熔斷、高頻控制、隔離、限流、限時、重試等多種高可用機制。Netflix 官方在停止維護 Hystrix 後，推薦使用 resilience4j 作為替代方案。
與Hystrix相比，它有以下一些主要的區別：
- Hystrix呼叫必須被封裝到HystrixCommand裡，而resilience4j以裝飾器的方式提供對函式式介面、lambda表示式等的巢狀裝飾，因此你可以用簡潔的方式組合多種高可用機制
- Hystrix的頻次統計採用滑動視窗的方式，而resilience4j採用環狀緩衝區的方式
- 關於熔斷器在半開狀態時的狀態轉換，Hystrix僅使用一次執行判定是否進行狀態轉換，而resilience4j則採用可配置的執行次數與閾值，來決定是否進行狀態轉換，這種方式提高了熔斷機制的穩定性
- 關於隔離機制，Hystrix提供基於執行緒池和訊號量的隔離，而resilience4j只提供基於訊號量的隔離
點關注，不迷路
好了各位，以上就是這篇文章的全部內容了，我後面會每週都更新幾篇高質量的大廠面試和常用技術棧相關的文章。感謝大夥能看到這裡，如果這個文章寫得還不錯， 求三連！！！ 創作不易，感謝各位的支援和認可，我們下篇文章見！
我是 九靈 , 關注公眾號：Java 補習課，掌握第一手資料！ 回覆 加群 交流。
如果本篇部落格有任何錯誤，請批評指教，不勝感激 ！