Hystrix

2024-01-30 15:36:04

Hystrix

目录

服务雪崩

  复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败，这就造成有可能会发生服务雪崩。
Hystrix
  服务雪崩：多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”.
  对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。

Hystrix简介

  Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。

断路器

  "断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝)，向调用方返回一个符合预期的、可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

Hystrix作用

  • 服务降级
  • 服务熔断
  • 接近实时的监控，限流

服务降级（Fall Back）

  假设微服务A要调用的服务B不可用了，需要服务B提供一个解决方法，而不是让服务A在那里傻等，耗死。不让客户端等待并立刻返回一个友好图示，比如像客户端提示服务器忙，请稍后再试等。

哪些情况会触发服务降级呢？
当程序运行异常、超时、服务熔断、线程池/信号量打满都会导致服务降级。

服务器端服务提供方进行服务降级

  降级的配置用 @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服务，我们发现其执行的方法确实为服务降级方法。

客户端消费方进行服务降级

  既然服务的提供方可以进行降级保护，那么服务的消费方，也可以更好的保护自己，也可以对自己进行降级保护，也就是说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秒，那么就会访问自己的降级服务方法。

统一全局服务降级方法

  而当前的这种处理方式是有问题的，也就是每个业务方法都对应了一个服务降级犯法，这会导致代码膨胀，所以我们应该定义一个统一的服务降级方法，统一的方法和自定义的方法分开。而且我们将服务降级方法和业务逻辑混合在了一起，这会导致代码混乱，业务逻辑不清晰。
  对于第一个问题，我们可以用feign接口中的@DefaultProperties(defaultFallback = “”) 注解来配置全局的服务降级方法，也就是说自己配置过@HystrixCommand(fallbackMethod = “”） fallbackMethod方法的采用自己配置的服务降级方法，而没有配置过的就采用@DefaultProperties(defaultFallback = “”) 配置的全局的服务降级方法。这样的话通用的服务降级方法和独享的服务降级方法分开，避免了代码膨胀，合理减少了代码量，修改服务消费方80的Controller入下：

@RestController
@Slf4j
@DefaultProperties(defaultFallback = "payment_Global_FallbackMethod") //全局服务降级
public class OrderHystrixController {

    @Autowired
    private PaymentHystrixService paymentHystrixService;

    @GetMapping("/consumer/payment/hystrix/ok/{id}")
    @HystrixCommand
    public 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访问的是定制服务降级方法，这里需要注意的是，无论是否配置了定制服务降级方法，都要在其服务上加入注解 @HystrixCommand， 否则服务降级和该服务没关系。

  而对于第二个问题， 我们可以为Feign客户端定义的接口添加一个服务降级处理的实现类即可实现解耦。

服务熔断（Break）

  服务熔断就相当于物理上的熔断保险丝。类比保险丝达到最大服务访问后，直接拒绝访问，拉闸断点，然后调用服务降级的方法并返回友好提示。

服务限流（Flow Limit）

  秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。

Hystrix使用

引入hystrix依赖

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

服务熔断使用

/**
     * 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")
    })

熔断器三个状态

Hystrix

状态 介绍
Closed 熔断关闭不会对服务进行熔断。
Open 请求不再进行调用当前服务，内部设置时钟一般为MTTR（平均故障处理时间），当打开时长达到所设时钟则进入半熔断状态（HALF-OPEN）。
Half Open 部分请求根据规则调用当前服务，如果请求成功且符合规则则认为当前服务恢复正常，关闭熔断。

熔断器工作过程

  1. 假设电路上的访问达到某个阈值（HystrixCommandProperties.circuitBreakerRequestVolumeThreshold()）…
  2. 并假设误差百分比超过阈值误差百分比（HystrixCommandProperties.circuitBreakerErrorThresholdPercentage()）…
  3. 然后，断路器从CLOSED为OPEN，触发熔断机制。
  4. 当它断开时，它会使针对该断路器的所有请求短路。
  5. 经过一段时间（HystrixCommandProperties.circuitBreakerSleepWindowInMilliseconds()）后，下一个单个请求被允许通过（这是HALF-OPEN状态）。如果请求失败，断路器将OPEN在睡眠窗口期间返回到该状态。如果请求成功，则断路器切换到，CLOSED，并且1.中的逻辑再次接管。
    Hystrix

熔断器在什么时候起作用

  • 熔断的三个重要参数

  1. 快照时间窗口期circuitBreaker.sleepWindowInMilliseconds：熔断器是否打开需要统计一些请求和错误数据，而统计的时间范围就是快找时间窗，默认为最近的10秒；

  2. 请求总数阈值circuitBreaker.requestVolumeThreshold：在快照时间窗内，必须满足请求总数阈值才有资格触发熔断，默认为20次，这意味着在快照时间窗规定的时间内，如果该Hystrix命令的调用次数不足20次，即使所有请求都超时或其他原因失败，熔断器都不会打开；

  3. 错误百分比阈值circuitBreaker.errorThresholdPercentage：当请求总数在快照时间窗内超过了阈值，且在这些调用中，超过错误百分比阈值比例的错误调用，熔断器就会打开。

  • 熔断器打开后再有请求调用的时候，将不会调用主逻辑，而是直接调用服务降级的方法，实现了自动发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

熔断器打开后如何关闭

  当熔断器打开后，对主逻辑进行熔断之后，Hystrix会启动一个 休眠时间窗 ， 在这个时间窗内，降级逻辑是临时的主逻辑，当休眠时间窗到期，熔断器会进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求能够正常访问，则熔断器会进入闭合状态，从而恢复主逻辑，如果注册请求依然有问题，则熔断器继续保持打开状态，并且休眠时间窗重新计时。

上一篇：第六节：SpringCloud Hystrix


下一篇：集成bug统计链接