服务熔断, 服务降级
服务熔断, 服务降级
参考:
https://blog.csdn.net/pengjunlee/article/details/86688858
https://blog.csdn.net/llianlianpay/article/details/79768890
在介绍熔断机制之前, 需要理解微服务的雪崩效应. 在微服务架构中, 微服务是完成一个单一的业务功能, 这样做的好处是可以做到解耦, 每个微服务可以独立演进. 但是, 一个应用可能会有多个微服务组成, 微服务之间的数据交互通过运程调用完成. 这就带来一个问题, 假设微服务A调用微服务B和微服务C, 微服务B和微服务C又调用其他的微服务, 这就是所谓的"扇出".
如果扇出的链路上某个微服务的调用响应时间过长或者不可用, 对微服务A的调用就会占用越来越多的系统资源, 进而引起系统崩溃, 所谓的"雪崩效应"
#服务熔断
熔断机制是应对雪崩效应的一种微服务链路保护机制。
当扇出链路的某个微服务不可用或者响应时间太长时,会对该服务内部的非核心接口进行服务降级,如果还是不能处理, 就会触发服务熔断,快速返回"错误"的响应信息。
当服务异常时直接就会熔断当前服务
#服务降级
服务降级是从整个系统的负荷情况出发和考虑的,对某些负荷会比较高的情况,为了预防某些功能(业务场景)出现负荷过载或者响应慢的情况,在其内部暂时舍弃对一些非核心的接口和数据的请求,而直接返回一个提前准备好的fallback(退路)错误处理信息。这样,虽然提供的是一个有损的服务,但却保证了整个系统的稳定性和可用性。
就像美团正常时, 显示所有订单, 但是并发量高时, 只显示100条
#执行流程
假设消费者调用生产者模块的A服务, 响应超时或是占用资源过多时, 就会对该模块下的其他服务进行服务降级, 如果其他服务降级后还是不能满足要求, 就会直接熔断该服务, 通过调用getFallback()
来调用定义好的fallback
其他服务恢复
#熔断VS降级
-
相同点:
目标一致 都是从可用性和可靠性出发,为了防止系统崩溃;
用户体验类似 最终都让用户体验到的是某些功能暂时不可用;
-
不同点:
触发原因不同 服务熔断一般是某个服务(下游服务,即被调用的服务)故障引起,而服务降级一般是从整体负荷考虑