服务雪崩
服务雪崩
一、如何解决灾难性雪崩效应
1.1、造成雪崩的原因
- A.服务提供者不可用（硬件故障，程序Bug，缓存击穿，用户大量请求）
- 重试加大流量（用户重试，代码逻辑重试）
- 服务调用者不可用（同步等待造成的资源耗尽）最终的结果就是一个服务不可用，导致一系列服务的不可用，而往往这种后果往往无法预料的。
1.2、如何解决雪崩
- 降级：超时降级、资源不足时(线程或信号量)降级，降级后可以配合降级接口返回托底数据。实现一个fallback方法, 当请求后端服务出现异常的时候, 可以使用fallback方法返回的值.
- 隔离（线程池隔离和信号量隔离）：限制调用分布式服务的资源使用，某一个调用的服务出现问题不会影响其他服务调用。
- 融断：当失败率(如因网络故障/超时造成的失败率高)达到阀值自动触发降级，熔断器触发的快速失败会进行快速恢复。
- 缓存：提供了请求缓存。
- 请求合并：提供请求合并。
二、服务降级
三、服务请求缓存
四、服务请求合并
五、服务熔断
熔断机制相当于电路的跳闸功能。例如：我们可以配置熔断策略为当请求错误比例在10s内>50%时，该服务将进入熔断状态，后续请求都会进入fallback。
5.1、熔断原理图
六、隔离技术之线程
6.1、线程池隔离的优点
- 使用线程池隔离可以完全隔离依赖的服务（例如图中的A、B、C服务），请求线程可以快速放回。
- 当线程池出现问题时，线程池隔离是独立的，不会影响其他服务和接口。
- 当失败的服务再次变得可用时，线程池将清理并可立即恢复，而不需要一个长时间的恢复。
- 独立的线程池提高了并发性。
6.2、线程池隔离的缺点
线程池隔离的主要缺点是它们增加计算开销（CPU）。每个命令的执行涉及到排队、调度和上 下文切换都是在一个单独的线程上运行的。
七、隔离技术之信号量
八、线程池隔离和信号量隔离
8.1、什么情况下，用线程池隔离？
请求并发量大，并且耗时长（请求耗时长一般是计算量大，或读数据库）：采用线程隔离策略，这样的话，可以保证大量的容器(tomcat)线程可用，不会由于服务原因，一直处于阻塞或等待状态，快速失败返回。
8.2、什么情况下，用信号量隔离？
请求并发量大，并且耗时短（请求耗时短可能是计算量小，或读缓存）：采用信号量隔离策略，因为这类服务的返回通常会非常的快，不会占用容器线程太长时间，而且也减少了线程切换的一些开销，提高了缓存服务的效率。
九、Feign的雪崩处理：服务降级处理
9.1、Feign服务降级处理
9.2、Feign服务降级后的异步记录
十、Dashboard
10.1、集群环境下，收集监控数据（turbine）
十一、资料
11.1、源码示例
spring-cloud/ 服务雪崩