<返回更多

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

2021-02-18    
加入收藏

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

 

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 分钟,表示还没有超过流量限制,进行处理,并将第一个元素压出队列,将新的请求时间压入队列。

声明:本站部分内容来自互联网,如有版权侵犯或其他问题请与我们联系,我们将立即删除或处理。
▍相关推荐
更多资讯 >>>