https://github.com/Netflix/Hystrix

在分散式環境中，許多服務依賴項不可避免地會失敗。Hystrix是一個庫，它通過新增延遲容忍和容錯邏輯來幫助您控制這些分散式服務之間的互動。Hystrix通過隔離服務之間的訪問點、停止它們之間的級聯故障以及提供後備選項來實現這一點，所有這些都可以提高系統的整體彈性。

通俗定義: Hystrix是一個用於處理分散式系統的延遲和容錯的開源庫，在分散式系統中，許多依賴不可避免的會呼叫失敗，超時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障(服務雪崩現象)，提高分散式系統的彈性。

1.服務雪崩

1.服務雪崩在微服務之間進行服務呼叫是由於某一個服務故障，導致級聯服務故障的現象，稱為雪崩效應。雪崩效應描述的是提供方不可用，導致消費方不可用並將不可用逐漸放大的過程。

2.圖解雪崩效應如存在如下呼叫鏈路:

而此時，Service A的流量波動很大，流量經常會突然性增加！那麼在這種情況下，就算Service A能扛得住請求，Service B和Service C未必能扛得住這突發的請求。此時，如果Service C因為抗不住請求，變得不可用。那麼Service B的請求也會阻塞，慢慢耗盡Service B的執行緒資源，Service B就會變得不可用。緊接著，Service A也會不可用，這一過程如下圖所示

2.服務熔斷

1.服務熔斷“熔斷器”本身是一種開關裝置，當某個服務單元發生故障之後，通過斷路器的故障監控，某個異常條件被觸發，直接熔斷整個服務。向呼叫方法返回一個符合預期的、可處理的備選響應(FallBack),而不是長時間的等待或者丟擲呼叫方法無法處理的異常，就保證了服務呼叫方的執行緒不會被長時間佔用，避免故障在分散式系統中蔓延，乃至雪崩。如果目標服務情況好轉則恢復呼叫。服務熔斷是解決服務雪崩的重要手段。

2.服務熔斷圖示

3.服務降級

1.服務降級說明

• 服務壓力劇增的時候根據當前的業務情況及流量對一些服務和頁面有策略的降級，以此環節伺服器的壓力，以保證核心任務的進行。同時保證部分甚至大部分任務客戶能得到正確的相應。也就是當前的請求處理不了了或者出錯了，給一個預設的返回。
• 通俗: 關閉系統中邊緣服務 保證系統核心服務的正常執行 稱之為服務降級

淘寶 刪除地址 確認收貨 刪除訂單 取消支付 節省cpu 記憶體

4.降級和熔斷總結

1.共同點

• 目的很一致，都是從可用性可靠性著想，為防止系統的整體緩慢甚至崩潰，採用的技術手段；
• 最終表現類似，對於兩者來說，最終讓使用者體驗到的是某些功能暫時不可達或不可用；
• 粒度一般都是服務級別，當然，業界也有不少更細粒度的做法，比如做到資料持久層（允許查詢，不允許增刪改）；
• 自治性要求很高，熔斷模式一般都是服務基於策略的自動觸發，降級雖說可人工干預，但在微服務架構下，完全靠人顯然不可能，開關預置、配置中心都是必要手段；

2.異同點

• 觸發原因不太一樣，服務熔斷一般是某個服務（下游服務）故障引起，而服務降級一般是從整體負荷考慮；
• 管理目標的層次不太一樣，熔斷其實是一個框架級的處理，每個微服務都需要（無層級之分），而降級一般需要對業務有層級之分（比如降級一般是從最外圍服務開始）

3.總結熔斷必會觸發降級,所以熔斷也是降級一種,區別在於熔斷是對呼叫鏈路的保護,而降級是對系統過載的一種保護處理

5.服務熔斷的實現

服務熔斷的實現思路

• 引入hystrix依賴,並開啟熔斷器(斷路器)
• 模擬降級方法
• 進行呼叫測試

1.專案中引入hystrix依賴

在商品服務下面
<!--引入hystrix-->
<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

2.開啟斷路器

@SpringBootApplication
@EnableCircuitBreaker //用來開啟斷路器
public class Products9998Application {
 public static void main(String[] args) {
  SpringApplication.run(Products9998Application.class,args);
 }
}

3.使用HystrixCommand註解實現斷路

//服務熔斷
@GetMapping("/product/break")
@HystrixCommand(fallbackMethod = "testBreakFall" )
public String testBreak(int id){
 log.info("接收的商品id為: "+ id);
 if(id<=0){
 throw new RuntimeException("資料不合法!!!");
 }
 return "當前接收商品id: "+id;
}

// 觸發熔斷的方法
public String testBreakFall(int id){
 return "當前資料不合法: "+id;
}

4.訪問測試

• 正常引數訪問
• 錯誤引數訪問

一直使用錯誤引數訪問，那麼再使用正常引數訪問也會顯示不合法，因為觸發了斷路器，但過一點時間又會自動的關閉，訪問又合法了

5.總結從上面演示過程中會發現如果觸發一定條件斷路器會自動開啟,過了一點時間正常之後又會關閉。那麼斷路器開啟條件是什麼呢？

6.斷路器開啟條件官網: https://cloud.spring.io/spring-cloud-netflix/2.2.x/reference/html/

A service failure in the lower level of services can cause cascading failure all the way up to the user. When calls to a particular service exceed circuitBreaker.requestVolumeThreshold (default: 20 requests) and the failure percentage is greater than circuitBreaker.errorThresholdPercentage (default: >50%) in a rolling window defined by metrics.rollingStats.timeInMilliseconds (default: 10 seconds),the circuit opens and the call is not made. In cases of error and an open circuit,a fallback can be provided by the developer.--摘自官方

原文翻譯之後,總結開啟關閉的條件:

1 當滿足一定的閥值的時候（預設10秒內超過20個請求次數）

2、當失敗率達到一定的時候（預設10秒內超過50%的請求失敗）

3、到達以上閥值，斷路器將會開啟

4、當開啟的時候，所有請求都不會進行轉發5、一段時間之後（預設是5秒），這個時候斷路器是半開狀態，會讓其中一個請求進行轉發。

如果成功，斷路器會關閉，若失敗，繼續開啟。重複4和5。

7.預設的服務FallBack處理方法如果為每一個服務方法開發一個降級,對於我們來說,可能會出現大量的程式碼的冗餘,不利於維護,這個時候就需要加入預設服務降級處理方法

@GetMapping("/product/hystrix")
@HystrixCommand(defaultFallback = "testHystrixFallBack") //通過HystrixCommand降級處理 指定出錯的方法
public String testHystrix(String name) {
 log.info("接收名稱為: " + name);
 int n = 1/0;
 return "服務[" + port + "]響應成功,當前接收名稱為:" + name;
}
//服務降級處理
public String testHystrixFallBack(String name) {
 return port + "當前服務已經被降級處理!!!,接收名稱為: "+name;
}

6.服務降級的實現

還是再之前專案的基礎之上

1.客戶端openfeign + hystrix實現服務降級實現

• 引入hystrix依賴
• 配置檔案開啟feign支援hystrix
• 在feign客戶端呼叫加入fallback指定降級處理
• 開發降級處理方法

2.開啟openfeign支援服務降級

feign.hystrix.enabled=true #開啟openfeign支援降級

3.在openfeign客戶端中加如Hystrix

// 建立一個ProductClientFallBack類實現這個介面，並實現這個介面的所有方法，為了對每個方法做不同的響應錯略
// 指定當前的介面是openfeign元件，value是呼叫的服務名
@FeignClient(value = "products",fallback = ProductClientFallBack.class)
public interface ProductClient {

 @GetMapping("/product/findOne")
 Map<String,Object> findOne(@RequestParam("productId") String productId);

}

4.開發fallback處理類

package com.md.fallback;

@Component
public class ProductClientFallBack implements ProductClient {

 @Override
 public Map<String,Object> findOne(String productId) {
  HashMap<String,Object> map = new HashMap<>();
  map.put("status","false");
  map.put("msg","當前查詢不可以使用，服務已經被降級");
  return map;
 }
}

正常訪問

然後直接將產品服務關閉，再進行訪問

注意:如果服務端降級和客戶端降級同時開啟,要求服務端降級方法的返回值必須與客戶端方法降級的返回值一致!!!

7.Hystrix Dashboard

0.說明Hystrix Dashboard的一個主要優點是它收集了關於每個HystrixCommand的一組度量。Hystrix儀表板以高效的方式顯示每個斷路器的執行狀況。

只是一個有UI頁面的元件，建立一個新的專案，還是根據之前的springcloud的環境搭建

1.專案中引入依賴

<!--引入hystrix dashboard 依賴-->
<dependency>
 <groupId>org.springframework.cloud</groupId>
 <artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId>
</dependency>

2.入口類中開啟hystrix dashboard

@SpringBootApplication
@EnableHystrixDashboard //開啟監控面板
public class Hystrixdashboard9990Application {
	public static void main(String[] args) {
		SpringApplication.run(Hystrixdashboard9990Application.class,args);
 }
}

在配置檔案中指定埠號9990

3.啟動hystrix dashboard應用http://localhost:9990(dashboard埠)/hystrix

4.監控的專案中入口類中加入監控路徑配置[新版本坑],並啟動監控專案

@Bean
public ServletRegistrationBean getServlet() {
 HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();
 ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);
 registrationBean.setLoadOnStartup(1);
 registrationBean.addUrlMappings("/hystrix.stream");
 registrationBean.setName("HystrixMetricsStreamServlet");
 return registrationBean;
}

5.通過監控介面監控

後面的hystrix.stream是固定的

6.點選監控,一致loading,開啟控制檯發現報錯[特別坑]

# 解決方案
- 新版本中springcloud將jquery版本升級為3.4.1，定位到monitor.ftlh檔案中，js的寫法如下：
	$(window).load(function() 
- jquery 3.4.1已經廢棄上面寫法

- 修改方案 修改monitor.ftlh為如下呼叫方式：
	$(window).on("load",function()
	
- 編譯jar原始檔，重新打包引入後，介面正常響應。

8.Hystrix停止維護

官方地址:https://github.com/Netflix/Hystrix

• 翻譯:Hystrix（版本1.5.18）足夠穩定，可以滿足Netflix對我們現有應用的需求。同時，我們的重點已經轉移到對應用程式的實時效能作出反應的更具適應性的實現，而不是預先配置的設定（例如，通過自適應併發限制）。對於像Hystrix這樣的東西有意義的情況，我們打算繼續在現有的應用程式中使用Hystrix，並在新的內部專案中利用諸如resilience4j這樣的開放和活躍的專案。我們開始建議其他人也這樣做。
• Dashboard也被廢棄

到此這篇關於SpringCloud-Hystrix元件使用方法的文章就介紹到這了,更多相關SpringCloud-Hystrix元件內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！