服务熔断, 服务降级

服务熔断, 服务降级

参考:

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降级

• 相同点：

  目标一致 都是从可用性和可靠性出发，为了防止系统崩溃；

  用户体验类似 最终都让用户体验到的是某些功能暂时不可用；

• 不同点：

  触发原因不同 服务熔断一般是某个服务（下游服务,即被调用的服务）故障引起，而服务降级一般是从整体负荷考虑