服务降级、熔断、限流

清疚 2022-10-30 11:18 291阅读 0赞

**目录**

1、概念

1.1 降级

1.1.1 常见降级：

1.1.2 示例

1.2 熔断

1.2.1 熔断设计

1.2.2 示例

1.3 限流

1.3.1 算法

1.3.2 示例

2、区别

3、案例

--------------------

# 1、概念 #

## 1.1 降级 ##

*  服务降级处理是在客户端实现完成的，与服务端没有关系。
 *  当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。降级的思想是丢车保帅。

### 1.1.1 常见降级： ###

*  服务接口拒绝服务：页面能访问，但是添加删除提示服务器繁忙。页面内容也可在Varnish或CDN内获取。
 *  页面拒绝服务：页面提示由于服务繁忙此服务暂停。跳转到varnish或nginx的一个静态页面。
 *  延迟持久化：页面访问照常，但是涉及记录变更，会提示稍晚能看到结果，将数据记录到异步队列或log，服务恢复后执行。
 *  随机拒绝服务：服务接口随机拒绝服务，让用户重试，目前较少有人采用。因为用户体验不佳。

### 1.1.2 示例 ###

A -> B -> C，C服务存在C1、C2、C3、C4

1.  如果C4优先级较低，一定是先降级优先级地的接口C4 。
2.  如果服务链路整体没有性能特别差的点，比如就是外部流量突然激增，那么就从外到内开始降级。 
3.  如果某个服务能检测到自身负载上升，那么可以从这个服务自身做降级。

## 1.2 熔断 ##

如果某个目标服务调用慢或者有大量超时，此时，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

### 1.2.1 熔断设计 ###

三个模块：熔断请求判断算法、熔断恢复机制、熔断报警。

* 熔断请求判断机制算法：使用无锁循环队列计数，每个熔断器默认维护10个bucket，每1秒一个bucket，每个blucket记录请求的成功、失败、超时、拒绝的状态，默认错误超过50%且10秒内超过20个请求进行中断拦截。
 * 熔断恢复：对于被熔断的请求，每隔5s允许部分请求通过，若请求都是健康的（RT<250ms）则对请求健康恢复。
 * 熔断报警：对于熔断的请求打日志，异常请求超过某些设定则报警。

### 1.2.2 示例 ###

A -> B -> C，如果C出现问题了，那么B熔断了，则A就不用熔断了。

## 1.3 限流 ##

限流模式主要是提前对各个类型的请求设置最高的QPS阈值，若高于设置的阈值则对该请求直接返回，不再调用后续资源。

常见限流方式

*  基于请求限流：指从外部请求的角度考虑限流。
 *  基于资源限流：指从系统内部考虑，找到影响性能的关键资源，对其使用上限限制。

### 1.3.1 算法 ###

*  漏桶算法：漏桶算法思路很简单，水（请求）先进入到漏桶里，漏桶以一定的速度出水，当水流入速度过大会直接溢出，可以看出漏桶算法能强行限制数据的传输速率。
 *  令牌桶算法：对于很多应用场景来说，除了要求能够限制数据的平均传输速率外，还要求允许某种程度的突发传输。这时候漏桶算法可能就不合适了，令牌桶算法更为适合。  
    令牌桶算法的原理是系统会以一个恒定的速度往桶里放入令牌，而如果请求需要被处理，则需要先从桶里获取一个令牌，当桶里没有令牌可取时，则拒绝服务。

单机限流：Guava 中的 RateLimiter。在 Guava 的 RateLimiter 中，使用的就是令牌桶算法，允许部分突发流量传输。在其源码里，可以看到能够突发传输的流量等于 maxBurstSeconds \* qps。

集群限流：TC 提供的 common-blocking 组件提供此功能。

###       1.3.2 示例 ###

B只允许A以QPS<=5的流量请求，而C却只允许B以QPS<=3的qps请求，那么B给A的设定就有点大，上游的设置依赖下游。而且限流对QPS的配置，可能会随着服务加减机器而变化，最好是能在集群层面配置，自动根据集群大小调整。

# 2、区别 #

<table style="width:432.02pt;"> 
 <tbody> 
 <tr> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">概念</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">目的</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">触发方</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">触发场景</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">解决方</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">处理方案</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">所有用户表现一致</td> 
 <td style="border-color:#000000;text-align:center;vertical-align:middle;width:54pt;">用户表现</td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">熔断</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">从可用性可靠性着想，为防止系统的整体缓慢甚至崩溃</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">某个服务（下游服务）不可用</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">当失败的调用到一定阈值，如缺省是5秒内20次调用失败，就会启动熔断机制，自动触发</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">调用方</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">开启熔断之后，如何实现自动恢复？每隔一段时间，释放一个请求到服务端进行探测，如果后端服务已经恢复，则自动恢复</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">不一致</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">用户体验到的是某些功能暂时不可达或不可用</td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">降级</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">为防止系统的整体缓慢甚至崩溃</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">服务出问题或者影响到核心流程的性能则需要暂时屏蔽掉</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">整体负荷比较大，进行人工干预</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">调用方</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">取消降级</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">一致</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">用户体验到的是某些功能暂时不可达或不可用</td> 
 </tr> 
 <tr> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">限流</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">通过对并发访问/请求进行限速或者一个时间窗口内的的请求进行限速来保护系统</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">通过对进行限速来保护系统</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">超出了服务每分钟的调用量或服务的某个方法调用量</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">如果是由于当时压测并发数较高引起；视具体情况而定</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">调大阈值</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">一致</td> 
 <td style="border-color:#000000;vertical-align:middle;width:54pt;">一旦达到限制速率则可以拒绝服务或</td> 
 </tr> 
 </tbody> 
</table>

# 3、案例 #

如果你来设计一个整点限量秒杀系统，包括登录、抢购、支付（依赖支付宝）等核心功能，你会如何设计接口级的故障应对手段？

思路：

*  降级（丢车保帅）：在秒杀时，通过服务降级把注册、修改个人信息等非核心功能关闭掉。
 *  熔断：支付依赖第三方服务，要设置熔断策略，熔断后要给出友好提示，比如10分钟后再来支付。
 *  限流：抢购下单接口采用限流方式，如抢购1000件商品，则设置2000大小的队列，请求超过2000后直接拒绝掉。

参考：

[https://blog.csdn.net/qq\_30215957/article/details/104502657][https_blog.csdn.net_qq_30215957_article_details_104502657]

[http://www.bubuko.com/infodetail-2922067.html][http_www.bubuko.com_infodetail-2922067.html]

[https://my.oschina.net/weiweiblog/blog/3012389][https_my.oschina.net_weiweiblog_blog_3012389]

[https://www.jianshu.com/p/681eec473eb4][https_www.jianshu.com_p_681eec473eb4]

[https_blog.csdn.net_qq_30215957_article_details_104502657]: https://blog.csdn.net/qq_30215957/article/details/104502657
[http_www.bubuko.com_infodetail-2922067.html]: http://www.bubuko.com/infodetail-2922067.html
[https_my.oschina.net_weiweiblog_blog_3012389]: https://my.oschina.net/weiweiblog/blog/3012389
[https_www.jianshu.com_p_681eec473eb4]: https://www.jianshu.com/p/681eec473eb4