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
原文地址：https://www.cnblogs.com/syjp/p/10389867.html