Kong网关限流实战：微服务架构下的流量控制

1. 项目背景与架构演进

在微服务架构中，API网关作为流量入口承担着至关重要的角色。我们原有的架构采用Nginx作为反向代理，将请求转发到HZero Gateway（基于Spring Cloud Gateway），再由内部网关路由到具体服务。这种架构在初期运行良好，但随着业务量增长，暴露出几个明显问题：

1. 限流能力薄弱：HZero Gateway自带的限流功能较为基础，无法实现细粒度的控制
2. 缺乏全局视角：难以对全站流量进行统一管控
3. 运维复杂度高：配置分散在各个服务中

引入Kong网关后，架构演变为三层结构：

code复制用户 → Nginx → Kong (8000/8443) → HZero Gateway (8080) → 内部服务

这种设计带来三个核心优势：

• 流量管控前置：在最外层实现限流、熔断等保护措施
• 策略集中管理：所有API策略通过Kong Admin API统一配置
• 能力扩展性强：可灵活添加认证、日志、监控等插件

实际部署中发现一个关键细节：Docker的iptables配置会影响容器间通信。如果未启用iptables，Kong容器将无法访问外部HZero Gateway的8080端口，这会导致所有请求失败。建议在部署前执行sudo modprobe ip_tables确保网络功能正常。

2. Kong限流方案深度解析

2.1 基础限流配置原理

Kong的限流插件(rate-limiting)基于令牌桶算法实现，其核心参数包括：

• second：每秒生成的令牌数（突发流量控制）
• minute：每分钟生成的令牌数（持续流量控制）
• policy：计数存储策略，支持local和redis两种模式

令牌桶的工作机制类似于地铁进站口：

• 令牌发放员以固定速率向桶中放入令牌（如每秒1个）
• 每个请求需要消耗1个令牌才能通过
• 当桶空时，新请求会被拒绝（返回429状态码）

这种设计既能防止突发流量压垮系统，又能保证持续流量的平稳处理。

2.2 两种典型配置方案

方案一：基础全局限流

bash复制curl -X POST http://localhost:8001/plugins/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting",
    "config": {
      "minute": 60,
      "second": 1,
      "policy": "local",
      "hide_client_headers": false
    }
  }'

这种配置适合中小型系统，特点包括：

• 使用本地内存存储计数（policy=local）
• 全局生效，不区分用户或接口
• 响应头会返回剩余次数信息

方案二：基于客户端的高级限流（推荐生产环境使用）

bash复制curl -X POST http://localhost:8001/plugins/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting",
    "config": {
      "minute": 60,
      "second": 1,
      "policy": "redis",
      "redis_host": "192.168.0.95",
      "redis_port": 6379,
      "redis_database": 2,
      "hide_client_headers": false
    },
    "consumer": false
  }'

这种方案的进阶特性：

1. 使用Redis集群存储计数，支持多Kong节点协同工作
2. 可通过consumer参数实现用户级限流
3. 数据库隔离（redis_database=2）避免与其他业务冲突

在压力测试中发现，当QPS超过500时，local策略会导致Kong内存占用飙升，而redis策略内存增长平稳。建议生产环境务必使用redis策略。

3. 特殊路由的限流排除策略

3.1 需要豁免限流的服务

在HZero体系中，以下三类接口必须排除限流：

1. 认证服务（/oauth）：登录接口被限流会导致所有用户无法认证
2. 服务注册中心（/register）：影响服务心跳检测
3. 健康检查接口（/actuator/health）：影响监控系统运行

3.2 配置示例：豁免OAuth认证

bash复制# 创建专属路由
curl -X POST http://localhost:8001/services/hzero-gateway/routes/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "hzero-oauth-no-limit",
    "paths": ["/oauth"],
    "strip_path": false,
    "preserve_host": true,
    "regex_priority": 10  # 更高优先级确保优先匹配
  }'

# 设置超高限流阈值（等效无限制）
curl -X POST http://localhost:8001/plugins/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting",
    "route": {"name": "hzero-oauth-no-limit"},
    "config": {
      "minute": 999999,
      "hour": 9999999,
      "day": 99999999,
      "policy": "local"
    }
  }'

关键配置技巧：

• regex_priority设为较高值（如10），确保优先匹配特殊路由
• 路径匹配使用精确前缀（如"/oauth"而非"/"）
• 虽然设置了大数值限流，但更好的做法是直接不挂载限流插件

4. 完整部署实操手册

4.1 服务与路由基础配置

bash复制# 创建指向HZero Gateway的服务
curl -X POST http://localhost:8001/services/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "hzero-backend",
    "url": "http://192.168.0.128:8080",
    "read_timeout": 60000,  # 超时时间设为60秒
    "write_timeout": 60000,
    "connect_timeout": 60000
  }'

# 创建全路径路由
curl -X POST http://localhost:8001/services/hzero-backend/routes/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "hzero-api",
    "paths": ["/"],
    "strip_path": false,
    "preserve_host": true
  }'

4.2 限流插件进阶配置

bash复制curl -X POST http://localhost:8001/plugins/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting",
    "service": {"name": "hzero-backend"},
    "config": {
      "minute": 60,
      "second": 1,
      "hour": 1000,  # 增加小时级控制
      "policy": "redis",
      "redis_host": "192.168.0.95",
      "redis_port": 6379,
      "redis_timeout": 2000,  # 增加Redis超时设置
      "redis_database": 2,
      "fault_tolerant": true,  # Redis故障时仍允许请求
      "hide_client_headers": false
    }
  }'

4.3 CORS跨域支持

bash复制curl -X POST http://localhost:8001/plugins/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "cors",
    "config": {
      "origins": ["https://example.com"],  # 建议替换为实际域名
      "methods": ["GET", "POST", "PUT", "DELETE", "PATCH", "OPTIONS"],
      "headers": ["Authorization", "Content-Type", "Accept"],
      "exposed_headers": ["X-Total-Count", "X-Page-Number"],
      "credentials": true,
      "max_age": 3600
    }
  }'

5. 生产环境调优建议

5.1 参数优化对照表

5.2 监控与告警配置

建议通过Prometheus监控以下指标：

1. kong_http_status：按状态码统计请求量
2. kong_latency_bucket：请求延迟分布
3. redis_connected_clients：Redis连接数

关键告警规则：

• 429状态码持续5分钟>100次/分钟
• 平均延迟>500ms持续10分钟
• Redis连接数>最大值的80%

6. 疑难问题排查指南

6.1 限流不生效检查清单

1. 确认插件已正确挂载到服务/路由

   bash复制curl http://localhost:8001/services/hzero-backend/plugins
   

2. 检查Redis连通性

   bash复制docker exec -it kong redis-cli -h 192.168.0.95 -p 6379 -n 2 ping
   

3. 验证路由匹配优先级

   bash复制curl http://localhost:8001/routes | jq '.data[].priority'
   

6.2 性能问题优化

现象：高并发时Kong CPU使用率高
解决方案：

1. 启用Kong的集群模式

   yaml复制# kong.conf
   cluster_listen = 0.0.0.0:7946
   

2. 调整worker进程数

   yaml复制nginx_worker_processes = auto
   

3. 开启缓存

   yaml复制db_cache_ttl = 3600
   db_cache_warmup_entities = services,routes
   

7. 部署方案选型建议

7.1 Docker Compose vs Kubernetes

对于不同规模系统的部署建议：

7.2 Docker Compose参考配置

yaml复制version: '3.8'
services:
  kong:
    image: kong:3.4
    environment:
      KONG_DATABASE: "off"
      KONG_DECLARATIVE_CONFIG: /usr/local/kong/kong.yml
      KONG_PROXY_LISTEN: 0.0.0.0:8000
      KONG_ADMIN_LISTEN: 0.0.0.0:8001
      KONG_NGINX_WORKER_PROCESSES: "4"  # 根据CPU核心数调整
    ports:
      - "8000:8000"
      - "8001:8001"
    volumes:
      - ./kong.yml:/usr/local/kong/kong.yml
    healthcheck:
      test: ["CMD", "kong", "health"]
      interval: 10s
      timeout: 10s
      retries: 3

8. 扩展应用场景

8.1 多租户限流策略

对于SaaS系统，可以实现租户级限流：

bash复制curl -X POST http://localhost:8001/plugins/ \
  -H "Content-Type: application/json" \
  -d '{
    "name": "rate-limiting",
    "config": {
      "minute": 60,
      "second": 1,
      "policy": "redis",
      "limit_by": "header",  # 根据Header区分租户
      "header_name": "X-Tenant-ID"
    }
  }'

8.2 动态限流调整

结合Prometheus指标实现自动扩缩容：

1. 创建定时任务查询QPS
2. 当QPS超过阈值时调用Kong Admin API调整参数

   bash复制curl -X PATCH http://localhost:8001/plugins/{plugin-id} \
     -d "config.minute=600"
   

经过实际验证，这套方案在日均百万PV的HZero系统中稳定运行，有效拦截了恶意刷接口行为，同时保障了核心业务的流畅运行。建议初次部署时先从宽松的限流策略开始，逐步收紧至最优值。