目录

 

文章目录

 

Rate Limiting

Rate Limiting 实现了可根据特定时间窗口来限制对 Route、Service 或 Consumer 的调用次数。

  • 官方推荐的流控方案：https://konghq.com/blog/how-to-design-a-scalable-rate-limiting-algorithm/

关键参数：

  • name（必选）：插件名称。
  • config.second（必选其一）：每秒请求限制。
  • config.minute（必选其一）：每分钟请求限制。
  • config.hour（必选其一）：每小时请求限制。
  • config.day（必选其一）：每天请求限制。
  • config.month（必选其一）：每月请求限制。
  • config.year（必选其一）：每年请求限制。
  • config.limit_by（可选）：限制次数的衡量标准，枚举：Consumer、Credential、IP，默认是 Consumer。如果 Consumer 或 Credential 没有设置时，则根据 IP 来限制。
  • config.policy（可选）：限流累加器的计数策略，枚举：Local、Cluster 或 Redis，默认是 Cluster。
    • local：准确低，性能影响最小。
    • redis：准确，性能影响比 cluster 小。
    • cluster：准确，不需要依赖其他组件，但相对来说性能影响最大的，因为每个请求都会强制对底层的数据源进行读写操作。
  • config.fault_tolerant（必选）：当第三方数据源出错时，是否启用限流功能。默认是 true，表示禁用限流功能。

应用场景：

  • 事务粒度：不能选用 local 策略，应该在 cluster 或 redis 策略中考量，推荐是先尝试使用 cluster 策略，如果性能急速下降，则切换成 redis 策略。需要注意的是，指标数据无法从原有数据源切换到 redis，通常来说，短周期指标（如：秒、分）不受影响，长周期指标（月）可能会有影响，所以切换数据源时需要小心。

  • 后端保护模式：这种场景中因为准确性不太重要，可以使用 local 策略，这需要多些尝试才能找到合适的值，比如用户希望配置限流每秒 100 个请求，总共有 5 个 Kong 节点，设置 local 策略，每秒 30 个请求，大致可以满足需求，如果觉得返回的失败过于频繁，可以适当增大阈值。需要注意的是，当增加 Kong 节点时，会增加总请求数；同理减少 Kong 节点时，会降低总请求数，所以调整节点数时需要同步调整阈值。在 Kong 节点前使用 HASH 一致性负载均衡器可以避免上述的问题，因为它会保证相同的用户会路由到指定的 Kong 节点，保证数据准确，并且不受节点缩放的影响。通常情况下，真实的请求数会大于限流的阈值，但是它还是能有效的防止攻击，并且保持最佳性能。