熔斷機制

概念

• 服務熔斷

當下遊的服務由於某種緣由忽然變得不可用或響應過慢，上游服務爲了保證本身總體服務的可用性，再也不繼續調用目標服務，直接返回，快速釋放資源。若是目標服務狀況好轉則恢復調用。

通常是指軟件系統中，因爲某些緣由使得服務出現了過載現象，爲防止形成整個系統故障，從而採用的一種保護措施，因此不少地方把熔斷亦稱爲過載保護。
適用場景：防止應用程序直接調用那些極可能會調用失敗的遠程服務或共享資源

• 服務降級

當服務器壓力劇增的狀況下，根據當前業務狀況及流量對一些服務和頁面有策略的降級，以此釋放服務器資源以保證核心任務的正常運行。

應該這麼理解：服務降級有不少種降級方式，如開關降級、限流降級、熔斷降級。服務熔斷屬於降級方式的一種！

• 雪崩效應

一種因 服務提供者 的不可用致使 服務調用者 的不可用,並將不可用 逐漸放大 的過程

分佈式系統中常常會出現某個基礎服務不可用形成整個系統不可用的狀況, 這種現象被稱爲服務雪崩效應.。如：在分佈式系統架構中多個系統之間一般是經過遠程RPC調用進行通訊，也就是 A 系統調用 B 系統服務，B 系統調用 C 系統的服務。當尾部應用 C 發生故障而系統 B 沒有服務降級時候可能會致使 B，甚至系統 A 癱瘓。

爲了應對服務雪崩, 一種常見的作法是手動服務降級. 而Hystrix的出現,給咱們提供了另外一種選擇.

　

雪崩效應造成緣由：

• 服務提供者不可用 

a）硬件故障：硬件損壞形成的服務器主機宕機， 網絡硬件故障形成的服務提供者的不可訪問

b）程序Bug

c）緩存擊穿：通常發生在緩存應用重啓，全部緩存被清空時，以及短期內大量緩存失效時，大量的緩存不命中，使請求直擊後端，形成服務提供者超負荷運行，引發服務不可用

d）用戶大量請求：在秒殺和大促開始前，若是準備不充分，用戶發起大量請求也會形成服務提供者的不可用

• 重試加大流量

a）用戶重試：在服務提供者不可用後， 用戶因爲忍受不了界面上長時間的等待,而不斷刷新頁面甚至提交表單

b）代碼邏輯重試： 服務調用端的會存在大量服務異常後的重試邏輯

• 服務調用者不可用

a）同步等待形成的資源耗盡：當服務調用者使用 同步調用  時, 會產生大量的等待線程佔用系統資源. 一旦線程資源被耗盡,服務調用者提供的服務也將處於不可用狀態, 因而服務雪崩效應產生了。

服務雪崩的應對策略：

• 流量控制

a）網關限流：由於Nginx的高性能, 目前一線互聯網公司大量採用Nginx+Lua的網關進行流量控制, 由此而來的OpenResty也愈來愈熱門

b）用戶交互限流：具體措施有： 1. 採用加載動畫,提升用戶的忍耐等待時間. 2. 提交按鈕添增強制等待時間機制.

c）關閉重試

• 改進緩存模式

a）緩存預加載

b）同步改成異步刷新

• 服務自動擴容

a）AWS的auto scaling

• 服務調用者降級服務

a）資源隔離：主要是對調用服務的線程池進行隔離

b）對依賴服務進行分類：根據具體業務，將依賴服務分爲： 強依賴和若依賴。強依賴服務不可用會致使當前業務停止，而弱依賴服務不可用不會致使當前業務停止

c）不可用服務的調用快速失敗：通常經過 超時機制, 熔斷器 和熔斷後的 降級方法 來實現

使用Hystrix預防服務雪崩

Netflix的 Hystrix 是一個幫助解決分佈式系統交互時超時處理和容錯的類庫，它擁有保護系統的能力.

Hystrix的設計原則包括：

• 資源隔離
• 熔斷器（Circuit Breaker）
• 命令模式

資源隔離

• 線程隔離

貨船爲了防止漏水和火災的擴散，將貨倉分隔爲多個，這種資源隔離減小風險的方式被稱爲Bulkheads(艙壁隔離模式)。Hystrix將一樣的模式運用到了服務調用者上。

在一個高度服務化的系統中，咱們實現的一個業務邏輯一般會依賴多個服務，好比: 商品詳情展現服務會依賴商品服務、 價格服務、商品評論服務。調用三個依賴服務會共享商品詳情服務的線程池， 若是其中的商品評論服務不可用， 就會出現線程池裏全部線程都因等待響應而被阻塞，從而形成服務雪崩。 如圖所示：

 

Hystrix經過將每一個依賴服務分配獨立的線程池進行資源隔離，用戶的請求將再也不直接訪問服務，而是經過線程池中的空閒線程來訪問服務，若是線程池已滿，則會進行降級處理，用戶的請求不會被阻塞，至少能夠看到一個執行結果（例如返回友好的提示信息），而不是無休止的等待或者看到系統崩潰。以下圖所示, 當商品評論服務不可用時， 即便商品服務獨立分配的20個線程所有處於同步等待狀態，也不會影響其餘依賴服務的調用.

• 信號隔離

信號隔離也能夠用於限制併發訪問，防止阻塞擴散，與線程隔離最大不一樣在於執行依賴代碼的線程依然是請求線程（該線程須要經過信號申請，若是客戶端是可信的且能夠快速返回，可使用信號隔離替換線程隔離，下降開銷。信號量的大小能夠動態調整，線程池大小不能夠。

熔斷器模式

熔斷器是位於線程池以前的組件。用戶請求某一服務以後，Hystrix會先通過熔斷器，此時若是熔斷器的狀態是打開，這時將直接進行降級處理，不會繼續將請求發到線程池。熔斷器至關於在線程池以前的一層屏障。每一個熔斷器默認維護10個bucket ，每秒建立一個bucket ，每一個blucket記錄成功,失敗,超時,拒絕的次數。當有新的bucket被建立時，最舊的bucket會被拋棄。

熔斷器模式定義了熔斷器開關相互轉換的邏輯：

三種狀態：

• open：打開熔斷，也就是服務調用方執行本地降級策略，不進行遠程調用。
• closed：關閉了熔斷，這時候服務調用方直接發起遠程調用。
• half-open：一箇中間狀態，容許定量的服務請求直接發起遠程調用。

 

服務的健康情況 = 請求失敗數 / 請求總數. 
熔斷器開關由關閉到打開的狀態轉換是經過當前服務健康情況和設定閾值比較決定的。

熔斷器的開關能保證服務調用者在調用異常服務時，快速返回結果，避免大量的同步等待，而且熔斷器能在一段時間後繼續偵測請求執行結果，提供恢復服務調用的可能。

Hystrix提供的熔斷器具備自我反饋，自我恢復的功能，Hystrix會根據調用接口的狀況，讓熔斷器在closed、open、half-open三種狀態之間自動切換：

• closed->open：正常狀況下熔斷器爲closed狀態，若是當前健康情況高於設定閾值，保持closed。若是當前健康情況低於設定閾值，則切換爲open。

• open->half-open：當服務接口對應的熔斷器爲open狀態，全部服務調用方調用該服務方法時所有執行本地降級方法。Hystrix提供了一種測試策略，即設置了一個時間窗口（通常設置成平均故障處理時間，也就是MTTR），從熔斷器變爲open狀態開始的一個時間窗口內，調用該服務接口時都委託服務降級方法進行執行。若是時間超過了時間窗口，則把熔斷狀態從open->half-open

• half-open->closed：當熔斷器爲half-open狀態，容許定量的服務請求。 若所有（或必定比例）的請求調用成功， 熔斷器恢復到closed，不然，熔斷器狀態爲open， 接下來的請求被禁止經過，從新記錄時間窗口開始時間。

命令模式

Hystrix使用命令模式(繼承HystrixCommand類)來包裹具體的服務調用邏輯(run方法)，並在命令模式中添加了服務調用失敗後的降級邏輯(getFallback).
同時咱們在Command的構造方法中能夠定義當前服務線程池和熔斷器的相關參數， 以下代碼所示:

public class Service1HystrixCommand extends HystrixCommand<Response> {
  private Service1 service;
  private Request request;

  public Service1HystrixCommand(Service1 service, Request request){
    supper(
      Setter.withGroupKey(HystrixCommandGroupKey.Factory.asKey("ServiceGroup"))
            .andCommandKey(HystrixCommandKey.Factory.asKey("servcie1query"))
            .andThreadPoolKey(HystrixThreadPoolKey.Factory.asKey("service1ThreadPool"))
            .andThreadPoolPropertiesDefaults(HystrixThreadPoolProperties.Setter()
            .withCoreSize(20))//服務線程池數量
            .andCommandPropertiesDefaults(HystrixCommandProperties.Setter()
            .withCircuitBreakerErrorThresholdPercentage(60)//熔斷器關閉到打開閾值
            .withCircuitBreakerSleepWindowInMilliseconds(3000)//熔斷器打開到關閉的時間窗長度
      ))
      this.service = service;
      this.request = request;
    );
  }

  @Override
  protected Response run(){
    return service1.call(request);
  }

  @Override
  protected Response getFallback(){
    return Response.dummy();
  }
}

 在使用了Command模式構建了服務對象以後, 服務便擁有了熔斷器和線程池的功能

 

Hystrix的內部處理邏輯

1. 構建Hystrix的Command對象，調用執行方法.

2. Hystrix檢查當前服務的熔斷器開關是否開啓，若開啓，則執行降級服務getFallback方法.

3. 若熔斷器開關關閉，則Hystrix檢查當前服務的線程池是否能接收新的請求，若超過線程池已滿，則執行降級服務getFallback方法.

4. 若線程池接受請求，則Hystrix開始執行服務調用具體邏輯run方法.

5. 若服務執行失敗，則執行降級服務getFallback方法，並將執行結果上報Metrics更新服務健康情況.（run()方法拋出非HystrixBadRequestException異常）

6. 若服務執行超時，則執行降級服務getFallback方法，並將執行結果上報Metrics更新服務健康情況.

7. 若服務執行成功，返回正常結果.

8. 若服務降級方法getFallback執行成功，則返回降級結果.

9. 若服務降級方法getFallback執行失敗，則拋出異常.

執行方式

• 同步執行：即一旦開始執行該命令，當前線程就得阻塞着直到該命令返回結果，而後才能繼續執行下面的邏輯
• 異步執行：命令開始執行會返回一個Future<T>的對象，不阻塞後面的邏輯，開發者本身根據須要去獲取結果。
• 響應式執行：命令開始執行會返回一個Observable<T> 對象，開發者能夠給給Obeservable對象註冊上Observer或者Action1對象，響應式地處理命令執行過程當中的不一樣階段。當調用HystrixCommand的observe()方法，或使用Observable的工廠方法（just(),from()）即爲響應式執行，這個功能的實現是基於Netflix的另外一個開源項目RxJava（https://github.com/Netflix/RxJava）來的，更細節的用法能夠參考：https://github.com/Netflix/Hystrix/wiki/How-To-Use#wiki-Reactive-Execution。

 

 整理自：https://segmentfault.com/a/119000000598889五、https://blog.csdn.net/smillest/article/details/80660565