微服务如何限制接口调用次数？

这种限制接口调用次数的方式，我们通常称之为限流，那么为什么要做限流呢，一般有两种原因：

1. 首先是防止服务提供方被大量的请求击垮

我们开发一个项目，最理想的状况是有多少请求，都可以正常地响应，但是在现在的互联网环境，我们很难评估用户的增长，很难评估访问量有多少，甚至有些时候会遇到恶意攻击；那么相比于项目被流量击垮，【限制流量，只满足部分访问的正常响应】要好一些。

简单说就是：满足所有请求 > 满足部分请求 > 项目被击垮，所有请求无法响应。

2. 计费

现在很多平台对外开发的接口，并不全是免费的，比如普通会员每天只能调用 1000 次接口，高级会员每天可以调用 10 万次接口，或者按照调用量计费。

那么如何限制服务接口的调用次数呢？

使用限流算法

通常我们可以通过限流算法达到限制接口调用次数，比如计数器法、滑动窗口法、漏桶算法、令牌桶算法，这里我们就用令牌桶算法举例。

令牌桶算法，我们可以看做有一个桶，桶里面有 N 个令牌，并且系统会以一个恒定的速度往桶里投放令牌，每次处理之前先要获取令牌，如果获取不到的话，就拒绝服务；在这里我们使用 google 出品的 Guava 工具库，里面提供了一个开箱即用的令牌桶 RateLimiter。

如图，我们编写了一个简单的接口，省略了业务逻辑，只返回一个字符串；我们设置 RateLimiter.create(2)，表示每秒不超过 2 个任务被提交。

让我们用接口工具模拟一下并发调用：

他强任他强，我自巍然不动。因为我们使用了限流算法，每秒只处理 2 个请求，所以从日志中我们可以看到这样的效果：每秒只有两条日志。

分布式架构下的限流

因为使用开源的组件，限流的实现看起来非常简单，但是这里也有一个比较大的问题，就是实例中是一个应用包，但在实际的项目中，我们通常会是用集群部署的方式，将我们的应用部署在多台机器上，那么这时候该如何限流呢？

每台服务器上的应用自己控制自己的响应数量？比如每天只能调 100 次，那部署 10 台的话，总量就变成了 1000 次了；

反推？因为每天总量只能调 100 次，部署 10 台，那就是每台每天只能调 10 次？这是个很差的办法，先不说流量一定可以平均分配到每台机器上，如果有一台机器挂掉了，是不是今天只能支持调用 90 次了？

通常的解决方案，可以把令牌桶中的令牌，不要放在本地，而是放在一个公共的地方，比如 redis 中，每次请求过来，就计算是否超过限制的总量，如果未超过，则正常处理，如果已超过，则返回错误信息。

具体做法是，用 Redis 中的 key-100 作为令牌桶，其中 100 表示一分钟可以调用 100 次，每次处理前对 value 进行减 1，返回的值大于 0 表示可以处理；每分钟将 value 设置回 100；或计数累加，开始是 0 ，不断累加，最后超过单位时间的总量限制；

不过这个方法要有一个定时任务，去设置令牌的数量，另外这种方法是不能应对突发流量的，比如前 59 秒一次请求也没有，第 60 秒来了 100 次，第 61 秒进入了一个新的周期，又来了 100 次请求 ，这样实际上是在两秒内处理了 200 次请求。

另外一种方案是使用 Redis 中的有序队列 Sorted Set ，存储近 100 次的调用时间，每次有新请求的时候，对比队列中第一个元素的时间和当前时间，如果相差超过 1 分钟，表示还没有超过流量限制，进行处理，并将第一个元素压出队列，将新的请求时间压入队列。