2. API网关与限流：网关架构模式、令牌桶与漏桶算法、分布式限流实现

2.1 API网关架构模式

API网关是微服务架构的流量入口，承担路由、认证、限流、监控等核心职责。当前主流网关包括 Kong（基于 OpenResty/Nginx）和 APISIX（基于 Lua + etcd），两者均采用插件化架构，但设计理念存在差异。

2.2 网关请求处理流程

下图展示 API 网关在限流场景下的核心处理链路：

2.3 令牌桶算法与漏桶算法

限流算法的核心是控制请求速率，令牌桶和漏桶是两种最经典的实现方式，两者在突发处理能力上存在本质区别。

2.4 令牌桶算法工作原理

下图展示令牌桶算法的完整生命周期：

2.5 分布式限流实现方案

单机限流无法应对多实例场景，分布式限流需要中心化存储协调状态。以下是三种主流实现：

1. Redis + Lua 脚本：利用 Redis 单线程特性，通过 Lua 脚本原子执行令牌桶逻辑，保证并发安全。
2. Redis-Cell 模块：Redis 4.0+ 的限流模块，内置 GCRA（通用细胞速率算法），性能优于 Lua 脚本。
3. Sentinel 集群流控：阿里开源的限流组件，支持 Token Server 模式，适合 Java 生态。

2.6 Redis + Lua 分布式限流实现

以下是一个基于令牌桶算法的 Redis Lua 脚本，支持动态调整速率和容量：

-- 令牌桶限流脚本
-- KEYS[1]: 限流 key
-- ARGV[1]: 令牌生成速率（个/秒）
-- ARGV[2]: 桶容量
-- ARGV[3]: 当前请求消耗令牌数（通常为1）
-- 返回值: 0=拒绝, 1=放行

local key = KEYS[1]
local rate = tonumber(ARGV[1])
local capacity = tonumber(ARGV[2])
local requested = tonumber(ARGV[3]) or 1

-- 获取当前桶状态
local token_info = redis.call('HMGET', key, 'tokens', 'last_refresh')
local tokens = tonumber(token_info[1]) or capacity
local last_refresh = tonumber(token_info[2]) or 0

-- 计算时间差，补充令牌
local now = redis.call('TIME')[1]
local elapsed = math.max(0, now - last_refresh)
local new_tokens = math.min(capacity, tokens + elapsed * rate)

-- 判断是否放行
if new_tokens >= requested then
    new_tokens = new_tokens - requested
    redis.call('HMSET', key, 'tokens', new_tokens, 'last_refresh', now)
    redis.call('EXPIRE', key, 10)  -- 设置过期时间，避免内存泄漏
    return 1
else
    -- 令牌不足，更新刷新时间但不扣减
    redis.call('HMSET', key, 'tokens', new_tokens, 'last_refresh', now)
    return 0
end

2.7 网关限流配置实战

以 APISIX 为例，通过 Admin API 配置基于令牌桶的限流插件：

# 创建路由并绑定限流插件
curl http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' \
  -X PUT -d '
{
  "uri": "/api/v1/orders",
  "plugins": {
    "limit-req": {
      "rate": 10,           -- 每秒请求速率
      "burst": 20,          -- 突发容量
      "rejected_code": 429, -- 拒绝状态码
      "key": "remote_addr"  -- 限流维度：客户端IP
    }
  },
  "upstream": {
    "type": "roundrobin",
    "nodes": {
      "192.168.1.100:8080": 1
    }
  }
}'

2.8 限流治理最佳实践

• 分层限流：网关层（全局 QPS）→ 服务层（业务限流）→ 资源层（DB 连接池），避免单点瓶颈。
• 动态配置：限流参数应支持运行时调整，APISIX 的 etcd watch 机制可实现秒级生效。
• 监控告警：记录限流触发次数、拒绝率、令牌桶水位，当拒绝率 > 5% 时触发扩容或降级。
• 降级策略：限流后返回友好提示（如 429 + Retry-After 头），避免客户端无限制重试。
• 压测验证：使用 wrk 或 Locust 模拟突发流量，验证限流曲线是否符合预期。