影子流量是将线上真实请求镜像至新模型服务以验证其线上行为，避免盲部署；需用守护线程异步发送、禁用重试、白名单头、结构化日志、丢弃响应体。
影子流量是什么，为什么模型服务需要它
影子流量不是复制请求再发一遍，而是把线上真实请求「镜像」到新模型服务，不改变主链路行为。模型上线前怕效果倒退、特征对齐出错、甚至 JSON 解析失败，靠离线测试很难覆盖所有边界 case —— 这时候影子流量是唯一能验证“它在线上到底 behaves 怎么样”的手段。
关键判断：如果你的模型服务没有影子流量能力，就等于在生产环境 blind deploy。
用 requests + threading 做轻量影子请求容易崩
常见错误现象：ConnectionRefusedError、影子请求拖慢主链路、上游超时陡增。原因很简单：主线程等 requests.post() 返回才继续，哪怕加了 timeout=(0.1, 0.1)，DNS 解析、TCP 握手失败仍会卡住主线程。
正确做法是彻底剥离影子路径：
立即学习“Python免费学习笔记（深入）”；
- 用
threading.Thread(target=send_shadow, args=(payload,))启动后立即daemon=True，避免阻塞主流程退出 - 影子请求函数内必须包住所有异常：
try...except Exception:，绝不让任何错误冒泡 - 禁用重试：
session.mount('http://', HTTPAdapter(max_retries=0))，否则一个挂掉的影子服务会让线程反复夯住 - 别传原始
request.headers全量 —— 某些 header（如X-Real-IP、Authorization）可能触发鉴权或限流，改用白名单：{k: v for k, v in headers.items() if k.lower() in ['content-type', 'x-request-id']}
Starlette / FastAPI 中怎么安全注入影子逻辑
不能在路由函数里写 if shadow_mode: send_to_new_model() —— 这会让主服务响应时间直接受影子服务 RT 影响，且无法做采样控制。
推荐方案是中间件 + 异步任务队列：
- 中间件中用
request.state.shadow_ratio = 0.05控制采样率，比硬编码random.random() 更易配置热更新 - 影子 payload 构建完后丢进
asyncio.create_task()，而非await，确保不阻塞当前 response - 务必设置
asyncio.wait_for(task, timeout=0.3)，超时直接 cancel，防止 asyncio event loop 被长尾请求拖垮 - 不要复用主服务的
httpx.AsyncClient实例 —— 影子请求失败不应影响主 client 的连接池，单独初始化带独立 timeout 和 pool limits 的 client
影子流量日志和可观测性怎么不拖垮性能
常见坑：每条影子请求都打 logger.info(f"shadow sent to {url} with {payload}")，QPS 上千时磁盘 I/O 直接打满，甚至引发 BlockingIOError。
实操建议：
- 只记录失败影子请求：
if response.status_code >= 400:再 log，且 log 级别设为WARNING - 用结构化日志（如
structlog），字段固定为event="shadow_fail",status_code,upstream_url，方便 ELK 提取 - 禁止在影子逻辑里调用
json.dumps(payload)—— 大 request body 序列化开销高，改用len(payload)或哈希摘要（如hashlib.md5(payload[:128]).hexdigest()）代替原始体 - 影子服务地址写死在配置里，别从环境变量拼接 URL —— 每次字符串格式化都是额外 CPU 开销
最常被忽略的一点：影子请求的 response body 一定 discard 掉，别调用 response.text() 或 response.json() —— 你根本不需要它，读取 body 会触发完整 buffer 分配和解析，纯属浪费。
