​前言

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

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

两种限流方式

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

  1. 基于请求限流

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

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

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

优点:

  • 实现简单

缺点:

  • 实践中面临的主要问题是比较难以找到合适的阈值。例如系统设定了1分钟10000个用户,但实际上6000个用户的时候系统就扛不住了;或者达到1分钟10000用户后,其实系统压力还不大,但此时已经开始丢弃用户访问了。而且还要考虑硬件相关的因素,例如一台32核的机器和64核的机器处理能力差别很大,阈值是不同的。

应用:

  • 适用于业务功能比较简单的系统,例如负载均衡系统、网关系统、抢购系统等。
  1. 基于资源限流

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

优点:

  • 有效地反映当前系统的压力,更好的进行限流

缺点:

  • 难以确定关键资源
  • 难以确定关键资源的阈值,需要在线上逐步调试,持续观察,直到找到合适的值。

应用:

  • 适用于具体的某个服务,比如订单系统、商品系统等。

四种限流算法

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

  1. 固定时间窗

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

优点:

  • 实现简单

缺点:

  • 存在临界点问题。例如上图中的红蓝两点只间隔了短短10秒,期间的请求数却已经达到200,超过了算法规定的限额(1分钟内处理100)。但是因为这些请求分别来自两个统计窗口,从单个窗口来看还没有超出限额,所以并不会启动限流,结果可能导致系统因为压力过大而挂掉。
  1. 滑动时间窗

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

优点:

  • 不存在临界点问题

缺点:

  • 相对于固定窗口,复杂度有所提升
  1. 漏桶算法

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

优点:

  • 突发大量流量时丢弃的请求较少,因为漏桶本身有缓存请求的作用

缺点:

  • 可以平滑流量,但是无法解决流量突增的问题。
  • 桶大小动态调整比较困难,需要不断的尝试才能找到符合业务需求的最佳桶大小。
  • 无法精确控制流出速度,也就是业务的处理速度。

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

  1. 令牌桶算法

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

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

优点:

  • 通过控制放入令牌的速率,可以动态调整处理速率,实现更加灵活。
  • 可以平滑限流,同时可以容忍突发流量,因为桶里面可以累积一定数量的令牌,当突发流量过来的时候,桶里面有累积的令牌,此时的业务处理速度会超过令牌放入的速度。

缺点:

  • 突发大量流量的时候可能丢弃很多请求,因为令牌桶不能累积太多令牌。
  • 实现相对复杂。

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

五种限流策略

  1. 服务拒绝

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

可通过设计实现对指定域名、IP、客户端、应用、用户等不同来源的请求进行拒绝。

  1. 延时处理

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

  1. 请求分级(优先级)

对不同来源的请求设置优先级,先处理优先级更高的请求。如VIP客户、重要的业务应用(如交易服务优先级高于日志服务)。

  1. 动态限流

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

  1. 监控预警&动态扩容

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

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

三个限流位置

  1. 接入层限流

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

  1. 应用限流

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

  1. 基础服务限流

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

  • 数据库:限制数据库连接、限制读写速率
  • 消息队列:限制消费速率(消费量、消费线程)

总结

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

参考:http://www.studyofnet.com/555653372.html