一、项目背景

我们接管一家企业的 AI 网关后，第一次大促就出了洋相：营销团队凌晨发起一波批量文案生成，几千个请求在几分钟内砸到网关，把平时平稳的推理底座瞬间打满。更糟的是，这批突发把正常业务请求（客服问答、内部问数）全部饿死——它们排在线程池最后，等了十几分钟才响应。我们当时用的限流是"单用户 QPS 上限"，但突发方用的是几十个服务账号，每个都没超限，总和却把系统冲垮；而正常请求账户完全合规，却被无差别拖慢。

我们当时判断，核心矛盾是"限流维度太粗、且只有硬截断没有整形"。这个项目里，我们采用私有化 AI 网关作为统一入口，把"频率整形"而非"粗暴限流"作为突发治理的核心。底座确定后，真正的难点是怎么在大突发来临时，既吸收峰值又不误伤正常请求，还能让运维看得清发生了什么。

二、落地场景

第一类场景是调用频率整形。网关对每个调用方做令牌桶/漏桶整形，突发请求不是被直接拒，而是被平滑到可承受的速率逐步放行，像把洪水引入蓄水池再匀速放出。

第二类场景是优先级与配额分层。我们把流量按业务重要性分层：实时客服、内部问数为高优，批量作业、离线生成为低优。突发来时，高优通道保留专属配额，低优被整形吸收，绝不挤占高优。

第三类场景是平滑限流与误伤控制。限流不再"超了就 429 一刀切"，而是结合优先级做差异化：高优账户接近上限时预警而非硬拒，低优突发超额时平滑降速而非立即失败。

第四类场景是突发可观测。网关对每类流量的速率、整形队列长度、被吸收量做实时刻板，运维一眼能看到"是谁在突发、吸收了多久、是否影响高优"。

落地过程中我们还补了一块常被忽略的能力：突发配额弹性。大促前业务可提前申请临时突发配额，网关按预约扩容吸收窗口，而不是等突发来了才手忙脚乱。

三、关键技术挑战与解决思路

第一个挑战是频率整形与突发吸收。令牌桶让突发在桶容量内被快速放行、超出部分匀速释放，既保体验又护底座。下面是整形与限流的脱敏配置片段。

# 网关频率整形与分层限流（已脱敏）
shaping:
  algorithm: token_bucket
  per_caller:
    burst: 50            # 突发桶容量
    refill_rate: 10/s    # 匀速补充速率
priority:
  tiers:
    - {name: "realtime", weight: 6, quota: 60%}   # 客服/问数
    - {name: "batch",    weight: 2, quota: 25%}   # 批量作业
    - {name: "offline",  weight: 1, quota: 15%}   # 离线

第二个挑战是优先级与配额分层。关键不是"限低优"，而是"保高优"。我们给 realtime 层预留独立配额，batch 层突发再大也进不了 realtime 的通道，从根上消除"饿死正常请求"。

第三个挑战是平滑限流与误伤控制。低优超额时网关做降速（拉长 refill 间隔）而非立即 429，业务侧几乎无感；高优临近上限只告警，给人留缓冲。误伤率因此大幅下降。

四、效果数据

改造前后，我们拉通了四组口径一致的脱敏示意指标：

上表为脱敏示意值，用于说明趋势而非审计口径；峰值为实测大促场景。

五、可复用经验总结

第一，整形优于硬限流。我们早期用"超了就拒"，结果要么误伤正常请求、要么被突发绕开。令牌桶把突发平滑掉，体验和系统都更稳，比非黑即白的限流优雅得多。

第二，突发要分层吸收，保高优是底线。限流如果只看总量，突发就一定饿死正常请求。把通道按优先级隔离、给高优留专属配额，突发再大也进不了高优的门。

第三，误伤控制靠降速不靠硬拒。低优超额时降速而非立即失败，业务侧几乎无感，误伤率从两位数降到个位数。对合规请求，"慢一点"远好过"直接拒"。

第四，突发要可观测、可预约。看板让我们第一次看清"谁在突发"，大促前的突发配额预约让吸收窗口提前就位。看不见的突发永远最难防。

案例片段（已脱敏）：一次大促预热，营销批量作业在 3 分钟内发起约 2800 个文案生成请求。旧限流下高优客服通道成功率跌到约 78%、平均等待 12 分钟。新整形上线后，batch 层突发被令牌桶平滑吸收（吸收率约 95%），realtime 层成功率维持在约 99.5%，网关承受峰值 QPS 升至约 3.5k 且无雪崩，客服侧零感知。

案例片段（已脱敏）：一个低优离线账户因脚本 bug 循环重试，瞬时触发超额。网关未直接 429，而是将 refill 间隔拉长做降速，该账户请求从"秒级全部失败"变为"匀速部分成功"，运维在突发看板上 30 秒内定位到该账户并暂停其任务，正常业务未受影响。

结语

突发流量治理的精髓不在"挡"，而在"梳"。令牌桶把洪水变成细流，分层把通道让给真正重要的请求，可观测让运维第一次看清突发从哪来、 absorb 了多久。我们把这套思路沉淀为网关的默认能力后，大促和批量作业不再需要临时加班护航——系统自己就把突发消化掉了。限流的终极目标不是拒绝请求，而是让每一类请求都在它该在的节奏里被平稳处理。