浅谈springcloud入门（四）-组件Hystrix熔断器

 在生活中，我们会遇到一种现象，当我们线路由于电压过高的时候，为了保护线路的整体安全，我们总会在电闸上安装保险丝，当遇到电路故障时，保险丝会烧断从而使电路安全得到保证，那么在微服务中，是否也有当单个服务异常导致整个微服务故障，我们留有的“保险丝”来进行预先防备呢？答案是有的，于是Hystrix出现了。

一、为什么要使用Hystrix？

在微服务架构中，服务与服务之间通过远程调用的方式进行通信，一旦某个被调用的服务发生了故障，其依赖服务也会发生故障，此时就会发生故障的蔓延，最终导致系统瘫痪。Hystrix实现了断路器模式，当某个服务发生故障时，通过断路器的监控，给调用方返回一个错误响应，而不是长时间的等待，这样就不会使得调用方由于长时间得不到响应而占用线程，从而防止故障的蔓延。Hystrix具备服务降级、服务熔断、线程隔离、请求缓存、请求合并及服务监控等强大功能。

二、什么是Hystrix？

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

Hystrix其设计原则如下：

1. 防止单个服务异常导致整个微服务故障。

2. 快速失败，如果服务出现故障，服务的请求快速失败，线程不会等待。

3. 服务降级，请求故障可以返回设定好的二手方案数据（兜底数据）。

4. 熔断机制，防止故障的扩散，导致整个服务瘫痪。

5. 服务监控，提供了Hystrix Bashboard仪表盘，实时监控熔断器状态

三、Hystrix的功能

1.资源隔离(流控，限流)

资源隔离包括线程池隔离和信号量隔离，作用是限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用 ，这里可以简单的理解为资源隔离就是限制请求的数量。

线程池隔离：使用一个线程池来存储当前请求，线程池对请求作处理，设置任务返回处理超时时间，堆积的请求先入线程池队列。这种方式要为每个依赖服务申请线程池，有一定的资源消耗，好处是可以应对突发流量（流量洪峰来临时，处理不完可将数据存储到线程池队里慢慢处理）

信号量隔离：使用一个原子计数器（或信号量）记录当前有多少个线程在运行，请求来先判断计数器的数值，若超过设置的最大线程个数则丢弃该类型的新请求，若不超过则执行计数操作请求来计数器+1，请求返回计数器-1。这种方式是严格的控制线程且立即返回模式，无法应对突发流量（流量洪峰来临时，处理的线程超过数量，其他的请求会直接返回，不继续去请求依赖的服务）

2.服务熔断

当服务端发生了错误后，客户端会调用降级方法。但是，当有一个新的访问时，客户端会一直调用服务端，让服务端运行一些明知会报错的代码。这能不能避免啊，我知道我错了，你访问我的时候，就直接去访问降级方法，不要再让我执行错的代码。

​ 这就是服务熔断，就好比我们家中的保险丝。当检测到家中的用电负荷过大时，就断开一些用电器，来保证其他的可用。在分布式系统中，就是调用一个系统时，在一定时间内，这个服务发生的错误次数达到一定的值时， 我们就打开这个断路器，不让调用过去，而是让他直接去调用降级方法。再过一段时间后，当一次调用时，发现这个服务通了，就将这个断路器改为“半开”状态，让调用一个一个的慢慢过去，如果一直没有发生错误，就将这个断路器关闭，让所有的服务全部通过。

3.服务降级

对于我们目前的单个SpringBoot项目来说，我们使用Ajax等一些方式调用接口时，如果服务器发生错误，我们在前端就会对这个错误进行处理。有可能是重试调用接口，或者给用户一个友好的提示，比如“服务繁忙，稍后再试”啥的。

​ 但是在分布式系统中，同样也会发生一些“错误”，而且在多个服务之间调用时，如果不能对这些“错误”进行友好的处理，就会导致我们整个项目瘫痪，这是万万不能发生的。所以Hystrix利用服务降级来很好的解决了这个问题。这个其实就类似于我们的try-catch这样的机制，发生错误了，我就执行catch中的代码。

​ 通过服务降级，能保证在某个或某些服务出问题的时间，不会导致整个项目出现问题，避免级联故障，从而来提高分布式系统的弹性。

简单理解就是服务降级就是当服务因为网络故障，服务器故障，读取超时等原因造成服务不可达的情况下返回一些预先准备好的数据给客户端。

4.缓存

提供了请求缓存、请求合并实现 ， 在高并发的场景之下，Hystrix请求缓存可以方便地开启和使用请求缓存来优化系统，达到减轻高并发时请求线程的消耗、降低请求响应时间的效果。

四、Hystrix工作原理

对于一次依赖调用，会被封装在一个HystrixCommand对象中，调用的执行有两种方式，一种是调用execute()方法同步调用，另一种是调用queue()方法进行异步调用。

执行时会判断断路器开关是否打开，如果断路器打开，则进入getFallback()降级逻辑；如果断路器关闭，则判断线程池/信号量资源是否已满，如果资源满了，则进入getFallback()降级逻辑；如果没满，则执行run()方法。再判断执行run()方法是否超时，超时则进入getFallback()降级逻辑，run()方法执行失败，则进入getFallback()降级逻辑，执行成功则报告Metrics。Metrics中的数据包括执行成功、超时、失败等情况的数据，Hystrix会计算一个断路器的健康值，也就是失败率，当失败率超过阈值后则会触发断路器开关打开。

getFallback()逻辑为：如果没有实现fallback()方法，则直接抛出异常，另外fallback降级也是需要资源的，在fallback时需要获取一个针对fallback的信号量，只有获取成功才能fallback，获取信号量失败，则抛出异常，获取信号量成功，才会执行fallback方法并且会响应fallback方法中的内容。

五、项目实战

1.导入依赖

由于Feign整合了Hystrix，所以我们不需要再导入依赖

2.yml配置

feign:
  hystrix:
    enabled: true

 3.FeignClient配置

fallbackFactory进行降级，fallback也可以但不会返回结果

@FeignClient(value = "user-server" ,fallbackFactory = UserFeignClientFallbackFactory.class)//fallbackFactory进行降级，fallback也可以但不会返回结果
public interface UserFeignClient {
    //调用用户服务的接口
    //最终完整调用用户服务的Url:"http://user-server/user/" + id
    @GetMapping("/user/{id}")
    User getUser(@PathVariable("id") Long id);


}

4.FeignClientFallbackFactory 

//降级需要交给Spring管理
@Component
public class UserFeignClientFallbackFactory implements FallbackFactory<UserFeignClient> {
    @Override
    public UserFeignClient create(Throwable throwable) {
        return new UserFeignClient() {
            @Override
            public User getUser(Long id) {
                //进行降级
                throwable.printStackTrace();
                return new User(-1L,"熔断机制","调用服务失败，请重新调试");
            }
        };
    }
}

5.测试效果