熔断器 —— Hystrix理论以及应用

虽然Hystrix已经停止更新了，但是其设计理念依旧是非常先进，为后续各种熔断器的开发提供了思路借鉴。因此还是值得大家去学习的！

Hystrix是Netflix在2012年对外开源的一款熔断降级工具，用于解决分布式系统的延迟和容错问题。

分布式系统面临的问题：

复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某个时候将不可避免的失败。

服务雪崩：

多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其他的微服务，这就是所谓的 “ 扇出 ” 。

如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A 的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的 “ 雪崩效应 ”。

对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。

所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接受流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫 雪崩。

要避免这样的级联故障，就需要有一种链路中断的方案：
服务降级、服务熔断

1 Hystrix 简介

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

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

官网资料：https://github.com/Netflix/Hystrix/wiki/How-To-Use
Hystrix 官宣：停更进入维护阶段

但是它推荐使用 resilience4j 替代，但是国内用的比较少，后续会介绍 SpringCloud Alibaba Sentinel 实现熔断和断流。

2 Hystrix 功能：

服务降级
服务熔断
接近实时的监控
限流、隔离等
Hystrix重要概念：

1.服务降级：

服务器忙，请稍后再试，不让客户端等待，并立刻返回一个友好提示，fallback

哪些情况会发出降级？

 - 程序运行异常
 - 超时
 - 服务熔断触发服务降级
 - 线程池 / 信号量打满也会导致服务降级

2.服务熔断

类似保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法，并返回友好提示

3.服务限流

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

3 构建微服务实战：

这里大家直接去看我的github源代码吧。

4 降级容错解决的维度要求

超时导致服务器变慢 (转圈)

超时不再等待

出错（宕机或程序运行出错）

 出错要有兜底

解决

 对方服务(8001)超时了，调用者(80)不能一直卡死等待，必须有服务降级

 对方服务(8001)宕机了，调用者(80)不能一直卡死等待，必须有服务降级
 
 对方服务(8001)OK，调用者(80)自己出故障或有自我要求(自己的等待时间小于服务提供者)，自己处理降级

5 Hystrix服务降级实战

降级配置：
HystrixCommand

8001: 先从自身找问题，设置自身调用超时时间的峰值，峰值时间之内可以正常调用，超过了要有兜底的方法处理，作为服务降级，fallback.

8001: fallback
（1）业务类启用
HystrixCommand报异常后如何处理
（2）主启动类激活
添加新注解，@EnableCircuitBreaker.


HystrixCommand是Hystrix对外暴露的抽象类，其内部定义了Hystrix熔断器的常规操作。

@Override
public String run(){
	// 业务逻辑
}

@Override
public String getFallBack(){
	// 发生错误或者熔断的时候，执行逻辑
}

Hystrix对应对的配置信息，通过HystrixCommand.Setter完成。

提供了2种隔离策略：线程池隔离（默认）和信号量隔离，信号量隔离可以用来完成限流操作。

如果我们故意制造两个异常：

int age = 10/0; 运行时异常

我们能接受3秒钟，它运行5秒钟，超时异常。
当前服务不可用了，做服务降级，兜底的方案都是paymentInfoTimeOutHandler

(1) 消费者服务降级

#yml添加配置,开启 hystrix
feign:
 hystrix:
   enabled: true

模拟异常


PS： 我们自己配置过的热部署方式对Java代码的改动明显，但对@HystrixCommand内属性的修改建议重启微服务。

问题1：

这样如果每个业务方法都对应一个兜底的方法，100个方法就有100个服务降级，会出现代码膨胀问题，我们需要一个统一的 fallbackMethod，统一的和自定义的分开。

解决问题：

@DefaultProperties(defaultFallback = "")

1 : 1 每个方法配置一个服务降级方法，造成代码膨胀

1 : N 除了个别重要核心业务有专属，其他普通的可以通过@DefaultProperties(defaultFallback = “”) 统一跳转到统一处理结果页面

这样通用的和独享的各自分开，避免了代码膨胀，合理减少了代码量。

问题2：

现在客户端与服务端关系紧紧耦合，客户端能跑是因为接口调用了微服务的业务逻辑方法，我们如果针对客户端接口做一些处理，把它调用的所有微服务方法进行降级，就可以解决耦合问题。

解决问题：

这个案例服务降级处理是在客户端80完成的，与服务端8001没有关系，只需要为 Feign 客户端定义的接口添加一个服务降级处理的实现类即可实现解耦。

@Component
public class PaymentFallbackService implements PaymentHystrixService {
    @Override
    public String paymentInfo_OK(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_OK ,o(╥﹏╥)o";
    }

    @Override
    public String paymentInfo_TimeOut(Integer id) {
        return "-----PaymentFallbackService fall back-paymentInfo_TimeOut ,o(╥﹏╥)o";
    }
}

接口使用@FeignClient(fallback = xxx.class)指定哪个类来处理异常

@Component
@FeignClient(value = "CLOUD-PROVIDER-HYSTRIX-PAYMENT", fallback = PaymentFallbackService.class)
public interface PaymentHystrixService {

    @GetMapping("/payment/hystrix/ok/{id}")
    public String paymentInfoOk(@PathVariable("id") int id);

    @GetMapping(value = "/payment/hystrix/timeout/{id}")
    public String paymentInfoTimeOut(@PathVariable("id") int id);

}