1 项目背景
业务场景
客服工单分类服务上线第三个月，随着业务扩展，日均工单量从 8000 涨到 3 万，高峰期 QPS 突破 50。第 14 章搭建的简单 FastAPI 服务开始暴露出问题：
某个周一早上，大量用户集中提交工单（早高峰效应），瞬间 QPS 冲到 80。FastAPI 单 worker 同步推理模式下，请求开始排队——第 50 个请求要等前面 49 个都处理完才轮到自己，等待时间超过 3 秒。部分请求超时返回 504，客服系统把这批工单标记为"系统错误"，转给了人工——结果早高峰 8 个客服面对了平时 3 倍的工单量。
更糟糕的是，同一个 IP 在 1 秒内提交了 200 条工单——经查是测试脚本失控。这 200 条请求挤爆了推理队列，正常用户的请求被延迟到 5 秒以上。
运维团队紧急扩容了 GPU 实例，但新实例从冷启动到模型加载完成需要 15 秒——这 15 秒内所有请求都失败了。
痛点
简单 API 到生产级推理服务，中间需要补齐三个工程能力：
- 请求队列与流量整形：突发流量不能直接打到模型上，需要排队缓冲 + 削峰填谷
- 限流与熔断：保护后端模型不被打垮，防止某个用户的异常行为影响全体
- 优雅启动与健康检查：新实例就绪前自动切流量，就绪后无缝接入
请求 → 限流检查 → 请求队列 → 动态Batching → 模型推理
