前言
微服务架构中,由于涉及到的服务较多,并且服务之间需要通信,这就意味着增加了服务的复杂度,复杂度的增加也就带来了服务的不可靠性:比如网络超时、服务宕机、服务超时等。
如果一条服务调用链中的某个服务出现了问题,就会导致上游调用服务线程积压,最终导致上游服务卡死无响应(这个过程称为服务雪崩)。
防止服务雪崩的解决思路:一是提前预防,限制流量防止流量过大导致服务被压垮,二是过程干预,比如真正遇到某个服务异常(不可用或超时)如何处理,比如熔断降级。
限流
任何架构都有有限的处理能力,通过提前干预,基于QPS 和并发线程数来限制流量,保证服务不被压垮。限流的方式有:
直接限流,多余的流量直接拒绝!
排队限流,让多余的流量排队等待处理,也称为流量整形。
比如 nginx 里有对应的 limit_req 、limit_rate配置来限制流量。
熔断
为了解决服务雪崩问题,提出了熔断这一概念,跟股市熔断、以及疫情期间的航班熔断类似。
服务熔断是根据一定的熔断策略(被调用服务的异常和超时率等)来决定是否断开该服务的调用,熔断后直接不返回或返回个空(快速失败)。
熔断后会尝试性地放行部分请求,来试探服务调用是不是能恢复(关闭熔断)。
熔断通常在调用端执行。
(异常)降级
没有触发熔断前,针对业务异常,可以做降级处理:比如记录异常,下次定时任务去补偿数据,返回一个默认值。这种处理称为降级操作。
注意,服务没有熔断,仍然被调用了,只是在执行的过程抛了异常,降级操作相当于捕获了异常然后返回一个默认值而已。
比如 sentinel 和 feign 都有对应的 fallback 属性来指定降级处理的类或者方法。
如果觉得还不错的话,关注、分享、在看(关注不失联~), 原创不易,且看且珍惜~