微服务—服务降级、熔断、限流

前言

微服务架构中，由于涉及到的服务较多，并且服务之间需要通信，这就意味着增加了服务的复杂度，复杂度的增加也就带来了服务的不可靠性：比如网络超时、服务宕机、服务超时等。

如果一条服务调用链中的某个服务出现了问题，就会导致上游调用服务线程积压，最终导致上游服务卡死无响应（这个过程称为服务雪崩）。

防止服务雪崩的解决思路：一是提前预防，限制流量防止流量过大导致服务被压垮，二是过程干预，比如真正遇到某个服务异常（不可用或超时）如何处理，比如熔断降级。

限流

任何架构都有有限的处理能力，通过提前干预，基于QPS 和并发线程数来限制流量，保证服务不被压垮。限流的方式有：

直接限流，多余的流量直接拒绝！

排队限流，让多余的流量排队等待处理，也称为流量整形。

比如 nginx 里有对应的 limit_req 、limit_rate配置来限制流量。

熔断

为了解决服务雪崩问题，提出了熔断这一概念，跟股市熔断、以及疫情期间的航班熔断类似。

服务熔断是根据一定的熔断策略（被调用服务的异常和超时率等）来决定是否断开该服务的调用，熔断后直接不返回或返回个空(快速失败）。

熔断后会尝试性地放行部分请求，来试探服务调用是不是能恢复（关闭熔断）。

熔断通常在调用端执行。

（异常）降级

没有触发熔断前，针对业务异常，可以做降级处理：比如记录异常,下次定时任务去补偿数据，返回一个默认值。这种处理称为降级操作。

注意，服务没有熔断，仍然被调用了，只是在执行的过程抛了异常，降级操作相当于捕获了异常然后返回一个默认值而已。

比如 sentinel 和 feign 都有对应的 fallback 属性来指定降级处理的类或者方法。

---

原创不易，如果觉得有用，就交个朋友吧