4. Kong内置Response Rate Limiting插件：基于上游响应头的限流机制

Kong内置的Response Rate Limiting插件（插件名：response-ratelimiting）是一种被动式限流机制。与传统的Request Rate Limiting在请求到达时立即计数不同，Response Rate Limiting在上游服务返回响应后才根据响应头中的特定字段进行计数和限流。这种机制特别适用于需要根据业务语义或上游服务反馈来动态调整客户端访问频率的场景。

4.1 核心机制与工作原理

Response Rate Limiting插件的核心工作流程如下：

  1. 客户端请求到达Kong网关，Kong将请求转发给上游服务。
  2. 上游服务处理请求并返回响应，响应头中包含限流相关的标识（如、自定义Header值）。
  3. Kong解析响应头，提取限流实体标识（如用户ID、值）。
  4. Kong根据配置的限流策略（每秒/分钟/小时/天的请求次数）检查该实体是否超出配额。
  5. 如果超出配额，Kong返回429 Too Many Requests；否则正常放行并更新计数器。
关键区别： Request Rate Limiting在请求到达时立即计数，而Response Rate Limiting在响应返回后才计数。这意味着即使客户端发送了请求，如果上游返回的响应头中不包含限流标识，该请求也不会被计入限流配额。
Response Rate Limiting 工作流程 客户端 Kong 网关 上游服务 限流计数器 ① 请求 ② 转发请求 ③ 响应（含限流Header） ④ 解析Header并计数 ⑤ 检查配额 ⑥ 正常响应 / 429 说明： 限流计数器仅在响应头包含有效限流标识时更新。如果上游响应头中缺少限流字段，该请求不计入配额。

4.2 适用场景

Response Rate Limiting插件在以下场景中具有明显优势：

场景 说明 典型配置
按限流 上游服务在响应头中返回，Kong根据该Key值对每个客户端进行独立限流 limits: { : { minute: 100 } }
按自定义Header限流 根据响应头中的自定义字段（如X-User-Id、X-Tenant-Id）进行租户级或用户级限流 limits: { user_id: { hour: 1000 } }
按业务状态码限流 仅对返回特定业务状态码（如X-Biz-Code: ERROR）的请求进行限流计数 limits: { error_count: { minute: 10 } }
按响应延迟限流 根据响应头中的延迟信息（如X-Response-Time）对慢请求进行限流 limits: { slow_req: { minute: 50 } }
最佳实践： 当上游服务已经具备完善的业务限流逻辑（如按用户等级、按订阅套餐）时，使用Response Rate Limiting可以避免在Kong层重复实现复杂的业务规则，只需让上游在响应头中返回限流标识即可。

4.3 配置示例

4.3.1 基础配置：按限流

以下示例展示如何通过Kong Admin API为某个Service配置Response Rate Limiting插件，实现按每分钟最多100次请求的限流：

curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=response-ratelimiting" \
  --data "config.limits..minute=100" \
  --data "config.limits..hour=5000" \
  --data "config.header_name=X-" \
  --data "config.block_on_first_violation=true"

参数说明：

  • config.limits..minute=100：定义名为的限流实体，每分钟最多100次。
  • config.limits..hour=5000：同一实体每小时最多5000次。
  • config.header_name=X-：从响应头中提取限流标识的字段名。
  • config.block_on_first_violation=true：首次违反限流规则时立即返回429，而不是等待计数器同步。

4.3.2 进阶配置：按自定义Header限流

如果上游服务在响应头中返回X-Tenant-Id用于标识租户，可以按租户进行限流：

curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=response-ratelimiting" \
  --data "config.limits.tenant.minute=200" \
  --data "config.limits.tenant.day=10000" \
  --data "config.header_name=X-Tenant-Id" \
  --data "config.fault_tolerant=false"

参数说明：

  • config.limits.tenant.minute=200：每个租户每分钟最多200次请求。
  • config.limits.tenant.day=10000：每个租户每天最多10000次请求。
  • config.fault_tolerant=false：如果Redis或计数器发生故障，直接返回错误，而不是放行请求（生产环境建议设为true以保障可用性）。

4.3.3 多维度限流配置

可以同时配置多个限流维度，例如同时按和按租户ID限流：

curl -X POST http://localhost:8001/services/my-service/plugins \
  --data "name=response-ratelimiting" \
  --data "config.limits..minute=100" \
  --data "config.limits..hour=5000" \
  --data "config.limits.tenant.minute=200" \
  --data "config.limits.tenant.day=10000" \
  --data "config.header_name=X-" \
  --data "config.secondary_header_name=X-Tenant-Id"
注意： 多维度限流时，config.header_name为主限流字段，config.secondary_header_name为辅助限流字段。两个字段必须同时存在于响应头中，否则该请求不会被限流计数。

4.4 限流策略参数对比

参数 类型 默认值 说明
config.header_name string 无（必填） 从响应头中提取限流标识的主字段名
config.secondary_header_name string null 辅助限流字段名，用于多维度限流
config.limits.{entity}.second integer null 每秒允许的最大请求数
config.limits.{entity}.minute integer null 每分钟允许的最大请求数
config.limits.{entity}.hour integer null 每小时允许的最大请求数
config.limits.{entity}.day integer null 每天允许的最大请求数
config.block_on_first_violation boolean false 首次违反规则时立即阻塞，无需等待计数器同步
config.fault_tolerant boolean true 限流后端（如Redis）故障时是否放行请求
config.hide_client_headers boolean false 是否在响应中隐藏限流相关的Header（如X-RateLimit-Remaining）

4.5 常见故障排查

4.5.1 限流未生效

  • 检查响应头字段名： 确认上游服务返回的响应头字段名与config.header_name完全一致（区分大小写）。
  • 检查限流实体名称： 确认config.limits.{entity}中的实体名称与响应头中的值类型匹配（如响应头值为字符串，实体名称应为而非）。
  • 检查Redis连接： Response Rate Limiting依赖Redis存储计数器，确认Kong与Redis的连接正常。

4.5.2 误触发429

  • 检查多维度限流冲突： 如果同时配置了主字段和辅助字段，两个字段必须同时存在且有效，否则请求不会被计数，可能导致其他维度误判。
  • 检查计数器同步延迟： 在集群模式下，计数器同步可能存在毫秒级延迟，block_on_first_violation=true可以缓解此问题。

4.5.3 性能问题

  • 减少限流维度： 每增加一个限流维度，Kong需要多执行一次Redis查询，建议将限流维度控制在2个以内。
  • 使用本地计数器： 对于非关键场景，可以配置config.local_strategy=true使用本地内存计数器，减少Redis依赖，但会牺牲集群一致性。
限流维度与性能关系 1个限流维度 1次Redis查询/请求 2个限流维度 2次Redis查询/请求 3个限流维度 3次Redis查询/请求 性能影响分析： • 每增加1个限流维度，Kong需要额外执行1次Redis INCR/EXPIRE操作。 • 建议：生产环境限流维度 ≤ 2个；超过2个时考虑使用本地计数器或合并维度。 • 优化：使用 pipeline 批量操作可减少网络往返，但Kong内置插件暂不支持。

4.6 工程实践建议

  • 优先使用Request Rate Limiting： 如果限流逻辑不依赖上游响应内容，优先使用Request Rate Limiting，因为它更简单、性能更好。
  • 响应头字段标准化： 与上游团队约定统一的响应头字段命名规范（如X-RateLimit-Key、X-RateLimit-Tenant），避免大小写或命名不一致导致限流失效。
  • 监控与告警： 配置Prometheus监控Response Rate Limiting的429响应次数和Redis查询延迟，及时发现限流策略异常。
  • 灰度发布： 新限流策略先在测试环境验证，确认响应头字段和限流阈值正确后，再通过Kong的tags或routes逐步灰度到生产环境。
← 上一章 📖 返回目录 下一章 →