如何理解SpringCloud中服務熔斷和降級Hystrix

這篇文章主要講解了“如何理解SpringCloud中服務熔斷和降級Hystrix”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“如何理解SpringCloud中服務熔斷和降級Hystrix”吧！

一、Hystrix斷路器

1、Hystrix是什么

分布式系統面臨的問題

復雜分布式體系結構中的應用程序有數十個依賴關系，每個依賴關系在某些時候將不可避免地失敗。

服務雪崩
多個微服務之間調用的時候，假設微服務A調用微服務B和微服務C，微服務B和微服務C又調用其它的微服務，這就是所謂的“扇出”。如果扇出的鏈路上某個微服務的調用響應時間過長或者不可用，對微服務A的調用就會占用越來越多的系統資源，進而引起系統崩潰，所謂的“雪崩效應”.
 
對于高流量的應用來說，單一的后端依賴可能會導致所有服務器上的所有資源都在幾秒鐘內飽和。比失敗更糟糕的是，這些應用程序還可能導致服務之間的延遲增加，備份隊列，線程和其他系統資源緊張，導致整個系統發生更多的級聯故障。這些都表示需要對故障和延遲進行隔離和管理，以便單個依賴關系的失敗，不能取消整個應用程序或系統。
 
 
備注：一般情況對于服務依賴的保護主要有3中解決方案：
 
（1）熔斷模式：這種模式主要是參考電路熔斷，如果一條線路電壓過高，保險絲會熔斷，防止火災。放到我們的系統中，如果某個目標服務調用慢或者有大量超時，此時，熔斷該服務的調用，對于后續調用請求，不在繼續調用目標服務，直接返回，快速釋放資源。如果目標服務情況好轉則恢復調用。
 
（2）隔離模式：這種模式就像對系統請求按類型劃分成一個個小島的一樣，當某個小島被火少光了，不會影響到其他的小島。例如可以對不同類型的請求使用線程池來資源隔離，每種類型的請求互不影響，如果一種類型的請求線程資源耗盡，則對后續的該類型請求直接返回，不再調用后續資源。這種模式使用場景非常多，例如將一個服務拆開，對于重要的服務使用單獨服務器來部署，再或者公司最近推廣的多中心。
 
（3）限流模式：上述的熔斷模式和隔離模式都屬于出錯后的容錯處理機制，而限流模式則可以稱為預防模式。限流模式主要是提前對各個類型的請求設置最高的QPS閾值，若高于設置的閾值則對該請求直接返回，不再調用后續資源。這種模式不能解決服務依賴的問題，只能解決系統整體資源分配問題，因為沒有被限流的請求依然有可能造成雪崩效應。

	Hystrix是一個用于處理分布式系統的延遲和容錯的開源庫，在分布式系統里，許多依賴不可避免的會調用失敗，比如超時、異常等，Hystrix能夠保證在一個依賴出問題的情況下，不會導致整體服務失敗，避免級聯故障，以提高分布式系統的彈性。
 
	“斷路器”本身是一種開關裝置，當某個服務單元發生故障之后，通過斷路器的故障監控（類似熔斷保險絲），向調用方返回一個符合預期的、可處理的備選響應（FallBack），而不是長時間的等待或者拋出調用方無法處理的異常，這樣就保證了服務調用方的線程不會被長時間、不必要地占用，從而避免了故障在分布式系統中的蔓延，乃至雪崩。

	服務降級、服務熔斷、服務限流、接近實時的監控

2、服務熔斷

服務熔斷
 熔斷機制是應對雪崩效應的一種微服務鏈路保護機制。
 當扇出鏈路的某個微服務不可用或者響應時間太長時，會進行服務的降級，進而熔斷該節點微服務的調用，快速返回"錯誤"的響應信息。當檢測到該節點微服務調用響應正常后恢復調用鏈路。在SpringCloud框架里熔斷機制通過Hystrix實現。Hystrix會監控微服務間調用的狀況，當失敗的調用到一定閾值，缺省是5秒內20次調用失敗就會啟動熔斷機制。熔斷機制的注解是@HystrixCommand。

=====處理異常業務邏輯=====provider client處理====

2.1>、參考cloud-provider-dept-8001新建cloud-provider-dept-8001-hystrix

2.2>、POM新增

<!--  hystrix 客戶端 -->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

2.3>、YML修改

eureka:
  instance:
    instance-id: cloud-dept8001-hystirx   #eureka服務列表中顯示的名稱--hystix
    prefer-ip-address: true  #訪問路徑可以顯示IP地址

2.4>、修改DeptController

	一旦調用服務方法失敗并排除了錯誤信息后，會自動調用@HystrixCommand標注好的fallbackMethod調用類中的指定方法。

	@HystrixCommand(fallbackMethod = "getHystrixCommand")
    @RequestMapping(value="/dept/get/{id}",method=RequestMethod.GET)
    public Dept get(@PathVariable("id") Long id)
    {
        if(id>200){
            throw new RuntimeException();
        }
        return service.get(id);
    }

	//參數必須一樣
    public Dept getHystrixCommand(@PathVariable("id") Long id){
        return new Dept().setDname("這是一個null部門.");
    }

2.5>、修改主啟動類APP

package com.lee.cloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.circuitbreaker.EnableCircuitBreaker;
import org.springframework.cloud.netflix.eureka.EnableEurekaClient;

@EnableCircuitBreaker//對hystrixR熔斷機制的支持
@EnableEurekaClient //本服務啟動后會自動注冊進eureka服務中
@SpringBootApplication
public class DeptProvider8001_APP_hystrix {

    public static void main(String[] args) {
        SpringApplication.run(DeptProvider8001_APP_hystrix.class,args);
    }
}

測試：

1>、啟動3個Eureka服務
2>、啟動cloud-provider-dept-8001-hystrix
3>、啟動cloud-consumer-dept-80
4>、訪問http://localhost:80/consumer/dept/get/9999
結果：
{"deptno":null,"dname":"這是一個null部門.","db_source":null}

思考：
服務熔斷，容易造成方法膨脹，如何解決呢？

3、服務降級

服務降級處理是在客戶端實現完成的，與服務端沒有關系

整體資源快不夠了，忍痛將某些服務先關掉，待渡過難關，再開啟回來。

===關閉不重要的服務===consumer client處理=====

3.1>、修改cloud-consumer-dept-80項目中個的service接口

根據已有的DeptFeignService接口，新建一個實現了FallbackFactory接口的類DeptFeignServiceFallbackFactory

package com.lee.cloud.feign.service;

import com.lee.cloud.entity.Dept;
import feign.hystrix.FallbackFactory;
import org.springframework.stereotype.Component;

import java.util.List;

@Component
public class DeptFeignServiceFallbackFactory implements FallbackFactory<DeptFeignService> {

    @Override
    public DeptFeignService create(Throwable throwable) {
        return new DeptFeignService() {
            @Override
            public Dept get(long id) {
                return new Dept().setDname("服務已經降級。。").setDb_source("服務降級  沒有找到  database.");
            }

            @Override
            public List<Dept> list() {
                return null;
            }

            @Override
            public boolean add(Dept dept) {
                return false;
            }
        };
    }

}

3.2>、DeptFeignService接口在注解@FeignClient中添加fallbackFactory屬性值

@FeignClient(value = "CLOUD-DEPT",fallbackFactory = DeptFeignServiceFallbackFactory.class)

3.3>、cloud-consumer-dept-80-feign工程修改yml

添加
feign:
	hystrix:
		enabled: true

測試：

1》、啟動3個eureka服務
2》、啟動服務提供者cloud-provider-dept-8001服務，注意不是cloud-provider-dept-8001-hystrix
3》、啟動cloud-consumer-dept-80-feign
4》、正常訪問測試 http://localhost:80/consumer/dept/get/1
5》、故意關閉cloud-provider-dept-8001
6》、客戶端自己調用提示
結果：
{"deptno":null,"dname":"服務已經降級。。","db_source":"服務降級  沒有找到  database."}

思考：
服務熔斷 和  服務降級   有什么區別？

【服務熔斷】
一般是某個服務故障或者異常引起，類似現實世界中的"保險絲"，當某個異常條件被處罰，直接熔斷整個服務，而不是一直等到此服務超時。

【服務降級】
所謂降級，一般是從整體負荷考慮，就是當某個服務熔斷之后，服務器將不再被調用。
此時客戶端可以自己準備一個本地的fallback回調，返回一個缺省值。
這樣做，雖然服務水平下降，但好歹可用，比直接掛掉要強。

4、服務監控HystrixDashboard

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

4.1>、新建module，cloud-consumer-dept-9001-hystirx-dashboard

4.2>、POM文件

<dependencies>
   <!-- 自己定義的api -->
   <dependency>
       <groupId>com.lee</groupId>
       <artifactId>cloud-api</artifactId>
       <version>${project.version}</version>
   </dependency>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-starter-web</artifactId>
   </dependency>
   <!-- 修改后立即生效，熱部署 -->
   <dependency>
     <groupId>org.springframework</groupId>
     <artifactId>springloaded</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.boot</groupId>
     <artifactId>spring-boot-devtools</artifactId>
   </dependency>
   <!-- Ribbon相關 -->
   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-eureka</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-ribbon</artifactId>
   </dependency>
   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-config</artifactId>
   </dependency>
   <!-- feign相關 -->
   <dependency>
     <groupId>org.springframework.cloud</groupId>
     <artifactId>spring-cloud-starter-feign</artifactId>
   </dependency>
   <!-- hystrix和 hystrix-dashboard相關-->
   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-hystrix</artifactId>
   </dependency>
   <dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-hystrix-dashboard</artifactId>
   </dependency> 
  </dependencies>

4.3>、YML文件

server:
  port: 9001

4.4>、主啟動類

package com.lee.cloud;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.hystrix.dashboard.EnableHystrixDashboard;

@EnableHystrixDashboard
@SpringBootApplication
public class DeptConsumer_DashBoard_9001_App {

    public static void main(String[] args) {
        SpringApplication.run(DeptConsumer_DashBoard_9001_App.class,args);
    }
}

4.5>、所有provider微服務提供者都需要添加監控依賴

<!-- actuator監控信息完善 -->
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>

測試：

1、啟動cloud-consumer-dept-9001-hystrix-dashboard
訪問：http://localhost:9001/hystrix
2、啟動3個eureka集群
3、啟動cloud-provider-dept-8001-hystrix
	訪問:http://localhost8001/dept/list
4、http://localhost:8001/hystrix.stream
	delay:2000ms  title: demo1

感謝各位的閱讀，以上就是“如何理解SpringCloud中服務熔斷和降級Hystrix”的內容了，經過本文的學習后，相信大家對如何理解SpringCloud中服務熔斷和降級Hystrix這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！