限流、熔断和降级

• 限流：顾名思义是为了限制流量峰值避免让服务不堪重负，是一种出于对服务稳定性的保护。
• 熔断：限流已完成，那服务是否就是稳定的、高可用的呢？在某些突发状况下，下游服务频繁超时，导致接口迟迟无法返回，会资源无法及时释放掉。虽进行了限流，但是新的流量过来时，还有一部分存量请求尚未处理完成，从而形成恶性循环，最终的结果依然是服务不堪重负。因此，熔断是上游服务的一种自我保护机制。
• 降级：细心的同学可能已经发现，将下游服务熔断后业务流转岂不是无法正常完成了。为此，就有了降级，降级分为流程降级和组件降级。

1. 顾名思义，流程降级就是换个流程，比如某下游服务非核心数据查询异常，那我可以不展示改数据。比如下游服务接口调用异常，改为MQ异步处理。再比如，双十一期间交易流量巨大，将用户信息修改降掉，通知用户该期间无法进行信息维护，这些都属于流程降级。
2. 不同于流程降级，组件异常可能会影响多个业务流程，比如redis集群异常，那么所有用到redis组件的流程都会受到影响。此时，我们就需要将组件降级，具体通过什么方式进行“补偿”就要依托于具体业务来确定了。
3. 综上可以看出，不同于熔断的自我保护机制，降级实则是对业务流程的一种保护机制。

• 降级一定会伴生熔断吗？答案是否定的，很多服务有降级但并没有熔断。熔断无非是担心下游服务响应太慢，无法在预期的时间内拿到结果从而导致上游服务资源无法释放，负载过高。但是如果上游服务接口超时时间设置较短，那也就不存在这种问题了。通常这种情况下会自动降级，代码健壮性较好。