概述
高可用三劍客 限流，熔斷和削峰 終於來到第二篇, 熔斷降級專題了，想回顧限流相關內容的童鞋,可以查看一下，下面文章，歡迎點贊，收藏，關注三連，感謝！
限流系列文章：
僅以兩張圖來初步形容一下 熔斷 適用的場景:
- 雪崩
- 股災
什么是熔斷
來自 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 補習課，掌握第一手資料！ 回復 加群 交流。
如果本篇博客有任何錯誤，請批評指教，不勝感激 ！