Hystrix熔断器环境搭建及详解

发布时间:2024年01月11日

一、Hystrix介绍

1. Hystrix含义

Hystrix,英文意思是豪猪,全身是刺,刺是一种保护机制。Hystrix也是Netflix公司的一款组件。

2. Hystrix作用

实现服务熔断降级处理,保护微服务,防止雪崩效应发生,以增强系统的稳定性和弹性。
以下功能会在下面后续举例讲解:

  • 隔离依赖:Hystrix 可以通过将每个依赖服务放在单独的线程池中来隔离依赖操作,防止某个依赖的故障或延迟影响到整个系统。

  • 服务降级:Hystrix 可以根据配置的降级策略,在被依赖服务不可用被依赖服务响应时间过长时,快速返回一个备选的响应结果,从而避免用户长时间等待或系统崩溃的情况。

  • 快速失败:当调用依赖服务出现错误时,Hystrix 可以快速失败并立即返回错误,而不是等待超时。

  • 断路器模式【熔断】:Hystrix 实现了断路器模式,可以监控依赖服务的状态,当错误率超过阈值时,会打开断路器,后续请求将被快速失败,而不会继续尝试调用依赖服务,从而减少对故障服务的访问。

  • 资源限制:Hystrix 可以对依赖服务的调用进行限流和并发控制,防止系统因为过多的请求导致资源耗尽。

  • 实时监控和指标收集:Hystrix 提供了丰富的实时监控和指标收集功能,可以通过 Hystrix 仪表板来查看依赖服务的健康状况、错误率、响应时间等指标,从而帮助开发人员及时发现和解决问题。

总的来说,Hystrix 可以提高分布式系统的容错性和弹性,通过隔离、降级、快速失败、断路器等机制,保护系统免受故障和延迟的影响,并提供实时监控和指标收集功能,方便开发人员进行故障诊断和性能优化。

3. 雪崩效应

当单个服务出现问题,调用这个服务的请求就出现线程阻塞,此时若有大量的请求涌入,容器的线程资源就会被消耗完毕导致服务瘫痪。

  1. 微服务中,一个请求可能需要调用多个微服务接口才能实现,会形成复杂的调用链路。
  2. 如果某服务出现异常,请求阻塞,用户得不到响应,容器中线程不会释放,于是越来越多用户请求堆积,越来越多线程阻塞。
  3. 单服务器支持线程和并发数有限,请求如果一直阻塞,会导致服务器资源耗尽,从而导致所有其他服务都不可用,从而形成雪崩效应。

4. 雪崩解决方案

预防、解决服务雪崩有三种方法:

  • 服务降级
  • 服务熔断
  • 服务限流
4.1. 服务降级

服务调用方调用服务提供方方法,服务方法内部出现异常时返回一个响应(fallback)给调用方,而不是长时间等待或者直接抛出无法处理的异常。例如:“服务器忙,请稍后再试!”

服务降级的触发条件是人为规定的,触发条件如下:

  • 报异常
  • 超时
  • 通信线程池被打满
4.2. 服务熔断

直接拒绝访问,快速返回一个开发者自定义的“异常信息”。

4.3. 服务限流

限制一个时间段内能够通行的请求数量。

降级和熔断的区别
熔断:熔断后请求不会再进调用服务的方法体,直接将链路断开,此后的每次请求都会直接被抛给fallback。
降级:降级后请求依然会进调用服务的方法体,每次请求都会先试图去调用服务,只是服务自己察觉到自己可能出问题了从而拒绝服务,然后再将请求转给fallback。直接转发到即当服务的调用出现超时、异常等情况时,返回一个响应(fallback)。降级可以用在服务调用的全链路上的任意位置,不过为了使用规范,一般建议用在提供方(让服务自己管好自己)。

二、实战案例

使用hystrix时,版本一定要选还在Netflix时的版本号,本文选择Hoxton版本以及其对应的spring boot 2.2.X或2.3.X

为了方便,项目在我们之前的zuul或者搭建eureka章节搭建的项目框架上进行开发。在之前的项目上开发并不意味着Hystrix要依赖于Eureka或者zuul,Hystrix可以独立应用。

在userservice服务中写一个错误,验证服务降低策略。

@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/login")
    public String login(){
        int res = 1/0;
        return "8080 login success";
    }
}

此时我们重启服务,访问orderservice服务,这个服务会调用userservice服务,有两个userservice服务,其中8080服务是有异常的。当订单服务调用到部署在8080端口的服务时就会报500错误。
在这里插入图片描述

现在我们来看下如何实现服务降低,在userservice服务异常时,快速返回一个备选的响应结果,从而避免用户长时间等待或系统崩溃的情况。

1. 引入依赖

在orderservice服务中引入依赖。

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

2. 熔断降级处理

2.1. 单点响应

适用:该方法是核心业务需要针对该方法设置一个单独的fallback。

@RestController
@RequestMapping("order")
public class OrderController {

    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(){
        return new RestTemplate();
    }

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/info")
    @HystrixCommand(fallbackMethod = "orderHandleException")
    public String getOrderInfo(){
        String url = "http://userservice/user/login";
        String info = restTemplate.getForObject(url, String.class);
        return "订单滴滴:" + info;
    }

    public String orderHandleException(){
        return "订单服务调用失败";
    }
}

添加@HystrixCommand(fallbackMethod = "orderHandleException"),指定了异常发生时的备选方案,异常发生会去调用orderHandleException方法。我们这里使用了fallabck为单点响应,即每个服务接口单独定义异常响应。目前我们没有进行任何配置文件的配置,但hystrix有默认的配置规则,不配置的情况下,默认配置规则也会生效,配置文件中的配置是全局的,我们也可以在方法上指定该方法的熔断策略。

 @GetMapping("/info")
 @HystrixCommand(fallbackMethod = "orderHandleException", commandProperties = {
         @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000")
 })
 public String getOrderInfo(){
     String url = "http://userservice/user/login";
     String info = restTemplate.getForObject(url, String.class);
     return "订单滴滴:" + info;
 }
2.2. 默认响应

我们上面的配置是针对单个方法的响应,也可以定义一个类中所有方法的默认fallback,来统一处理服务降级。

@RestController
@RequestMapping("order")
@DefaultProperties(defaultFallback = "globalFallback")
public class OrderController {

    @Bean
    @LoadBalanced
    public RestTemplate getRestTemplate(){
        return new RestTemplate();
    }

    @Autowired
    private RestTemplate restTemplate;


    @GetMapping("/info")
    @HystrixCommand(fallbackMethod = "orderHandleException", commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds",value = "2000")
    })
    public String getOrderInfo(){
        String url = "http://userservice/user/login";
        String info = restTemplate.getForObject(url, String.class);
        return "订单滴滴:" + info;
    }

    @GetMapping("/didi")
    @HystrixCommand
    public String getOrderInfo2(){
        int res = 1/0;
        return "订单didi";
    }

    public String globalFallback(){
        return "订单服务调用失败_gloabl";
    }

    public String orderHandleException(){
        return "订单服务调用失败";
    }
}

在这里插入图片描述

2.3. 全局响应

无论是单点响应还是默认响应,响应代码和业务代码都耦合在一起,全局响应将响应放在OpenFeign调用侧,使得业务代码和响应代码解耦。

依赖:OpenFeign的依赖中包含了hystrix,导入OpenFeign后不用单独导入hystrix。

在需要降级的服务上进行下面配置:orderservice
pom.xml

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

application.yml

feign:
  hystrix:
    enabled: true

orderservice服务改造:

@RestController
@RequestMapping("order")
public class OrderController {

    @Resource
    private UserServiceClient userServiceClient;

    @GetMapping("/info")
    public String getOrderInfo() {
        String info = userServiceClient.login();
        return "订单滴滴:" + info;
    }
}

新增feign包 ,创建 UserServiceClient类:

@FeignClient(name = "userservice", fallback = UserServiceFallback.class)
public interface UserServiceClient {

    @GetMapping("/user/login")
    String login();
}

这个类实现了服务远程调用,fallback指定了远程调用服务时异常触发服务降级。
新增fallback包,创建UserServiceFallback方法进行服务降级处理。

@Component
public class UserServiceFallback implements UserServiceClient {
    @Override
    public String login() {
        return "用户服务调用失败";
    }
}

启动类开启服务远程调用:@EnableFeignClients

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
@EnableFeignClients
public class ConsumerServerApplication {

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

重启服务,orderservice服务调用会轮询调用8080和8081端口的userservice服务,如果8081端口抛异常,会直接进行服务降级处理,返回用户服务调用失败给用户,如果8081端口超时则不会立马进行服务降级处理,而是会报504,直到满足默认的熔断配置规则才会触发服务熔断,才会直接返回用户服务调用失败给用户。

3. 开启熔断降级

在启动类上添加开启熔断和降级注解

@SpringBootApplication
@EnableEurekaClient
@EnableCircuitBreaker
public class ConsumerServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(ConsumerServerApplication.class, args);
    }
}

启动服务,再次访问orderservice服务。订单服务还是有可能成功的,因为8081端口的服务没有问题,异常是我们人为制造的。
在这里插入图片描述
目前的操作中并不需要进行配置文件配置,默认的熔断策略是5秒内20次调用失败熔断器开启5秒,在这5秒内所有请求直接返回fallback。

4. 熔断策略配置

在orderservice服务的配置文件中进行配置熔断策略:
在application.yml中,注释可能会导致错误,报错将错误删除即可。

# 配置熔断策略:
hystrix:
 command:
   default:
     circuitBreaker:
        # 强制打开熔断器 默认false关闭的。测试配置是否生效
        # forceOpen: false
        # 触发熔断错误比例阈值,默认值50% 10个请求有5个被拒绝访问,则开启熔断
        errorThresholdPercentage: 50
        # 熔断后休眠时长,默认值5秒 熔断器开启5s后,再关闭
        sleepWindowInMilliseconds: 10000
        # 熔断触发最小请求次数,默认值是20 累计请求20次无响应,开启熔断
        requestVolumeThreshold: 10

上面的配置就是10个请求有5个失败进行服务降级就会开启熔断器,熔断器开启10秒,如果在这个时间段内有新的请求发生,它们将不会被直接转发到服务,而是由 fallback 方法来处理,从而达到服务降级的目的。配置文件的配置是全局生效,配置也可以在对应的方法上,针对该方法配置对应的降级熔断的策略,上面已经介绍过了。

5. 服务超时

1/0从8080端口的userservice删去,使服务正常。
在8081端口的userservice中进行一个休眠操作,休眠3秒:

@RestController
@RequestMapping("/user")
public class UserController {

    @GetMapping("/login")
    public String login(){

        //演示熔断超时,服务降级
        try {
            System.out.println("8081服务睡了3秒");
            Thread.sleep(3000);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }

        return "8081 login success";
    }
}

此时重启服务,访问orderservice会发现,会发现报504错误,也就是网关超时。我们虽然使用了网关zuul,但504错误并不是因为配置了网关才会报504错误,即使不配置网关,客户端直接请求上游服务器,而上游服务器的响应时间过长,也可能导致 HTTP 504 错误。此外,还有一些其他的因素,比如网络连接问题、DNS 问题等,也可能导致 HTTP 504 错误。

# 配置熔断策略:
hystrix:
 command:
   default:
     circuitBreaker:
        # 触发熔断错误比例阈值,默认值50% 10个请求有5个被拒绝访问,则开启熔断
        errorThresholdPercentage: 50
        # 熔断后休眠时长,默认值5秒 熔断器开启5s后,在关闭
        sleepWindowInMilliseconds: 10000
        # 熔断触发最小请求次数,默认值是20 累计请求20次无响应,开启熔断
        requestVolumeThreshold: 10
      execution:
        isolation:
          thread:
            # 熔断超时设置,默认为1秒 过了超时时间后,做服务降级,给用户的请求返回设置的默认值
           timeoutInMilliseconds: 2000

修改服务提供者方法,休眠3秒钟,这时超时时间是2s,过了超时时间仍调用不到服务,(满足熔断策略配置规则)此时触发熔断。如果休眠时间小于超时时间,那么不会触发熔断,而是一直报504异常。即使不设置熔断超时时间,默认的熔断时间就是1秒了,所以一般来说都会触发熔断。

文章来源:https://blog.csdn.net/m0_53951384/article/details/135502217
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。