接口限流、服务降级、熔断

接口限流

为什么需要限流

与用户打交道的服务

比如web服务、对外API，这种类型的服务有以下几种可能导致机器被拖垮

1. 用户增长过快（这是好事）
2. 因为某个热点事件（微博热搜）
3. 竞争对象爬虫
4. 恶意的刷单

这些情况都是无法预知的，不知道什么时候会有10倍甚至20倍的流量进来，如果遇到此类情况，扩容是根本来不及的，弹性扩容也是来不及的；

对内的RPC服务

一个服务A的接口可能被BCDE多个服务进行调用，在B服务发生突发流量时，直接把A服务给调用挂了，导致A服务对CDE也无法提供服务。 这种情况时有发生，解决方案有两种：

1. 每个调用方采用线程池进行资源隔离
2. 使用限流手段对每个调用方进行限流

限流的算法

单机的限流算法有：

1. 计数器
2. 令牌桶
3. 漏桶

1、计数器算法

原理：采用计数器实现限流有点简单粗暴，一般我们会限 制一秒钟的能够通过的请求数。

比如限流qps为100，算法的实现思路就是从第一个请求进来开始计时，在接下去的1s内，每来一个请求，就把计数加1，如果累加的数字达到了100，那么后续的请求就会被全部拒绝。等到1s结束后，把计数恢复成0，重新开始计数。

实现：对于每次服务调用，可以通过AtomicLong.incrementAndGet()方法来给计数器加1并返回最新值，通过这个最新值和阈值进行比较。

弊端：如果我在单位时间1s内的前10ms，已经通过了100个请求，那后面的990ms，只能眼巴巴的把请求拒绝，我们把这种现象称为“突刺现象”。

2、漏桶算法

为了消除"突刺现象"，可以采用漏桶算法实现限流，漏桶算法这个名字就很形象。

原理：算法内部有一个容器，类似生活用到的漏斗，当请求进来时，相当于水倒入漏斗，然后从下端小口慢慢匀速的流出。不管上面流量多大，下面流出的速度始终保持不变。如果容器满了，那么新进来的请求就丢弃。

不管服务调用方多么不稳定，通过漏桶算法进行限流，每10毫秒处理一次请求。因为处理的速度是固定的，请求进来的速度是未知的，可能突然进来很多请求，没来得及处理的请求就先放在桶里，既然是个桶，肯定是有容量上限，如果桶满了，那么新进来的请求就丢弃。

实现：在算法实现方面，可以准备一个队列，用来保存请求，另外通过一个线程池定期从队列中获取请求并执行，可以一次性获取多个并发执行。

弊端：无法应对短时间的突发流量。

3、令牌桶算法

从某种意义上讲，令牌桶算法是对漏桶算法的一种改进，桶算法能够限 制请求调用的速率，而令牌桶算法能够在限 制调用的平均速率的同时还允许一定程度的突发调用。

原理：在令牌桶算法中，存在一个桶，用来存放固定数量的令牌。算法中存在一种机制，以一定的速率往桶中放令牌。每次请求调用需要先获取令牌，只有拿到令牌，才有机会继续执行，否则选择选择等待可用的令牌、或者直接拒绝。

放令牌这个动作是持续不断的进行，如果桶中令牌数达到上限，就丢弃令牌，所以就存在这种情况，桶中一直有大量的可用令牌，这时进来的请求就可以直接拿到令牌执行，比如设置qps为100，那么限流器初始化完成一秒后，桶中就已经有100个令牌了，这时服务还没完全启动好，等启动完成对外提供服务时，该限流器可以抵挡瞬时的100个请求。所以，只有桶中没有令牌时，请求才会进行等待，最后相当于以一定的速率执行。

实现思路：可以准备一个队列，用来保存令牌，另外通过一个线程池定期生成令牌放到队列中，每来一个请求，就从队列中获取一个令牌，并继续执行。

集群限流

比如为了限 制某个资源被每个用户或者商户的访问次数，5s只能访问2次，或者一天只能调用1000次，这种需求，单机限流是无法实现的，这时就需要通过集群限流进行实现。

如何实现？为了控制访问次数，肯定需要一个计数器，而且这个计数器只能保存在第三方服务，比如redis。

大概思路：每次有相关操作的时候，就向redis服务器发送一个incr命令，比如需要限 制某个用户访问/index接口的次数，只需要拼接用户id和接口名生成redis的key，每次该用户访问此接口时，只需要对这个key执行incr命令，在这个key带上过期时间，就可以实现指定时间的访问频率。

还可以用消息队列来限流，比如处理大促时的流量削峰。

服务降级

降级指系统将某些业务或者接口的功能降低，可以是只提供部分功能，也可以是完全停掉所有功能。

案例

1. 双11，订单暂时不允许修改收货地址
2. 论坛，降级为只能看帖子，不能发帖子
3. App的日志上传接口，可以完全停掉一段时间，这段时间内APP都不能上传日志

方式

常见的实现降级的方式：独立降级系统。简单一点可以在配置中心配置。

将降级操作独立到一个单独的系统中，可以实现复杂的权限管理、批量操作等功能。其基本架构如下：

熔断

熔断的目的是应对依赖的外部系统故障的情况

案例

1. A服务的X功能依赖B服务的某个接口，当B服务的接口响应很慢的时候，A服务的X功能响应肯定被拖慢，进一步导致A服务的线程都被卡在X功能处理上，此时A服务的其他功能都会被卡住或者响应非常慢
2. 加入熔断机制后，A服务不再请求B服务这个接口，A服务内部只要发现是请求B服务的这个接口就立即返回错误，从而避免A服务整个被拖慢甚至拖死

实现

1. 关键是需要有一个统一的API调用层，由API调用层来进行采样或者统计，如果接口调用散落在代码各处就没法进行统一处理了
2. 另一个关键是阈值的设计，例如1分钟内30%的请求响应时间超过1秒就熔断，这个策略的“1分钟”“30%”“1秒”都对最终的熔断效果有影响
3. 实践中一般都是先根据分析再确定阈值，然后上线观察效果，再进行调优

https://blog.csdn.net/bjpowernode_com/article/details/85162473