​前言

随着现在微服务、分布式系统的发展，各个服务之间的相互调用越来越复杂。为了保证自身服务的稳定性与高可用，当面对超过自身服务能力的请求调用时，要做一定的限流措施。如同五一、国庆期间的旅游出行、景区爆满，游客限流。我们的服务面对诸如秒杀、大促、618、双十一以及可能的恶意攻击、爬虫等高并发、大流量的场景也需要做服务限流。

对超出服务处理能力之外的请求进行拦截，对访问服务的流量进行限制，这就是服务限流。接下来我们就好好谈谈服务限流这回事儿。

两种限流方式

常见的限流方式可以分为两类：基于请求限流和基于资源限流。

基于请求限流指从外部访问的请求角度考虑限流，常见的方式有两种。

第一种是限制总量，也就是限制某个指标的累积上限，常见的是限制当前系统服务的用户总量，例如：某个直播间限制总用户数上限为100万，超过100万后新的用户无法进入；某个抢购活动商品数量只有100个，限制参与抢购的用户上限为1万个，1万的用户直接拒绝。

第二种是限制时间量，也就是限制一段时间内某个指标的上限，例如1分钟内只允许10000个用户访问；每秒请求峰值最高为10万。

优点：

缺点：

应用：

基于请求限流是从系统外部考虑的，而基于资源限流是从系统内部考虑的，也就是找到系统内部影响性能的关键资源，对其使用上限进行限制。常见的内部资源包括连接数、文件句柄、线程数和请求队列等。比如CPU的占用率超过80%的时候就开始拒绝新的请求。

优点：

缺点：

应用：

四种限流算法

常见的限流算法有4种，它们的实现原理和优缺点各不相同，在实际设计的时候需要根据业务场景来选择。

固定时间窗算法的实现原理是，统计固定时间周期内的请求量或者资源消耗量，超过限额就会启动限流，如下图所示：

优点：

缺点：

为了解决临界点问题，滑动时间窗算法应运而生，它的实现原理是，两个统计周期部分重叠，从而避免短时间内的两个统计点分属不同的时间窗的情况，如下图所示：

优点：

缺点：

漏桶算法的实现原理是，将请求放入“桶”（消息队列等），业务处理单元（线程、进程和应用等）从桶里拿请求处理，桶满则丢弃新的请求，如下图所示：

优点：

缺点：

漏桶算法主要适用于瞬时高并发流量的场景（例如刚才提到的0点签到、整点秒杀等）。在短短几分钟内涌入大量请求时，为了更好的业务效果和用户体验，即使处理慢一些，也要做到尽量不丢弃用户请求。

令牌桶算法和漏桶算法的不同之处在于，桶中放入的不是请求，而是“令牌”，这个令牌就是业务处理前需要拿到的“许可证”。也就是说，当系统收到一个请求时，先要到令牌桶里面拿“令牌”，拿到令牌才能进一步处理，拿不到就要丢弃请求。

它的实现原理是如下图所示：

优点：

缺点：

令牌桶算法主要适用于两种典型的场景，一种是需要控制访问第三方服务的速度，防止把下游压垮，例如支付宝需要控制访问银行接口的速率；另一种是需要控制自己的处理速度，防止过载，例如压测结果显示系统最大处理TPS是100，那么就可以用令牌桶来限制最大的处理速度。

五种限流策略

当请求流量达到限流阈值时，对多余的请求直接拒绝。

通过将多余的请求加入缓存队列或延时队列，来应对短期的流量突增，高峰期过后开始将堆积的请求流量逐渐处理。

可以监控系统相关指标、评估系统压力，通过注册中心、配置中心等动态调整限流阈值。

如果有优秀的服务监控系统与自动部署、发布系统，可以通过监控系统自动监测系统运行情况，对短期内服务压力暴增、流量大幅写入的情况进行邮件、短信等方式进行预警。

在满足特定条件下，可自动部署、发布相关服务，起到动态扩容的效果。

三个限流位置

可以通过Nginx、API路由网关等对域名或IP进行限流，同时可以拦截非法请求。

每个服务可以有自己的单机或集群限流措施，也可以调用第三方的限流服务，比如阿里的Sentinel限流框架。

也可以对基础服务层进行限流。

总结

本文从宏观角度总结了服务限流的两种方式，三个可以限流的位置，四种常见的限流算法，五种限流的策略。最后再补充几句，合理的限流配置，需要了解系统的吞吐量，所以，限流一般需要结合容量规划和压测来进行。当外部请求接近或者达到系统的最大阈值时，触发限流，采取其他的手段进行降级，保护系统不被压垮。

参考：