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

接口限流

为什么需要限流

与用户打交道的服务

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

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

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

对内的RPC服务

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

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

限流的算法

单机的限流算法有：

计数器
令牌桶
漏桶

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带上过期时间，就可以实现指定时间的访问频率。

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

服务降级

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

案例

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

方式

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

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

熔断

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

案例

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

实现

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

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