僅以兩張圖來初步形容一下 熔斷 適用的場景:

• 雪崩

• 股災

?

什么是熔斷

來自 wiki 的 熔斷機制 描述：

熔斷機制（英語：Circuit breaker / Trading curb）指的是在股票市場的交易時間中， 當價格波動的幅度達到某一個限定的目標（熔斷點）時，對其暫停交易一段時間的機制。 此機制如同保險絲在電流過大時候熔斷，故而得名。熔斷機制推出的目的是為了防范系統性風險，給市場更多的冷靜時間，避免恐慌情緒蔓延導致市場波動， 從而防止大規模股價下跌現象的發生。 然而熔斷機制也因切斷了資金的流通性，同樣會造成市場情緒加大，并令市場風險在熔斷期結束后繼續擴大。

轉換成互聯網語言可以這么理解:

• 當異常幅度達到設定的閥值后觸發的系統保護機制

• 保護機制會將某部分能力關閉，以保證大部分能力的正常

• 這種機制是有損的，但是利大于端

熔斷機制的特點，在關閉一段時間后，會自動觸發恢復檢測，如果發現服務正常，則將服務逐漸開放。

1、雪崩效應

在分布式服務部署的架構下，整體鏈路可以參考為：

image.png

如果在大促期間， DB_2 由于 機器負載過高，sql執行緩慢，鏈接數打滿 或網絡抖動等情況，導致 DB_2 不可用，那么整體鏈路的影響就會變成：

image.png

服務雪崩的每個階段都可能由不同的原因造成, 比如造成 服務不可用 的原因有:

• 硬件故障

• 程序Bug

• 緩存擊穿

• 用戶大量請求

2、雪崩處理策略

• 流量控制：限流和削峰都屬于流量控制的一種策略

• 緩存優化：在上述案例中，DB 由于壓力過大導致的雪崩，可以引入緩存，減輕DB壓力

• 服務降級：通過異常分支鏈路的快速失敗，確保主鏈路正常提供服務

• 應用擴容：針對機器壓力過大，負載過高，可以通過機器擴容來解決，緩解流量壓力

?

斷路器模式

熔斷器模式（Circuit Breaker Pattern），是一個現代軟件開發的設計模式。用以偵測錯誤，并避免不斷地觸發相同的錯誤（如維護時服務不可用、暫時性的系統問題或是未知的系統錯誤）。

狀態描述：

• 關閉：熔斷器默認處于關閉狀態，熔斷器本身帶有計數能力（如滑動窗口實現）,當失敗數量達到預設閥值后，觸發狀態變更，熔斷器被打開

• 開啟：在一定時間內，所有請求都會被拒絕，或采用備用鏈路處理。

• 半開啟：在刷新時間窗口后，會進入半開啟狀態,熔斷器嘗試接受請求，如果這階段出現請求失敗，直接恢復到開啟狀態。

image.png

?

隔離策略

1、線程隔離

Hystrix 采用了 Bulkhead Partition艙壁隔離技術，來將外部依賴進行資源隔離，進而避免任何外部依賴的故障導致本服務崩潰。

艙壁隔離，是說將船體內部空間區隔劃分成若干個隔艙，一旦某幾個隔艙發生破損進水，水流不會在其間相互流動，如此一來船舶在受損時，依然能具有足夠的浮力和穩定性，進而減低立即沉船的危險。

image.png

圖片來源：《防雪崩利器：熔斷器 Hystrix 的原理與使用》

Hystrix 在線程池隔離實現主要解決一下場景：

在商品詳情系統中，如果沒有對服務做降級措施，那么當評論服務出現異常時，整個商品詳情系統都會受到影響，最終導致用戶無法查看商品詳情。

在這個例子中，商品詳情服務，從請求入口分配線程處理，對每個服務使用同一個線程進行處理（同步），在評論服務出現異常時（響應緩慢，處理超時，服務異常等）,導致整個線程阻塞，服務端響應超時，觸發用戶重試刷新請求，最終導致服務雪崩，系統崩潰。

image.png

Hystrix 線程池隔離方案；

hystrix把每個依賴都進行隔離，對依賴的調用全部包裝成HystrixCommand或者HystrixObservableCommand 在服務調用時，分配獨立的線程池進行資源隔離調用，如下圖中的評論服務出現不可用時，商品詳情系統還是能夠將商品信息，大促信息封裝好返回給用戶。評論服務的異常，并不會影響其他依賴的調用。

image.png

線程隔離特點

優點：

• 一個依賴可以給予一個線程池，這個依賴的異常不會影響其他的依賴。

• 使用線程可以完全隔離第三方代碼,請求線程可以快速放回。

• 當一個失敗的依賴再次變成可用時，線程池將清理，并立即恢復可用，而不是一個長時間的恢復。

• 可以完全模擬異步調用，方便異步編程。

• 使用線程池，可以有效的進行實時監控、統計和封裝。

缺點：

• 使用線程池的缺點主要是增加了計算的開銷。每一個依賴調用都會涉及到隊列，調度，上下文切換，而這些操作都有可能在不同的線程中執行。

線程切換的性能損耗問題

Netflix在使用過程中詳細評估了使用異步線程和同步線程帶來的性能差異，結果表明在99%的情況下，異步線程帶來的幾毫秒延遲的完全可以接受的

2、信號量隔離

Hystrix 的信號量隔離限制對某個資源調用的異常比例。

Sentinel 在信號量隔離的限制上提供了更多的策略選擇，基于慢調用比例、異常比例和異常數。

信號量隔離實現原理

Sentinel 底層采用高性能的滑動窗口數據結構 LeapArray 來統計實時的秒級指標數據，在 信號量隔離的底層實現中， 通過根據不同的策略，如 異常數 策略，統計在 滑動窗口區間內， 異常請求量的比例，來決定對服務進行熔斷降級處理。

滑動窗口示意圖：

image.png

1、慢調用比例 (SLOW_REQUEST_RATIO) 設置允許的慢調用 RT（即最大的響應時間），請求的響應時間大于該值則統計為慢調用。當調用請求數量大于閥值，觸發熔斷。閥值設置，100ms響應，10個請求 如下圖所示：

image.png

2、異常比例 (ERROR_RATIO

當單位統計時長內請求數目大于設置的最小請求數目，并且異常的比例大于閾值，則接下來的熔斷時長內請求會自動被熔斷。閥值設置 20% 如下圖所示：

image.png

3、異常數 (ERROR_COUNT)

當單位統計時長內的異常數目超過閾值之后會自動進行熔斷。閥值設置 5 如圖所示：

image.png

?

熔斷降級組件對比

image.png

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之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的面试官：熔断降级原理是什么？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。