如何理解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这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！