高并发之降级和熔断

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

基本的容错模式

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

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

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

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

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

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

服务降级

服务熔断

服务熔断与服务降级比较

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

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

1.共性：

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

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

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

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

2.区别：

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

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

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

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

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