高并发之降级和熔断

当用户请求 A、P、H、I 四个服务获取数据时，在正常流量下系统稳定运行，如果某天系统进来大量流量，其中服务 I 出现 CPU、内存占用过高等问题，结果导致服务 I 出现延迟、响应过慢，随着请求的持续增加，服务 I 承受不住压力导致内部错误或资源耗尽，一直不响应，此时更糟糕的是其他服务对 I 有依赖，那么这些依赖 I 的服务一直等待 I 的响应，也会出现请求堆积、资源占用，慢慢扩散到所有微服务，引发雪崩效应。

基本的容错模式

常见的容错模式主要包含以下几种方式：

1.主动超时：Http请求主动设置一个超时时间，超时就直接返回，不会造成服务堆积

2.限流：限制最大并发数

3.熔断：当错误数超过阈值时快速失败，不调用后端服务，同时隔一定时间放几个请求去重试后端服务是否能正常调用，如果成功则关闭熔断状态，失败则继续快速失败，直接返回。（此处有个重试，重试就是弹性恢复的能力）

4.隔离：把每个依赖或调用的服务都隔离开来，防止级联失败引起整体服务不可用

5.降级：服务失败或异常后，返回指定的默认信息

 

服务降级

由于爆炸性的流量冲击，对一些服务进行有策略的放弃，以此缓解系统压力，保证目前主要业务的正常运行。它主要是针对非正常情况下的应急服务措施：当此时一些业务服务无法执行时，给出一个统一的返回结果。

服务熔断

熔断这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。

服务熔断与服务降级比较

服务熔断对服务提供了proxy，防止服务不可能时，出现串联故障（cascading failure），导致雪崩效应。

服务熔断一般是某个服务（下游服务）故障引起，而服务降级一般是从整体负荷考虑。

1.共性：

目的 -> 都是从可用性、可靠性出发，提高系统的容错能力。

最终表现->使某一些应用不可达或不可用，来保证整体系统稳定。

粒度 -> 一般都是服务级别，但也有细粒度的层面：如做到数据持久层、只许查询不许增删改等。

自治 -> 对其自治性要求很高。都要求具有较高的自动处理机制。

2.区别：

触发原因 -> 服务熔断通常是下级服务故障引起；服务降级通常为整体系统而考虑。

管理目标 -> 熔断是每个微服务都需要的，是一个框架级的处理；而服务降级一般是关注业务，对业务进行考虑，抓住业务的层级，从而决定在哪一层上进行处理：比如在IO层，业务逻辑层，还是在外围进行处理。

实现方式 -> 代码实现中的差异。

服务熔断恢复需注意的问题

如果服务是幂等性的，则恢复重试不会有问题；而如果服务是非幂等性的，则重试会导致数据出现问题。

如若转载，请注明出处：开源字节 https://sourcebyte.cn/article/233.html