當前位置：首頁 >

SpringCloud-06-Hystrix断路器

發布時間：2024/3/7 47 豆豆

生活随笔收集整理的這篇文章主要介紹了 SpringCloud-06-Hystrix断路器小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

Hystrix斷路器

1. 概述

1. 分布式系統面臨的問題

復雜分布式體系結構中的應用程序有數十個依賴關系，每個依賴關系在某些時候將不可避免地失敗。這就造成有可能會發生服務雪崩。那么什么是服務雪崩呢？

多個微服務之間調用的時候，假設微服務A調用微服務B和微服務C，微服務B和微服務C又調用其他的微服務，這就是所謂的“扇出”（向一把打開的折扇）。如果扇出的鏈路上某個微服務的調用響應時間過長或者不可用，對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，這就是所謂的”雪崩效應“。也就是系統的 高可用 受到了破壞。

對于高流量的應用來說，單一的后端依賴可能會導致所有服務器上的所有資源在幾秒內飽和。比失敗更糟的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導致整個系統發送更過的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便 單個依賴關系的失敗，不能取消整個應用程序或系統。

所以，通常當發現一個模塊下的某個實例失敗后，這時候這個模塊依然還會接受流量，然后這個有問題的模塊還調用了其他的模塊，這樣就會發生級聯故障，或者叫做雪崩。而面對這種糟糕的問題，我們就應該采取 服務降級、服務熔斷 等方式來解決。

2. Hystrix是什么

Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫，在分布式系統里，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整個服務失敗，避免級聯故障，以提高分布式系統的彈性。

“斷路器”本身是一種開關裝置，當某個服務單元發生故障之后，通過斷路器的故障監控（類似于物理的熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要的占用，從而避免了故障在分布式系統中的蔓延，乃至雪崩。

3. Hystrix能做什么？

主要有服務降級、服務熔斷、接近實時的監控、限流、隔離等等，其官方文檔參考。當然Hystrix現在已經停更了，雖然有一些替代品，但是學習Hystrix及其里面的思想還是非常重要的！

2. Hystrix重要概念

1. 服務降級——Fall Back

假設微服務A要調用的服務B不可用了，需要服務B提供一個兜底的解決方法，而不是讓服務A在那里傻等，耗死。不讓客戶端等待并立刻返回一個友好圖示，比如像客戶端提示服務器忙，請稍后再試等。哪些情況會觸發服務降級呢？

比如程序運行異常、超時、服務熔斷觸發服務降級、線程池/信號量打滿也會導致服務降級。

2. 服務熔斷——Break

服務熔斷就相當于物理上的熔斷保險絲。類比保險絲達到最大服務訪問后，直接拒絕訪問，拉閘斷點，然后調用服務降級的方法并返回友好提示。

3. 服務限流——Flow Limit

秒殺高并發等操作，嚴禁一窩蜂的過來擁擠，大家排隊，一秒鐘N個，有序進行。

3. Hystrix案例實操

1. 構建

新建一個Module：cloud-provider-hystrix-payment8001作為服務提供方的微服務，和之前的服務消費方同樣選擇8001端口，但是在POM文件中需要引入Hystrix的依賴：

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-hystrix</artifactId> </dependency>

然后編寫其配置文件，端口號為8001，服務名為cloud-provider-hystrix-payment，以使其入駐服務注冊中心。然后編寫其主啟動類，在SpringCloud-01Eureka服務注冊與發現都有詳細介紹過，之后編寫其業務類，service編寫入下：

package cn.sher6j.springcloud.service;import org.springframework.stereotype.Service;import java.util.concurrent.TimeUnit;/*** 應該要先寫接口，再寫實現類，這里為了節約時間，直接用實現類了* @author sher6j* @create 2020-05-21-17:29*/ @Service public class PaymentService {/*** 正常訪問* @param id* @return*/public String paymentInfo_OK(Long id) {return "線程池： " + Thread.currentThread().getName() + " paymentInfo_OK, id: " + id;}/*** 模擬復雜業務需要3秒鐘* @param id* @return*/public String paymentInfo_TimeOut(Long id) {int time = 3;//暫停幾秒鐘線程，程序本身沒有錯誤，就是模擬超時try {TimeUnit.SECONDS.sleep(time);} catch (InterruptedException e) {e.printStackTrace();}return "線程池： " + Thread.currentThread().getName() + " paymentInfo_TimeOut, id: " + id;} }

Controller編寫入下：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentService; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.beans.factory.annotation.Value; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-17:34*/ @RestController @Slf4j public class PaymentController {@Autowiredprivate PaymentService paymentService;@Value("${server.port}")private String serverPort;@GetMapping("/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id) {String result = paymentService.paymentInfo_OK(id);log.info("========result:" + result);return result;}@GetMapping("/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentService.paymentInfo_TimeOut(id);log.info("========result:" + result);return result;} }

也就是說cloud-provider-hystrix-payment服務提供了兩個方法，paymentInfo_OK 方法可以很快訪問，paymentInfo_TimeOut 方法我們模擬了一個復雜的業物邏輯，通過線程休眠的方式使其模擬一個需要執行3秒的服務方法。

在啟動了注冊中心和8001服務后，我們對服務的 paymentInfo_OK（下面用OK代替）和 paymentInfo_TimeOut （下面用TO代替）分別進行訪問，我們發現，http://localhost:8001/payment/hystrix/ok/1 可以很快的訪問，而http://localhost:8001/payment/hystrix/timeout/1 每次訪問大約需要3秒的時間。

2. 高并發測試

1. 服務提供方自測壓力測試：

需要3秒的復雜業務邏輯 TO 訪問時，需要時間很少的 OK 是完全可以正常訪問的，但是在高并發的情況下，也就是說 TO 有很多訪問量的時候，OK 還能夠這么正常的訪問嗎？下面我們用 Jmeter 進行高并發壓力測試，用20000個請求都去訪問 TO 服務，在 Jmeter 中新建一個線程組：測試Hystrix用來模擬高并發訪問 TO 服務，線程組配置參數如下：

然后我們用該線程組發送HTTP請求給 TO 服務，創建如下的HTTP請求進行壓力測試：

我們觀察8001服務的后端控制臺，可以看到對 TO 服務進行了大量的訪問：

而此時我們再去訪問 OK 服務時什么樣的呢？？

可以看到，OK 服務無妨像之前一樣很快能夠得到訪問，這里我們模擬的是20000的訪問量（沒敢模擬數字太大的訪問量，怕把系統直接搞死哈哈哈哈），實際中可能會有遠大于20000的訪問量，當訪問量更多的時候，甚至可能卡死服務，原因就是Tomcat的默認的工作線程數被打滿了，沒有多余的線程來分解壓力和處理。

而剛才做的壓力測試還只是服務提供方8001自己實現的測試，如果此時是外部的服務消費方80來訪問該服務，那么服務消費方只能夠進行干等，消費方顯然會對這樣的等待時間不滿意，服務提供方很有可能直接被拖死。我們發現8001自測都會出現問題，那如果我們再用服務消費方測試呢？

2.服務消費方進行壓力測試：

新建一個Module：cloud-consumer-feign-hystrix-order80作為服務消費方，服務消費方利用feign訪問提供方的服務，編寫對應的service接口如下：

然后編寫其Controller：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentHystrixService; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-20:02*/ @RestController @Slf4j public class OrderHystrixController {@Autowiredprivate PaymentHystrixService paymentHystrixService;@GetMapping("/consumer/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_OK(id);return result;}@GetMapping("/consumer/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;} }

將80服務啟動，用http://localhost/consumer/payment/hystrix/ok/1 對服務提供方的 OK 服務進行訪問，再進行壓力測試，和之前一樣，無法迅速訪問該服務，如果壓力測試中的線程數更多的時候，很可能會造成超時錯誤，出現以下錯誤提示：

故障原因：8001同一層次的其他接口服務被困死，因為Tomcat線程池里面的工作線程已經被擠占完畢，80此時再調用8001，必然導致客戶端訪問響應緩慢。正是因為出現了這種現象，所以我們才需要服務降級、容錯、服務限流等技術。

3. 服務降級Fall Back

1. 服務端服務提供方的服務降級

降級的配置用 @HystrixCommand 注解，在服務提供方自身找問題，設置自身調用超時時間的峰值，在峰值內可以正常運行，超過了峰值需要有兜底的方法處理，用作服務降級。

首先在服務提供方的業務類上啟用 @HystrixCommand 實現報異常后如何處理，也就是一旦調用服務方法失敗并拋出了錯誤信息后，會自動調用 @HystrixCommand 標注好的fallbackMethod服務降級方法。在服務提供方的service中我們修改 TO 服務：

/*** 模擬復雜業務需要3秒鐘* HystrixCommand配置2秒以內走正常的邏輯，超過2秒走服務降級邏輯* @param id* @return*///設置服務降級方法為paymentInfo_TimeOutHandler，超時峰值為2秒@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "2000")})public String paymentInfo_TimeOut(Long id) {int time = 3;//暫停幾秒鐘線程，程序本身沒有錯誤，就是模擬超時try {TimeUnit.SECONDS.sleep(time);} catch (InterruptedException e) {e.printStackTrace();}return "線程池： " + Thread.currentThread().getName() + " paymentInfo_TimeOut, id: " + id;}/*** 兜底方法* @param id* @return*/public String paymentInfo_TimeOutHandler(Long id) {return "系統忙，請稍后再試";}

然后在主啟動類上添加 @EnableCircuitBreaker 注解對熔斷器進行激活，TO服務的訪問時間3秒，而我們用Hystrix配置的時間峰值為2秒，也就是當服務超時或服務出錯時，會訪問我們設置的fallbackMethod服務降級方法，再次訪問TO服務，我們發現其執行的方法確實為服務降級方法：

2. 客戶端服務消費方的服務降級

既然服務的提供方可以進行降級保護，那么服務的消費方，也可以更好的保護自己，也可以對自己進行降級保護，也就是說Hystrix服務降級既可以放在服務端（服務提供方），也可以放在客戶端（服務消費方），但是！！！通常是用客戶端做服務降級，下面在服務消費方即客戶端配置自己的服務降級保護，修改80消費方的配置文件，添加如下配置已使其支持Hystrix：

feign:hystrix:enabled: true

在80消費方的主啟動類上添加 @EnableHystrix 激活Hystrix服務。然后在80的Controller中同樣加入**@HystrixCommand**注解已實現服務降級：

@GetMapping("/consumer/payment/hystrix/timeout/{id}")@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")})public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;}/*** 兜底方法* @param id* @return*/public String paymentInfo_TimeOutHandler(Long id) {return "系統忙，請稍后再試";}

也就是說如果消費方訪問服務提供方的時間超過了1.5秒，那么就會訪問自己的降級服務方法。

3. 統一全局服務降級方法

而當前的這種處理方式是有問題的，也就是每個業務方法都對應了一個服務降級犯法，這會導致代碼膨脹，所以我們應該定義一個統一的服務降級方法，統一的方法和自定義的方法分開。而且我們將服務降級方法和業務邏輯混合在了一起，這會導致代碼混亂，業務邏輯不清晰。

對于第一個問題，我們可以用feign接口中的 @DefaultProperties(defaultFallback = "") 注解來配置全局的服務降級方法，也就是說自己配置過**@HystrixCommand(fallbackMethod = “”）** fallbackMethod方法的采用自己配置的服務降級方法，而沒有配置過的就采用**@DefaultProperties(defaultFallback = "")** 配置的全局的服務降級方法。這樣的話通用的服務降級方法和獨享的服務降級方法分開，避免了代碼膨脹，合理減少了代碼量，修改服務消費方80的Controller入下：

package cn.sher6j.springcloud.controller;import cn.sher6j.springcloud.service.PaymentHystrixService; import com.netflix.hystrix.contrib.javanica.annotation.DefaultProperties; import com.netflix.hystrix.contrib.javanica.annotation.HystrixCommand; import com.netflix.hystrix.contrib.javanica.annotation.HystrixProperty; import lombok.extern.slf4j.Slf4j; import org.springframework.beans.factory.annotation.Autowired; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable; import org.springframework.web.bind.annotation.RestController;/*** @author sher6j* @create 2020-05-21-20:02*/ @RestController @Slf4j @DefaultProperties(defaultFallback = "payment_Global_FallbackMethod") //全局服務降級 public class OrderHystrixController {@Autowiredprivate PaymentHystrixService paymentHystrixService;@GetMapping("/consumer/payment/hystrix/ok/{id}")@HystrixCommandpublic String paymentInfo_OK(@PathVariable("id") Long id) {int i = 1/0; //手動模擬錯誤String result = paymentHystrixService.paymentInfo_OK(id);return result;}@GetMapping("/consumer/payment/hystrix/timeout/{id}")//定制服務降級@HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {@HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "1500")})public String paymentInfo_TimeOut(@PathVariable("id") Long id) {String result = paymentHystrixService.paymentInfo_TimeOut(id);return result;}/*** 定制服務降級方法* @param id* @return*/public String paymentInfo_TimeOutHandler(Long id) {return "定制異常處理信息";}/*** 全局服務降級方法* @return*/public String payment_Global_FallbackMethod() {return "全局異常處理信息";} }

paymentInfo_TimeOut由于定制了降級服務，所以訪問服務提供方會出現超時（服務提供方提供的服務執行時間超過1.5秒），而paymentInfo_OK我們用 int i = 1/0; 這行代碼模擬了錯誤，分別訪問http://localhost/consumer/payment/hystrix/timeout/1 和http://localhost/consumer/payment/hystrix/ok/1 ，我們得到如下結果：

可以看到由于paymentInfo_OK沒有進行定制的服務降級方法，所以其訪問的是全局服務降級方法，而paymentInfo_TimeOut訪問的是定制服務降級方法，這里需要注意的是，無論是否配置了定制服務降級方法，都要在其服務上加入注解 @HystrixCommand，否則服務降級和該服務沒關系，比如paymentInfo_OK如果沒有加入該注解，就直接會報除數為0錯誤。

而對于第二個問題，我們可以為Feign客戶端定義的接口添加一個服務降級處理的實現類即可實現解耦，我們的80客戶端已經有了PaymentHystrixService接口，我們新建一個類PaymentFallbackService實現該接口，并重寫接口中的方法，為接口里的方法進行異常處理，并且我們在PaymentHystrixService聲明其服務降級方法所在的類：

package cn.sher6j.springcloud.service;import org.springframework.cloud.openfeign.FeignClient; import org.springframework.stereotype.Component; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.PathVariable;/*** @author sher6j* @create 2020-05-21-20:00*/ @Component //當出現錯誤是到PaymentFallbackService類中找服務降級方法 @FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackService.class) public interface PaymentHystrixService {@GetMapping("/payment/hystrix/ok/{id}")public String paymentInfo_OK(@PathVariable("id") Long id);@GetMapping("/payment/hystrix/timeout/{id}")public String paymentInfo_TimeOut(@PathVariable("id") Long id); } package cn.sher6j.springcloud.service;import org.springframework.stereotype.Component;/*** @author sher6j* @create 2020-05-21-21:27*/ @Component public class PaymentFallbackService implements PaymentHystrixService {@Overridepublic String paymentInfo_OK(Long id) {return "paymentInfo_OK出現異常";}@Overridepublic String paymentInfo_TimeOut(Long id) {return "paymentInfo_TimeOut出現異常";} }

然后我們將Controller中耦合的代碼都取消：

然后我們關閉8001服務提供方服務，模擬服務器宕機，如圖，在服務訪問出現錯誤時，訪問了我們配置的PaymentFallbackService類中的服務降級方法，這樣就實現了代碼的解耦，使業務邏輯不再混亂。

4. 服務熔斷Break

1. 熔斷機制概述

熔斷機制是應對雪崩效應的一種微服務鏈路保護機制，當扇出鏈路的某個微服務出錯不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，也就是說服務熔斷會導致服務降級，快速返回錯誤的響應信息。當檢測到該節點微服務調用響應正常后，恢復調用鏈路。也就是說，服務熔斷在服務好了之后會重新允許訪問服務。在SpringCloud框架中，熔斷機制通過Hystrix實現。Hystrix會監控微服務間的調用狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗，就會啟動熔斷機制。熔斷機制的注解是 @HystrixCommand。關于熔斷機制，具體可以參考論文CircuitBreaker。

2. 實操

在8001服務提供方的Service中添加如下代碼：

//======服務熔斷/*** fallbackMethod 服務降級方法* circuitBreaker.enabled 是否開啟斷路器* circuitBreaker.requestVolumeThreshold 請求次數* circuitBreaker.sleepWindowInMilliseconds 時間窗口期* circuitBreaker.errorThresholdPercentage 失敗率達到多少后跳閘* 以下配置意思是在10秒時間內請求10次，如果有6此是失敗的，就觸發熔斷器* 注解@HystrixProperty中的屬性在com.netflix.hystrix.HystrixCommandProperties類中查看* @param id* @return*/@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_fallback", commandProperties = {@HystrixProperty(name = "circuitBreaker.enabled", value = "true"),@HystrixProperty(name = "circuitBreaker.requestVolumeThreshold", value = "10"),@HystrixProperty(name = "circuitBreaker.sleepWindowInMilliseconds", value = "10000"),@HystrixProperty(name = "circuitBreaker.errorThresholdPercentage", value = "60")})public String paymentCircuitBreaker(@PathVariable("id") Long id) {if (id < 0) {throw new RuntimeException("id 不能為負數");}String serialNumber = IdUtil.simpleUUID();return Thread.currentThread().getName() + " 調用成功，流水號： " + serialNumber;}/*** 服務熔斷觸發的服務降級方法* @param id* @return*/public String paymentCircuitBreaker_fallback(@PathVariable("id") Long id) {return "id 不能為負數，請稍后再試。id:" + id;}

在 @HystrixCommand 注解中配置熔斷機制的參數，配置的參數含義如下：

屬性名含義默認值

circuitBreaker.enabled	是否開啟斷路器	true
circuitBreaker.requestVolumeThreshold	請求次數	20
circuitBreaker.sleepWindowInMilliseconds	時間窗口期	5000
circuitBreaker.errorThresholdPercentage	失敗率達到多少后跳閘	50

這些屬性名的具體含義一級其默認值可以在 com.netflix.hystrix.HystrixCommandProperties 類中進行查看。而我們在service中配置的意思就是在10秒時間內請求10次，如果有6次是失敗的，就觸發熔斷器。

在Controller中添加該服務：

@GetMapping("payment/circuit/{id}")public String paymentCircuitBreaker(@PathVariable("id") Long id) {String result = paymentService.paymentCircuitBreaker(id);log.info("=========result:" + result);return result;}

3. 測試

根據我們的業物邏輯，也就是當我們的id為整數時，服務可以正常訪問，而當id為負數時，訪問服務出錯。我們先訪問 http://localhost:8001/payment/circuit/1 代表正確的服務請求，可以發現一切正常！！！：

然后我們進行大量的錯誤訪問，強行觸發服務熔斷，然后在進行正確的訪問。

我們發現在進行超出我們閾值的錯誤訪問后，觸發了服務熔斷，即使再進行正確的訪問也無法進行，但是一定時間后，正確的服務訪問又可以順利進行，這就是服務熔斷的整體過程：在觸發了服務熔斷后，先進行服務的降級，再逐漸恢復調用鏈路。

4. 總結

結合官網中對熔斷機制的描述，其熔斷過程可以如下描述：

熔斷器打開和關閉的精確方式如下：

**1.**假設電路上的訪問達到某個閾值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()）…
**2.**并假設誤差百分比超過閾值誤差百分比（HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()）…
**3.**然后，斷路器從CLOSED為OPEN，觸發熔斷機制。
**4.**當它斷開時，它會使針對該斷路器的所有請求短路。
**5.經過一段時間（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()）后，下一個單個請求被允許通過（這是HALF-OPEN狀態）。如果請求失敗，斷路器將OPEN在睡眠窗口期間返回到該狀態。如果請求成功，則斷路器切換到，CLOSED，并且1.**中的邏輯再次接管。

也就是在熔斷機制中，熔斷器分為三個狀態：

熔斷器打開OPEN請求不再進行調用當前服務，內部設置時鐘一般為MTTR（平均故障處理時間），當打開時長達到所設時鐘則進入半熔斷狀態（HALF-OPEN）。

熔斷器關閉CLOSED	熔斷關閉不會對服務進行熔斷。
熔斷器半開HALF-OPEN	部分請求根據規則調用當前服務，如果請求成功且符合規則則認為當前服務恢復正常，關閉熔斷。

下面是官網上的熔斷器流程圖：

那么熔斷器在什么情況下開始起作用呢？

涉及到熔斷器的三個重要參數：
快照時間窗口期circuitBreaker.sleepWindowInMilliseconds：熔斷器是否打開需要統計一些請求和錯誤數據，而統計的時間范圍就是快找時間窗，默認為最近的10秒；
請求總數閾值circuitBreaker.requestVolumeThreshold：在快照時間窗內，必須滿足請求總數閾值才有資格觸發熔斷，默認為20次，這意味著在快照時間窗規定的時間內，如果該Hystrix命令的調用次數不足20次，即使所有請求都超時或其他原因失敗，熔斷器都不會打開；
錯誤百分比閾值circuitBreaker.errorThresholdPercentage：當請求總數在快照時間窗內超過了閾值，且在這些調用中，超過錯誤百分比閾值比例的錯誤調用，熔斷器就會打開。
熔斷器打開后再有請求調用的時候，將不會調用主邏輯，而是直接調用服務降級的方法，實現了自動發現錯誤并將降級邏輯切換為主邏輯，減少響應延遲的效果。
在熔斷器打開后，原來的主邏輯如何恢復呢？

當熔斷器打開后，對主邏輯進行熔斷之后，Hystrix會啟動一個 休眠時間窗 ，在這個時間窗內，降級邏輯是臨時的主邏輯，當休眠時間窗到期，熔斷器會進入半開狀態，釋放一次請求到原來的主邏輯上，如果此次請求能夠正常訪問，則熔斷器會進入閉合狀態，從而恢復主邏輯，如果注冊請求依然有問題，則熔斷器繼續保持打開狀態，并且休眠時間窗重新計時。

5. Hystrix工作流程

整體的Hystrix工作流程圖入下：

4. 服務監控Hystrix Dashboard

除了隔離依賴服務的調用以外，Hystrix還提供了準實時的調用監控——Hystrix Dashboard，Hystrix會持續的記錄所有通過Hystrix發起的請求的執行信息，并以統計報表和圖形的形式展示給用戶，包括每秒執行多少請求，多少成功，多少失敗等。SpringCloud也提供了Hystrix Dashboard的整合，對監控內容轉化成可視化界面。

新建Module：cloud-consumer-hystrix-dashboard9001作為Hystrix Dashboard服務
添加Hystrix Dashboard的依賴：
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-netflix-hystrix-dashboard</artifactId> </dependency>
寫配置文件application.yml，加個端口即可：
server:port: 9001
編寫主啟動類，在主啟動類上添加@EnableHystrixDashboard注解開啟Hystrix Dashboard功能：
package cn.sher6j.springcloud;import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;/*** @author sher6j* @create 2020-05-21-23:47*/ @SpringBootApplication @EnableHystrixDashboard public class HystrixDashboardMain9001 {public static void main(String[] args) {SpringApplication.run(HystrixDashboardMain9001.class);} }
所有的服務提供方微服務（如我們的8001/8002）都需要監控依賴配置：
 <dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-actuator</artifactId> </dependency>

訪問 http://localhost:9001/hystrix 我們就可以看見Hystrix Dashboard的圖形化界面

為了讓服務提供方的服務能被Hystrix Dashboard監控到，需要在提供方服務的主啟動類中添加如下配置：

/***此配置是為了服務監控而配置，與服務容錯本身無關，springcloud升級后的坑*ServletRegistrationBean因為springboot的默認路徑不是"/hystrix.stream"，*只要在自己的項目里配置上下面的servlet就可以了*/@Beanpublic ServletRegistrationBean getServlet() {HystrixMetricsStreamServlet streamServlet = new HystrixMetricsStreamServlet();ServletRegistrationBean registrationBean = new ServletRegistrationBean(streamServlet);registrationBean.setLoadOnStartup(1);registrationBean.addUrlMappings("/hystrix.stream");registrationBean.setName("HystrixMetricsStreamServlet");return registrationBean;}

在Hystrix Dashboard的圖形化界面中輸入要監控的服務提供者：

下面就是Dashboard對服務的監控狀態：

總結

以上是生活随笔為你收集整理的SpringCloud-06-Hystrix断路器的全部內容，希望文章能夠幫你解決所遇到的問題。

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

上一篇： Jess 7.2p2——Java平台规则
下一篇： ABAP JSON 字段名映射 name