Spring Cloud第五篇 | 服務熔斷Hystrix

山有山的高度，水有水的深度。人生就是一場修行，註定會經歷千迴百轉，方能遇到一生的摯愛，註定要經歷浮浮沉沉，才能領會生命的涵義。燃一盞心燈，照亮每一個黑暗的角落，微笑，是最美的詩行。 ...

本文是Spring Cloud專欄的第五篇文章，瞭解前四篇文章內容有助於更好的理解本文：

一、微服務高可用技術

大型複雜的分散式系統中，高可用相關的技術架構非常重要。

高可用架構非常重要的一個環節，就是如何將分散式系統中的各個服務打造成高可用的服務，從而足以應對分散式系統環境中的各種各樣的問題，避免整個分散式系統被某個服務的故障給拖垮。

比如：

服務間的調用超時
服務間的調用失敗

要解決這些棘手的分散式系統可用性問題，就涉及到了高可用分散式系統中的很多重要的技術，包括：

資源隔離
限流與過載保護
熔斷
優雅降級
容錯
超時控制
監控運維

二、服務降級、熔斷、限流概念

1、服務雪崩效應

服務雪崩效應產生與服務堆積在同一個線程池中，因為所有的請求都是同一個線程池進行處理，這時候如果在高併發情況下，所有的請求全部訪問同一個介面，這時候可能會導致其他服務沒有線程進行接受請求，這就是服務雪崩效應效應。

2、服務降級

在高併發情況下，防止用戶一直等待，使用服務降級方式(直接返回一個友好的提示給客戶端，調用fallBack方法)

3、服務熔斷

熔斷機制目的為了保護服務，在高併發的情況下，如果請求達到一定極限(可以自己設置闊值)如果流量超出了設置閾值，然後直接拒絕訪問，保護當前服務。使用服務降級方式返回一個友好提示，服務熔斷和服務降級一起使用

4、服務隔離

因為預設情況下，只有一個線程池會維護所有的服務介面，如果大量的請求訪問同一個介面，達到tomcat 線程池預設極限，可能會導致其他服務無法訪問。

解決服務雪崩效應:使用服務隔離機制(線程池方式和信號量)，使用線程池方式實現隔離的原理: 相當於每個介面(服務)都有自己獨立的線程池，因為每個線程池互不影響，這樣的話就可以解決服務雪崩效應。

線程池隔離:

每個服務介面，都有自己獨立的線程池，每個線程池互不影響。

信號量隔離:

使用一個原子計數器（或信號量）來記錄當前有多少個線程在運行，當請求進來時先判斷計數器的數值，若超過設置的最大線程個數則拒絕該請求，若不超過則通行，這時候計數器+1，請求返回成功後計數器-1。

5、服務限流

服務限流就是對介面訪問進行限制，常用服務限流演算法令牌桶、漏桶。計數器也可以進行粗暴限流實現。

三、Hystrix簡單介紹

Hystrix是國外知名的視頻網站Netflix所開源的非常流行的高可用架構框架。Hystrix能夠完美的解決分散式系統架構中打造高可用服務面臨的一系列技術難題。

Hystrix “豪豬”，具有自我保護的能力。hystrix 通過如下機制來解決雪崩效應問題。

在微服務架構中，我們把每個業務都拆成了單個服務模塊，然後當有業務需求時，服務間可互相調用，但是，由於網路原因或者其他一些因素，有可能出現服務不可用的情況，當某個服務出現問題時，其他服務如果繼續調用這個服務，就有可能出現線程阻塞，但如果同時有大量的請求，就會造成線程資源被用完，這樣就可能會導致服務癱瘓，由於服務間會相互調用，很容易造成蝴蝶效應導致整個系統宕掉。因此，就有人提出來斷路器來解決這一問題。

資源隔離：包括線程池隔離和信號量隔離，限制調用分散式服務的資源使用，某一個調用的服務出現問題不會影響其他服務調用。

降級機制：超時降級、資源不足時(線程或信號量)降級，降級後可以配合降級介面返回托底數據。

融斷：當失敗率達到閥值自動觸發降級(如因網路故障/超時造成的失敗率高)，熔斷器觸發的快速失敗會進行快速恢復。

緩存：提供了請求緩存、請求合併實現。

四、Hystrix環境搭建

1、添加依賴

<!-- hystrix斷路器 -->
<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

2、在主類上添加註解@EnableCircuitBreaker

3、在調用遠程的服務的方法上添加@HystrixCommand(fallbackMethod="error")

4、服務消費者Hystrix測試

Hystrix預設超時時間為1000毫秒，如果後端響應超過1000ms，就會觸發熔斷

修改預設超時時間：

@HystrixCommand(fallbackMethod="error",commandProperties={@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "3500")})//fallbackMethod如果發生熔斷，調用error()方法

5、Hystrix的服務降級

有了服務的熔斷,隨之就會有服務的降級,所謂服務降級,就是當某個服務熔斷之後,服務端提供的服務將不再被調用,此時由客戶端自己準備一個本地的 fallback回調,返回一個預設值來代表服務端的返回,這種做法,雖然不能得到正確的返回結果,但至少保證了服務的可用,比直接拋出錯誤或服務不可用要好很多,當然這需要根據具體的業務場景來選擇

6、Hystrix的異常處理

我們在調用服務提供者時,我們自己也有可能會拋異常,預設情況下方法拋了異常會自動進行服務降級,交給服務降級中的方法去處理。

當我們自己發生異常後,只需要在服務降級方法中添加一個Throwable類型的參數就能夠獲取到拋出的異常的類型,如下

public String error(Throwable throwable){
      System.out.println("異常信息："+throwable.getMessage());
      //訪問遠程服務失敗，該如何處理，這些處理邏輯就可以寫在該方法中
      return  "ERROR";
}

此時我們可以在控制台看到異常的類型; 如果遠程服務有一個異常拋出後我們不希望進入到服務降級方法中去處理,而是直接將異常拋給用戶，那麼我們可以在@HystrixCommand註解中忽略異常，如下：

@HystrixCommand(fallbackMethod="error",ignoreExceptions = Exception.class)

7、自定義Hystrix請求的服務異常熔斷處理

我們也可以自定義類繼承自HystriXCommand來實現自定義的Hystrix請求, 在 getFallback方法中調用getEXecutionException方法來獲取服務拋出的異常

com.netflix.hystrix.HystrixCommand.Setter.withGroupkey(HystrixCommandGrouke.Factory.asKey("")

8、請求緩存

請求緩存是在同一請求多次訪問中保證只調用一次這個服務提供者的介面，在這同一次請求第一次的結果會被緩存，保證同一請求中同樣的多次訪問返回結果相同。

請求緩存有兩種方式實現：

第一種方式是通過自定義類繼承HystriXCommand覆蓋getCacheKey方法開啟緩存
第二種方式使用註解的形式，和緩存相關的註解一共有三個，分別是@CacheResult、@CacheKey和@CacheRemove

具體操作參考：https://segmentfault.com/a/1190000011468804

9、請求合併

在微服務架構中，我們將一個項目拆分成很多個獨立的模塊，這些獨立的模塊通過遠程調用來互相配合工作，但是在高併發情況下，通信次數的增加會導致總的通信時間增加，同時線程池的資源也是有限的，高併發環境會導致有大量的線程處於等待狀態，進而導致響應延遲，為瞭解決這些問題，我們需要來瞭解Hystrix的請求合併。

　　Hystrix的請求合併就是把重覆的請求批量的用一個HystrixCommand命令去執行，以減少通信消耗和線程數的占用。Hystrix的請求合併用到了HystrixCollapser這個抽象類，它在HystrixCommand之前放置一個合併處理器，將處於一個很短的時間窗(預設10ms)內對同一依賴服務的多個請求進行整合併以批量方式發起請求的功能。

具體操作參考：https://segmentfault.com/a/1190000011468804

詳細參考案例源碼：https://gitee.com/coding-farmer/spirngcloud-learn