容错的背景
随着服务数量的增加,整个架构出现故障的概率提高了,所以服务容错的需求增加了
在复杂的分布式架构的应用程序有很多的依赖,都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施,当前应用服务就有被拖垮的风险。
服务雪崩
服务雪崩效应是一种因服务提供者的不可用导致服务调用者的不可用,并将不可用逐渐放大的过程,服务雪崩就形成了。
形成的原因
我把服务雪崩的参与者简化为 服务提供者 和 服务调用者,
并将服务雪崩产生的过程分为以下三个阶段来分析形成的原因:
- 服务提供者不可用
- 重试加大流量
- 服务调用者不可用
1、服务雪崩的每个阶段都可能由不同的原因造成:比如
- 硬件故障
- 程序Bug
- 缓存击穿
- 用户大量请求
2、形成重试加大流量的原因有
- 用户重试
- 代码逻辑重试
3、服务调用不可用产生的主要原因是:
- 同步等待造成的资源耗尽
应对策略
“超时”:在调用方,一定时间内未得到响应则放弃请求;在异常时,确保资源的消耗有上限
“限流”:在提供方,限制进入系统的流量,确保在系统的负载范围内,保证系统能够正常运转
“仓壁模式”:资源隔离手段,在调用方使用线程池等方式,限制资源消耗在某个范围之内
“熔断器”: 在调用方,在系统上检测调用,如果发现了某个底层服务故障,则自动熔断,不再调用该服务”,隔一段时间再次检测是否恢复,如果恢复则加入集群
“断路器”。“断路器”是一种开关装置,就好比我们家里的熔断保险丝,当出现突发情况,会自动跳闸,避免整个电路烧坏。
那么当某个服务发生故障时,通过 Hystrix,会向调用方返回一个符合预期的、可处理的默认响应(也称备选响应,即fallBack),
而不是长时间的等待或者直接返回一个异常信息。这样就能保证服务调用方可以顺利的处理逻辑,而不是那种漫长的等待或者其他故障。
这就叫“服务熔断”,就跟熔断保险丝一个道理。
服务熔断机制是应对雪崩效应的一种微服务链路保护机制。当扇出链路的某个微服务不可用或者响应时间太长,就会进行服务的降级,
快速熔断该节点微服务的调用,返回默认的响应信息。当检测到该节点微服务调用响应正常后即可恢复。