玩转SpringCloud专题(十五)-SpringCloud之Hystrix服务熔断

1.服务熔断概述

熔断其实是在降级的基础上引入了重试的机制。当某个时间内失败的次数达到了多少次就会触发熔断机制。熔断机制是应对雪崩效应的一种微服务链路保护机制。

断路器很好理解，当​​Hystrix Command​​​请求后端服务失败数量超过一定比例(默认50%)，断路器会切换到开路状态(​​Open​​​)。这时所有请求会直接失败而不会发送到后端服务。 断路器保持在开路状态一段时间后(默认10秒)，自动切换到半开路状态(​​HALF-OPEN​​​)。这时会判断下一次请求的返回情况， 如果请求成功，断路器切回闭路状态(​​CLOSED​​​)， 否则重新切换到开路状态(​​OPEN​​​)。 ​​Hystrix​​的断路器就像我们家庭电路中的保险丝，一旦后端服务不可用，断路器会直接切断请求链，避免发送大量无效请求影响系统吞吐量， 并且断路器有自我检测并恢复的能力。

熔断器开关相互转换的逻辑图：

在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是​​​@HystrixCommand​​。

我们来说说断路器的工作原理。当我们把服务提供者eureka-client中加入了模拟的时间延迟之后，在服务消费端的服务降级逻辑因为hystrix命令调用依赖服务超时，触发了降级逻辑，但是即使这样，受限于Hystrix超时时间的问题，我们的调用依然很有可能产生堆积。

这个时候断路器就会发挥作用，那么断路器是在什么情况下开始起作用呢？这里涉及到断路器的三个重要参数：快照时间窗、请求总数下限、错误百分比下限。这个参数的作用分别是：

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

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

错误百分比下限：当请求总数在快照时间窗内超过了下限，比如发生了30次调用，如果在这30次调用中，有16次发生了超时异常，也就是超过50%的错误百分比，在默认设定50%下限情况下，这时候就会将断路器打开。

那么当断路器打开之后会发生什么呢？当熔断器在10秒内发现请求总数超过20，并且错误百分比超过50%，这个时候熔断器打开。打开之后，再有请求调用的时候，将不会调用主逻辑，而是直接调用降级逻辑，返回fallback。通过断路器，实现了自动地发现错误并将主逻辑切换为降级逻辑，减少响应延迟的效果。

在断路器打开之后，处理逻辑并没有结束，我们的降级逻辑已经被成了主逻辑，那么原来的主逻辑要如何恢复呢？对于这一问题，hystrix也为我们实现了自动恢复功能。当断路器打开，对主逻辑进行熔断之后，hystrix会启动一个休眠时间窗，在这个时间窗内，降级逻辑是临时的成为主逻辑，当休眠时间窗到期，断路器将进入半开状态，释放一次请求到原来的主逻辑上，如果此次请求正常返回，那么断路器将继续闭合，主逻辑恢复，如果这次请求依然有问题，断路器继续进入打开状态，休眠时间窗重新计时。

通过上面的一系列机制，hystrix的断路器实现了对依赖资源故障的端口、对降级策略的自动切换以及对主逻辑的自动恢复机制。这使得我们的微服务在依赖外部服务或资源的时候得到了非常好的保护，同时对于一些具备降级逻辑的业务需求可以实现自动化的切换与恢复，相比于设置开关由监控和运维来进行切换的传统实现方式显得更为智能和高效。

2.服务熔断实现

导入依赖
在基础依赖之外我们只需要导入Hystrix的依赖即可

<!--服务熔断组件-->
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
</dependency>

启动类
添加对应的注解即可

@EnableCircuitBreaker // 开启熔断 断路器
@EnableEurekaClient
@SpringBootApplication
public class SpringcloudEurekaConsumerApplication {

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

客户端修改
注意@HystrixCommand注解的内容

@RequestMapping(value = "/get", method = RequestMethod.GET)
    @ResponseBody
    // 一旦调用服务方法失败并抛出了错误信息后，会自动调用@HystrixCommand标注好的fallbackMethod调用类中的指定方法
    @HystrixCommand(fallbackMethod = "processHystrix_Get",
            commandProperties = {
                    //默认 20 个;10s 内请求数大于 20 个时就启动熔断器，当请求符合熔断条件时将触发 getFallback()。
                    @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_REQUEST_VOLUME_THRESHOLD,
                            value = "10"),
                    //请求错误率大于 50%时就熔断，然后 for 循环发起请求，当请求符合熔断条件时将触发 getFallback()。
                    @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_ERROR_THRESHOLD_PERCENTAGE,
                            value = "50"),
                    //默认 5 秒;熔断多少秒后去尝试请求
                    @HystrixProperty(name = HystrixPropertiesManager.CIRCUIT_BREAKER_SLEEP_WINDOW_IN_MILLISECONDS,
                            value = "5000"),
            })
    public User get(@RequestParam("id") Integer id) {
        User u = this.userClientService.getUserById(id);
        return u;
    }

    /**
     * 服务降级
     * 返回托底数据的方法
     * @param id
     * @return
     */
    public User processHystrix_Get(@RequestParam("id") Integer id) {
        User u = new User();
        u.setId(110);
        u.setUsername("该ID：" + id + "没有没有对应的信息,null--@HystrixCommand");
        u.setNote("no this database in MySQL");
        return u;
    }

启动provider和consumer访问查看，正常访问，可以从provider获取到数据。

异常访问。获取到的是托底数据，而且我们快速访问的话5秒内都返回的托底数据(同一个请求)，5秒后会尝试重试连接，这个测试的细心点可以看到这个效果的

3.服务降级与熔断的区别

下面通过一个日常的故事来说明一下什么是服务降级，什么是熔断。

故事的背景是这样的：由于小强在工作中碰到一些问题，于是想请教一下业界大牛小壮。于是发生了下面的两个场景：

小强在拿起常用手机拨号时发现该手机没有能够拨通，所以就拿出了备用手机拨通了某A的电话，这个过程就叫做降级（主逻辑失败采用备用逻辑的过程）。

由于每次小壮的解释都属于长篇大论，不太容易理解，所以小强每次找小壮沟通的时候都希望通过常用手机来完成，因为该手机有录音功能，这样自己可以慢慢消化。由于上一次的沟通是用备用电话完成的，小强又碰到了一些问题，于是他又尝试用常用电话拨打，这一次又没有能够拨通，所以他不得不又拿出备用手机给某A拨号，就这样连续的经过了几次在拨号设备选择上的“降级”，小强觉得短期内常用手机可能因为运营商问题无法正常拨通了，所以，再之后一段时间的交流中，小强就不再尝试用常用手机进行拨号，而是直接用备用手机进行拨号，这样的策略就是熔断（常用手机因短期内多次失败，而被暂时性的忽略，不再尝试使用）。