Hystrix解决雪崩问题

什么是Hystix

Hystix是Netflix开源的一个延迟和容错库，用于隔离访问远程服务，防止出现级联失败。

什么是雪崩问题

微服务中，服务间调用关系错综复杂，一个请求，可能需要调用多个微服务接口才能实现，会形成非常复杂的调用
链路：一次业务请求，需要调用A、P、H、I四个服务，这四个服务又可能调用其它服务。 如果此时，某个服务出
现异常，用户请求得不到响应，则tomcat的线程不会释放，于是越来越多的用户请求到来，越来越多的线程会阻塞。
服务器支持的线程和并发数有限，请求一直阻塞，会导致服务器资源耗尽，从而导致所有其它服务都不可用，形成雪崩效应

Hystrix解决雪崩问题

解决雪崩问题的手段主要是服务降级，服务降级：优先保证核心服务，而非核心服务不可用或弱可用。包括： - 线程隔离 - 服务熔断

线程隔离

做线程隔离的目的就是如果某个服务出现问题可以把它控制在一个小的范围，不至于影响到全局；比如给A这个微服务分配了能装5条线程的线程池 所以说最多也只是堵塞5个线程
Hystrix为每个依赖服务调用分配一个小的线程池，如果线程池已满调用将被立即拒绝，默认不采用排队，加速失败判定时间。用户的请求将不再直接访问服务，而是通过线程池中的空闲线程来访问服务，如果线程池已满，或者请求超时，则会进行降级处理

服务降级：可以优先保证核心服务

用户的请求故障时，不会被阻塞，更不会无休止的等待或者看到系统崩溃，至少可以看到一个执行结果（例如返回
友好的提示信息） 。

1、在客户端（消费端） 引入依赖

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

2、（消费端）启动类添加注解@EnableCircuitBreaker

//@SpringBootApplication
//@EnableDiscoveryClient // 开启Eureka客户端 和在user-service引入的注解相同  注册到Eureka
//@EnableCircuitBreaker   //开启熔断
@SpringCloudApplication   //包含上面三个注解
public class ConsumerApplication {
.....
}

3、编写降级逻辑，即一旦请求失败或线程池已满，就访问自定义的降级方法。
两种方式：一、指定哪个方法来从当降级方法。二、默认的降价方法

@RestController
@RequestMapping("/consumer")
@Slf4j   //   把日志对象配置进来  下面就通过log.error在日志打印信息
@DefaultProperties(defaultFallback = "defaultFallback")   //声明默认的降级方法
public class ConsumerController {

    @Autowired
    private RestTemplate restTemplate;

    @GetMapping("/{id}")
    //用来声明一个降级逻辑的方法 表示如果微服务不能正常提供服务，执行queryByIdFallback方法
    //@HystrixCommand(fallbackMethod = "queryByIdFallback")
    @HystrixCommand     //如果使用默认的降级方法，这个注解必须有，如果想要使用自己指定的降级方法，就像上面那个那样写
    public String queryById(@PathVariable("id") Long id){     //因为在这里返回user对象没什么用，所以改为String
    
        if (id==1){    //设置，如果传进来的是1那么就抛出异常
            throw new RuntimeException("太忙了");
        }

        String url = "http://user-service/user/"+id;
        return restTemplate.getForObject(url,String.class);

    }

    //默认的失败降级方法   相同的返回值，不需要写参数
    public String queryByIdFallback(Long id) {
        log.error("查询用户信息失败。id：{}", id);
        return "对不起，网络太拥挤了！";
    }

    //默认的熔断处理方法
    public String defaultFallback(){
        return "默认提示：对不起，网络太拥挤了！";
    }

}

服务熔断

熔断原理：在分布式系统中应用服务熔断后；服务调用方可以自己进行判断哪些服务反应慢或存在大量超时，可以针对这些服务进行主动熔断，防止整个系统被拖垮。Hystrix的服务熔断机制，可以实现弹性容错；当服务请求情况好转之后，可以自动重连。通过断路的方式，将后续 请求直接拒绝，一段时间（默认5秒）之后允许部分请求通过，如果调用成功则回到断路器关闭状态，否则继续打 开，拒绝请求的服务。

状态机有3个状态：
Closed：关闭状态（断路器关闭），所有请求都正常访问。
Open：打开状态（断路器打开），所有请求都会被降级。Hystrix会对请求情况计数，当一定时间内失败请求
百分比达到阈值，则触发熔断，断路器会完全打开。默认失败比例的阈值是50%，请求次数最少不低于20次。
Half Open：半开状态，不是永久的，断路器打开后会进入休眠时间（默认是5S）。随后断路器会自动进入半开状态。此时会释放部分请求通过，若这些请求都是健康的，则会关闭断路器，否则继续保持打开，再次进行休眠计时

分析：熔断器开始是关闭的，但是如果出现请求次数20以上且失败率大于50%，即触碰到了这个阈值，就会打开熔 断器，打开熔断器，此时就访问的服务进行降级处理，即请求直接拒绝。5秒之后，熔断器变为半开状态， 允许部分请求访问，如果请求调用成功，就将熔断器变为关闭状态，如果请求调用失败，熔断器变为关闭 状态，拒绝请求，5秒后熔断器又变为半开状态，允许部分请求，然后再判断请求是否成功。这样Hystrix的服务熔断机制就实现了弹性容错，即会自动改变熔断器的状态。

要在被访问的请求中添加@HystrixCommand注解

@GetMapping("{id}")
@HystrixCommand
public String queryById(@PathVariable Long id) {
}

测试：
当我们疯狂访问id为1的请求时（超过20次），就会触发熔断。断路器会打开，一切请求都会被降级处理。此时你访问id为2的请求，会发现返回的也是失败，而且失败时间很短，只有 5 秒左右；因进入半开状态之后2是 可以的。

如果想改时间的配置，可以参考下方：

hystrix:
  command:
    default:
      execution:
        isolation:
          thread:
            timeoutInMilliseconds: 2000 #服务降级超时时间
      circuitBreaker:
		errorThresholdPercentage: 50 # 触发熔断错误比例阈值，默认值50%
		sleepWindowInMilliseconds: 10000 # 熔断后休眠时长，默认值5秒
		requestVolumeThreshold: 10 # 熔断触发最小请求次数，默认值是20