hystrix 解决服务雪崩效应

1、服务雪崩效应

默认情况下tomcat只有一个线程池去处理客户端发送的所有服务请求，这样的话在高并发情况下，如果客户端所有的请求堆积到同一个服务接口上，

就会产生tomcat的所有线程去处理该服务接口，可能会导致其他服务接口访问延迟；

 

2、Hystrix服务保护框架，在微服务中Hystrix为我们解决了哪些事情？

Hystrix 别名“豪猪”

1）断路器

2）服务降级

3）服务熔断

4）服务隔离机制

5）服务雪崩效应

--》连环雪崩效应，如果比较严重的话，可能会导致整个微服务接口无法访问，所有服务都会瘫痪

 

3、解决服务雪崩效应原理：

1）服务降级

在高并发情况下，防止用户一直等待，使用服务降级方式（返回一个友好的提示直接给客户端，不会去处理请求，调用fallback本地方法），目的是为了用户体验

比如秒杀--当前请求人数过多，请稍后重试。（在tomcat中没有线程进行处理客户端请求的时候，不应该让用户一直转圈等待。）

2）服务熔断

例如保险丝，服务熔断的目的是为了保护服务，在高并发情况下，如果请求达到了一定的极限（可以自己设置阈值），如果流量超出了设置的阈值，会自动开启保护服务功能，使用服务降级方式返回一个友好的提示。

熔断机制和服务降级一起使用。

默认阈值为10个

3）服务隔离

采用线程池隔离，每个服务接口都有自己独立的线程池，每个线程池互不影响；

缺点：CPU占用率非常高。

不是所有的接口都要去采用线程池隔离，只有核心关键接口才需要

 

4、Hystrix设置禁止超时时间

当一个服务被大量线程数访问时，另外一个服务能访问，但是却跳到了fallback方法中，这是因为Hystrix需要设置禁止超时时间；

@HystrixCommand注解默认开启了线程池隔离，服务降级，服务熔断

feign超时时间需要设置，否则会报错

java.net.SocketTimeoutException: Read timed out

--》我设置这一步时，在yml文件中添加相关配置，idea没有给出相应提示，本来还有点怀疑，但是运行之后竟然成功
了。

 

5、Hystrix实现方式

Hystrix有两种方式实现：一种是注解，一种是接口

1）Hystrix的注解方式业务代码和return调用的方法是属于同一个线程的

2）而第二种方式，业务代码和return调用的方法是两个线程，并且属于不同线程池

3）第一种方式比较冗余，所以最好采用第二种方式

备注

1）这个Hystrix的超时时间会影响所有的接口，不是只针对@HystrixCommand注解的接口

2）如果调用其他接口超时的时候（默认是1秒时间），默认情况下业务逻辑是可以正常执行的，但是为了避免客户端等待，会直接执行服务降级方法。

常见错误

1）java.util.concurrent.TimeoutException: null

2）java.lang.RuntimeException: Hystrix circuit short-circuited and is OPEN