4. Shadow部署架构设计

Shadow部署的核心目标，是让新模型在不影响生产交易的前提下，接收与生产环境同源的真实请求，完成推理并输出结果，但不将结果返回给业务方。因此，架构设计的关键不是“让模型跑起来”，而是构建一条可复制、可隔离、可观测、可回滚的旁路链路。本节围绕数据流、请求复制、旁路评估、日志采集与监控体系五个部分展开。

一、核心原理：Shadow链路与生产链路的关系

生产链路是“请求→网关→生产模型→响应→业务”。Shadow链路则是在网关或服务网格层将请求复制一份，异步发送到Shadow服务，Shadow服务调用新模型完成推理，结果写入日志与评估库，不参与真实响应。两条链路共享输入，但输出完全隔离。

这种设计带来三个约束：第一，Shadow链路必须异步非阻塞，不能拖慢生产请求；第二，Shadow服务需要独立资源池，避免与生产模型争抢GPU或内存；第三，所有Shadow请求必须可标识、可采样、可关闭，便于灰度与熔断。

二、请求复制：在哪里复制、复制什么、复制多少

请求复制通常有三个位置：网关层、服务网格Sidecar、应用内埋点。网关层复制最通用，适合HTTP/RPC接口；Sidecar复制对业务代码零侵入，但需要服务网格支持；应用内埋点最灵活，可精确控制字段，但改造成本高。

复制内容需要遵循“最小必要”原则：请求ID、用户标识、输入特征、时间戳、渠道来源必须保留；敏感字段如身份证、银行卡号需脱敏或哈希。复制比例建议从1%开始，逐步提升到10%、50%，最终全量。复制策略可用如下配置表达：

shadow:
  enabled: true
  sample_rate: 0.05          # 5%采样
  async: true                # 异步非阻塞
  timeout_ms: 800            # Shadow超时，不影响生产
  max_concurrency: 200       # 最大并发，防止打爆
  exclude_paths:
    - /health
    - /metrics
  mask_fields:
    - id_card
    - bank_card
    - phone

三、旁路评估：如何判断新模型是否更优

Shadow部署的价值在于“用真实流量做离线评估”。评估体系需要同时关注效果指标与工程指标。效果指标包括准确率、AUC、KS、召回率、排序一致性；工程指标包括P99延迟、错误率、GPU利用率、显存占用。两者必须同时达标，才能进入下一阶段。

四、日志采集与监控体系搭建

Shadow日志必须包含请求侧与响应侧两部分，并通过Trace ID关联。推荐结构如下：

{
  "trace_id": "a1b2c3d4",
  "request_id": "req_889900",
  "model_version": "v2.3.1",
  "input_hash": "f3a9...",
  "prod_output": {"score": 0.82, "rank": 3},
  "shadow_output": {"score": 0.85, "rank": 2},
  "latency_ms": 46,
  "status": "success",
  "timestamp": "2025-04-12T10:23:45Z"
}

日志采集链路建议采用“应用→Kafka→Flink→数据湖/评估库”的异步管道，避免直接写数据库造成瓶颈。监控体系则分为三层：基础设施层（CPU/GPU/内存）、服务层（QPS/延迟/错误率）、业务层（一致率/漂移/覆盖率）。告警规则应设置“Shadow链路异常不影响生产”的隔离策略。

五、复盘：一个典型的Shadow部署失败案例

某团队在网关层开启100%请求复制，但未设置异步与超时，导致生产请求P99从80ms升至420ms。复盘发现三个问题：第一，复制逻辑同步等待Shadow响应；第二，Shadow服务与生产模型共享GPU，资源争抢；第三，日志直接写MySQL，写入放大。修正方案是：改为Kafka异步复制、Shadow独立GPU节点、日志写入ClickHouse，并将采样率降至5%。修正后生产P99恢复至85ms，Shadow评估正常进行。

因此，Shadow部署架构设计的本质是隔离与可观测：隔离资源、隔离链路、隔离故障；可观测请求、可观测输出、可观测指标。只有把数据流、请求复制、旁路评估、日志采集与监控体系五部分串成闭环，Shadow部署才能真正成为模型上线的安全试验场。