限流、熔断和降级

  • 限流:顾名思义是为了限制流量峰值避免让服务不堪重负,是一种出于对服务稳定性的保护
  • 熔断:限流已完成,那服务是否就是稳定的、高可用的呢?在某些突发状况下,下游服务频繁超时,导致接口迟迟无法返回,会资源无法及时释放掉。虽进行了限流,但是新的流量过来时,还有一部分存量请求尚未处理完成,从而形成恶性循环,最终的结果依然是服务不堪重负。因此,熔断是上游服务的一种自我保护机制。
  • 降级:细心的同学可能已经发现,将下游服务熔断后业务流转岂不是无法正常完成了。为此,就有了降级,降级分为流程降级和组件降级
  1. 顾名思义,流程降级就是换个流程,比如某下游服务非核心数据查询异常,那我可以不展示改数据。比如下游服务接口调用异常,改为MQ异步处理。再比如,双十一期间交易流量巨大,将用户信息修改降掉,通知用户该期间无法进行信息维护,这些都属于流程降级。
  2. 不同于流程降级,组件异常可能会影响多个业务流程,比如redis集群异常,那么所有用到redis组件的流程都会受到影响。此时,我们就需要将组件降级,具体通过什么方式进行“补偿”就要依托于具体业务来确定了。
  3. 综上可以看出,不同于熔断的自我保护机制,降级实则是对业务流程的一种保护机制
  • 降级一定会伴生熔断吗?答案是否定的,很多服务有降级但并没有熔断。熔断无非是担心下游服务响应太慢,无法在预期的时间内拿到结果从而导致上游服务资源无法释放,负载过高。但是如果上游服务接口超时时间设置较短,那也就不存在这种问题了。通常这种情况下会自动降级,代码健壮性较好。
posted @ 2022-04-29 15:27  机械公敌  阅读(614)  评论(0编辑  收藏  举报