1雪崩效应概述
多个微服务之间调用的时候假设微服务A调用微服务B和微服务C微服务B和微服务C又调用其它的微服务这就是所谓的“扇出”。如果扇出的链路上某个微服务的调用响应时间过长或者不可用对微服务A的调用就会占用越来越多的系统资源进而引起系统崩溃所谓的“雪崩效应”
2熔断机制概述
熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长时会进行服务的降级进而熔断该节点微服务的调用快速返回错误的响应信息。当检测到该节点微服务调用响应正常后恢复调用链路。 在Spring Cloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况当失败的调用到一定阈值缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。
3: 熔断类型
在Hystrix里面熔断又分为三种情况半熔断、熔断打开、熔断关闭
- 熔断打开请求不再进行调用当前服务内部设置时钟一般为MTTR平均故障处理时间)当打开时长达到所设时钟则进入半熔断状态
- 半熔断 部分请求根据规则调用当前服务如果请求成功且符合规则则认为当前服务恢复正常关闭熔断
- 熔断关闭: 熔断关闭不会对服务进行熔断
4: 断路器图解
5断路器在什么情况下开始起作用
涉及到断路器的三个重要参数快照时间窗、请求总数阀值、错误百分比阀值。
- 快照时间窗断路器确定是否打开需要统计一些请求和错误数据而统计的时间范围就是快照时间窗默认为最近的10秒。
- 请求总数阀值在快照时间窗内必须满足请求总数阀值才有资格熔断。默认为20意味着在10秒内如果该hystrix命令的调用次数不足20次即使所有的请求都超时或其他原因失败断路器都不会打开。
- 错误百分比阀值当请求总数在快照时间窗内超过了阀值比如发生了30次调用如果在这30次调用中有15次发生了超时异常也就是超过50%的错误百分比在默认设定50%阀值情况下这时候就会将断路器打开。
6断路器开启或者关闭的条件
- 当满足一定的阀值的时候默认10秒内超过20个请求次数
- 当失败率达到一定的时候默认10秒内超过50%的请求失败
- 到达以上阀值断路器将会开启
- 当开启的时候所有请求都不会进行转发
- 一段时间之后默认是5秒这个时候断路器是半开状态会让其中一个请求进行转发。如果成功断路器会关闭若失败继续开启。重复4和5
7断路器打开之后
- 再有请求调用的时候将不会调用主逻辑而是直接调用降级fallback。通过断路器实现了自动地发现错误并将降级逻辑切换为主逻辑减少响应延迟的效果。
- 原来的主逻辑要如何恢复呢
对于这一问题hystrix也为我们实现了自动恢复功能。
当断路器打开对主逻辑进行熔断之后hystrix会启动一个休眠时间窗在这个时间窗内降级逻辑是临时的成为主逻辑当休眠时间窗到期断路器将进入半开状态释放一次请求到原来的主逻辑上如果此次请求正常返回那么断路器将继续闭合主逻辑恢复如果这次请求依然有问题断路器继续进入打开状态休眠时间窗重新计时。
8线程隔离示意图
9依赖隔离
Hystrix提供了两种隔离策略线程池隔离和信号量隔离默认采用线程池隔离。
- 线程池隔离
Hystrix使用舱壁模式来实现线程池的隔离它会为每一个Hystrix命令创建一个独立的线程池不同服务通过使用不同线程池彼此间将不受影响这样就算某个在Hystrix命令包装下的依赖服务出现延迟过高的情况也只是对该依赖服务的调用产生影响而不会拖慢其他的服务
这种方式需要为每个依赖的服务申请线程池有一定的资源消耗通过线程池大小可以控制并发量当线程池饱和时可以提前拒绝服务,防止依赖问题扩散。建议线程池不要设置过大否则大量堵塞线程有可能会拖慢服务器 - 线程池隔离的好处
1应用自身得到完全的保护不会受不可控的依赖服务影响。
2可以有效的降低接入新服务的风险
3当依赖的服务从失效恢复正常后它的线程池会被清理并且能够马上恢复健康的服务相比之下容器级别的清理恢复速度要慢得多。
4当依赖的服务出现配置错误的时候线程池会快速的反应出此问题通过失败次数、延迟、超时、拒绝等指标的增加情况。同时可以在不影响应用功能的情况下通过实时的动态属性刷新来处理它。
5当依赖的服务因实现机制调整等原因造成其性能出现很大变化的时候此时线程池的监控指标信息会反映出这样的变化。同时可以通过实时动态刷新自身应用对依赖服务的阈值进行调整以适应依赖方的改变。
10信号量隔离
- 线程隔离会带来线程开销有些场景比如无网络请求场景可能会因为用开销换隔离得不偿失为此Hystrix提供了信号量隔离当服务的并发数大于信号量阈值时将进入fallback。
- 实现方式是使用一个原子计数器或信号量来记录当前有多少个线程在运行请求过来了先判断计数器的数值若超过设置的最大线程个数则丢弃该类型的新请求若不超过则执行计数操作请求来计数器+1。
信号隔离与线程隔离最大不同在于执行依赖代码的线程依然是请求线程而线程池方式下业务请求线程和执行依赖的服务的线程不是同一个线程