hystrix学习笔记

Hystrix概述

分布式系统面临的问题

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或不可用，对微服务A的调用就会占用越来越多的系统资源，进行引起系统崩溃，所谓的“服务雪崩”。对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的联级故障。

hystrix是什么

1. Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖必不可免的会调用失败，比如超时、异常等，Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联鼓掌，以提高分布式系统的弹性。
2. 断路器本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝）向调用方返回一个符合预期的、可处理的备选响应（Fallback），而不是常见的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。

官网 link https://github.com/Netflix/Hystrix/wiki/How-To-Use

服务降级

哪些情况会触发降级？
例：程序运行异常、超时、服务熔断触发服务降级、线程池/信号量打满也会导致服务降级。
服务的降级处理是在客户端实现完成，与服务端没有关系。在服务熔断机制下，每个方法都要有一个对应的注解HystrixCommand和fallback方法，这样显然是不合适的，而且对本身业务也有侵入性。所以服务降级可以实现上述逻辑的解耦和分离。而这里又是面向接口编程，所以自然想到了将异常等处理逻辑与接口进行绑定，即可实现对业务本身无侵入，实现解耦。

代码示例

provider端服务降级

controller层方法

@GetMapping("/hystrix/payment/timeout/{id}")
public String timeout(@PathVariable("id") Integer id) {
    String s = paymentService.paymentInfo_TimeOut(id);
    log.info(s);
    return s;
}

service层（这里的hystrixproperty参数设置超时时间为3秒，如果超过三秒就调用paymentInfo_TimeOutHandler方法）

   @HystrixCommand(fallbackMethod = "paymentInfo_TimeOutHandler", commandProperties = {
            @HystrixProperty(name = "execution.isolation.thread.timeoutInMilliseconds", value = "3000")
    })
    public String paymentInfo_TimeOut(Integer id) {
        //int i  = 1/0;
        Integer num = 5;
        try {
            TimeUnit.SECONDS.sleep(num);
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
        return "线程池：" + Thread.currentThread().getName() + " paymentInfo_TimeOut, id:" + id + " 耗时：" + num;
    }

    public String paymentInfo_TimeOutHandler(Integer id) {
        return "服务繁忙～请稍后再试";
    }

consumer端服务降级

consumer端feign接口

@FeignClient(value = "cloud-payment-hystrix-service",fallback = PaymentFallback.class)
public interface PaymentHystrixService {

    @GetMapping("/hystrix/payment/ok/{id}")
    String paymentInfoOK(@PathVariable("id") Integer id);

    @GetMapping("/hystrix/payment/timeout/{id}")
    String paymentInfoTimeOut(@PathVariable("id") Integer id);
}

实现feign接口（服务降级处理类）

@Component
public class PaymentFallback implements PaymentHystrixService {

    @Override
    public String paymentInfoOK(Integer id) {
        return " 全局处理 ok";
    }

    @Override
    public String paymentInfoTimeOut(Integer id) {
        return " 全局处理 消费者端服务降级，服务繁忙～请稍后";
    }
}

调用结果
provider端响应：

consumer端响应

服务熔断

熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或响应时间太长时，会进行服务的降级，进而熔断该节点微服务的调用，快速返回“错误”的响应信息。当检测到该节点的微服务调用响应正常后恢复调用链路。在Spring Cloud框架里熔断机制通过Hystix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定的阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand

熔断类型：

①熔断打开：请求不再调用当前服务,内部设置一般为MTTR(平均故障处理时间),当打开长达导所设时钟则进入半熔断状态

②熔断关闭：熔断关闭后不会对服务进行熔断

③熔断半开：部分请求根据规则调用当前服务,如果请求成功且符合规则则认为当前服务恢复正常,关闭熔断

大神论文：https://martinfowler.com/bliki/CircuitBreaker.html

断路器在什么情况下开始起作用？

涉及到断路器的三个重要参数：快照时间窗、请求总数阀值、错误百分比阀值

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

2. 请求总数阀值：在快照时间窗内，必须满足请求总数阀值才有资格熔断。默认为20，意味着在10秒内如果该hystrix命令的调用次数不足20次，即使所有的请求都超时或其它原因失败，断路器都不会打开

3. 错误百分比阀值：当请求总数在快照时间窗内超过了阀值，比如发生了30次调用，如果在这30次调用中，有超过15次发生了超时异常，也就是超过50%的错误百分比（默认错误阀值50%），断路器会打开

断路器开启或关闭的条件？

1、当满足一定阈值时（默认10秒内超过20个请求次数）

2、当失败率达到一定时（默认10秒内超过50%的请求失败）

3、到达以上阈值，断路器将开启

4、当开启时，所有请求将不会转发

5、一段时间后（默认是5秒），这个时候断路器是半开状态，会让其中一个进行转发。如果成功，断路器会关闭，若失败，继续开启。重复4~5

断路器打开之后

再有请求调用的时候，将不会再调用主逻辑，而是直接调用降级fallback,通过断路器，实现了自动地发现错误并将降级逻辑切换为主逻辑，减少响应延迟的效果。

原来的逻辑如何恢复？

当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时

代码示例（这里只演示服务提供方的熔断）
controller层

  @GetMapping("/hystrix/payment/circuit/{id}")
    public String circuit(@PathVariable("id") Integer id) {
        String s = paymentService.paymentCircuitBreaker(id);
        log.info(s);
        return s;
    }

service层

@HystrixCommand(fallbackMethod = "paymentCircuitBreaker_handler", 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(Integer id) {
    Assert.isTrue(id > 0, "***********id不能为负数");
    return Thread.currentThread().getName() + " 调用成功，流水号：" + IdUtil.simpleUUID();
}

public String paymentCircuitBreaker_handler(Integer id) {
    return "id不能为负数，请重新输入";
}

调用多次http://localhost:8001/hystrix/payment/circuit/-1 之后

达到熔断条件，然后调用http://localhost:8001/hystrix/payment/circuit/1结果为：

等个几秒后再调用http://localhost:8001/hystrix/payment/circuit/1 响应：

官网断路器流程图


官网 https://github.com/Netflix/Hystrix/wiki/How-it-Works

服务限流

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

服务监控DashBoard

简记：7色，1圈，1线

7个颜色分别对应有英文提示说明；

1圈越大，说明该服务的访问频率越高，流量压力也比较大；

1线就很明显了，实时的调用频率。

①实心圆：两层含义，它通过颜色的变化代表了实例的健康程度，它的健康程度从绿色<黄色<橙色<红色依次递减。此外，它的大小也会根据实例的请求流量发生变化，流量越大该实心圆就越大。所以通过实心圆的展示，就可以在大量的实例中快速的发现故障实例和高压力实例。

②曲线：用来记录2分钟内的相对变化，可以通过它来观察到流量的上升和下降趋势

部分资料参考自 link