Hystrix熔断器解析

介绍

微服务架构应用的特点就是多服务，而服务层之间通过网络进行通信，从而支撑起整个应用系统，所以，各个微服务之间不可避免的存在耦合依赖关系。但任何的服务应用实例都不可能永远的健康或网络不可能永远的都相安无事，所以一旦某个服务或局部业务发生了故障，会导致系统的不可用，我们知道当故障累积到一定程度就会造成系统层面的灾害，也就是级联故障，也叫雪崩效应，所以微服务需要在故障累计到上限之前阻止或疏通这些故障以保证系统的稳固安全，而Hystrix熔断器就可以实现这样的功能。

Hystrix设计目标

• 对通过第三方客户端库访问的依赖项（通常是通过网络）的延迟和故障进行保护和控制。
• 在复杂的分布式系统中阻止级联故障。
• 快速失败，快速恢复。
• 回退，尽可能优雅地降级。
• 启用近实时监控、警报和操作控制。

Hystrix工作流程

1. 包裹请求：使用HystrixCommand包裹对依赖的调用逻辑，每个命令在独立的线程中执行，使用了设计模式中的“命令模式”；
2. 跳闸机制：当某服务的错误率超过一定阈值时，Hystrix可以自动或者手动跳闸，停止请求该服务一段时间；
3. 资源隔离：Hystrix为每个依赖都维护了一个小型的线程池（或者信号量）。如果该线程已满，则发向该依赖的请求就会被立即拒绝，而不是排队等候，从而加速失败判定；
4. 监控：Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功、失败、超时、以及被拒绝的请求等；
5. 回退机制：当请求失败、超时、被拒绝，或当断路器打开时，执行回退逻辑，回退逻辑由开发人员自行提供，如返回一个缺省值；
6. 自我修复：断路器打开一段时间后，会自动进入“半开”状态，此时断路器可允许一个请求访问依赖的服务，若请求成功，则断路器关闭，否则断路器转为“打开”状态

重要配置参数详解

• circuitBreaker.enabled – 熔断器是否启用，默认是true
• circuitBreaker.requestVolumeThreshold – 滑动窗口内（10s）的请求数阈值，只有达到了这个阈值，才有可能熔断，默认是20
• circuitBreaker.errorThresholdPercentage – 错误率阈值，默认50%
• circuitBreaker.sleepWindowInMilliseconds – 熔断器打开之后，为了能够自动恢复，每隔一段时间放一个请求过去，试探所依赖的服务是否恢复，默认5000ms
• execution.isolation.thread.timeoutInMilliseconds – 方法执行超时时间，默认值是 1000ms

使用Hystrix

这里以Dubbo服务提供者和消费者为例说明

1. 导入依赖包（提供者和消费者）

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-hystrix</artifactId>
    <version>2.0.1.RELEASE</version>
</dependency>

2. 启动类添加注释@EnableHystrix，开启服务容错（提供者和消费者）
3. 服务实现类方法添加注释（提供者）

@HystrixCommand(commandProperties = {
            @HystrixProperty(name="circuitBreaker.requestVolumeThreshold", value = "10"),
            @HystrixProperty(name="execution.isolation.thread.timeoutInMilliseconds", value="2000")
    })

4. 控制层方法添加注释@HystrixCommand(fallbackMethod="error")（消费者），以及添加回调方法

public String error() {
        return "服务暂不可用";
    }

参考资料

• https://www.cnblogs.com/lfalex0831/p/9199459.html
• https://blog.csdn.net/nangeali/article/details/82596769
• http://www.imooc.com/article/76515