一、项目背景

我们每次底座升级前都想压一波真流量验证，但真压就怕压挂了影响线上用户。最早的办法是挑凌晨低峰手动跑脚本，结果覆盖面小、数据还不干净，因为压测流量和真实流量混在一起，抢同一份配额、记同一本账，最后压测发现的瓶颈都分不清是压测引的还是本来就有。有次压测把真实账单的计量也带偏了，财务来问为什么某应用半夜算力费用暴涨。我们意识到，不把压测流量和真实流量在网关层分开，压测数据根本不可信，还敢出事。这个项目也让我们把"压测即生产"的纪律立了起来，凡是进网关的流量都得讲清楚自己是干嘛的。

二、落地场景

我们在 AI 网关接入层做了流量染色：压测流量在入口打上特定标记，网关识别后路由到影子集群，配额和计量与真实流量完全隔离，结果只观测不回写业务。真实用户完全无感，影子集群挂了也不影响线上。压测覆盖到的接口、模型、路径都能在报告里看清楚，发现的瓶颈直接对应到具体实例。升级前跑一轮，心里才有底。染色标记还支持按批次区分，同一轮压测里不同场景打不同标，报告能拆开看，不会再混成一团。

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

染色透传一致性是第一个坑。压测流量经过多跳转发，标记在某层被丢了，到了网关认不出是压测，又混进真实池。我们改用请求头加网关侧强制重写双保险，任何一跳丢了入口还能补。影子集群资源隔离最怕偷懒共用，我们坚持影子集群独立部署、独立配额，绝不蹭真实集群的空闲算力，否则压测结果被真实负载干扰。计量不污染真实账单是红线，压测调用走独立计量通道，月底对账时和真实账单物理隔离。压测流量防逃逸则是出口也校验标记，防止影子集群误调了真实下游。还有个坑是染色标记长期不换会残留线上，我们给每轮压测标记带时间戳，过期自动失效，避免旧标记被误认成真实流量。

压测流量的规模控制也是个坑。初版没给影子集群设上限，一轮压测把影子集群的算力打满，反而影响了旁边共用基础设施的其他测试。我们后来给每轮压测标了最大并发和时长上限，超了自动停，既护住影子集群也不打扰别人。还有个细节：染色标记的校验要在入口和出口都做，入口染色、出口也要确认没被中间层篡改或丢失，否则影子集群可能误调真实下游，那可就不是污染账单这么简单了。隔离这种事，校验点宁可多不可少，漏一个就埋一颗雷。

案例片段（已脱敏）： 某次升级前压测，流量染色与路由隔离关键配置如下：traffic_shade:  mark_header: "X-Shadow: probe-2026"  route_to: shadow_cluster  quota_isolated: true  metering: shadow_only  writeback: false  egress_check: true该轮压测覆盖约七成核心接口，在影子集群发现某模型实例在并发八十路时 P99 延迟陡增三点五倍，真实账单零污染，问题在升级前修复未影响线上。

四、效果数据

压测覆盖率从原来挑接口的零散验证提升到约七成核心接口，升级前的盲区明显缩小。影子集群隔离故障数为零，压测期间真实业务零感知、零抖动。真实账单零污染，财务再没来问过半夜费用异常。压测发现的瓶颈能精准定位到具体实例和并发区间，某轮就抓到一个模型在八十路并发时延迟陡增三点五倍的问题，升级前修掉。带时间戳的标记上线后，再没出现过旧压测流量残留线上的情况，清理从手工变成自动。底座升级从"凭感觉"变成"压过才发"，发布信心明显提升。

染色隔离跑熟后，我们把它固化成了发布流程的一环：任何涉及底座或网关的大变更，先发一轮带时间戳的影子压测，过了才允许灰度。财务那边也松了口气，真实账单再也看不到半夜异常费用，对账工时省了一大块。我们后来给压测报告加了瓶颈热力图，哪个模型、哪个并发区间、哪项指标先到顶一目了然，研发照着图优化比看文字结论快。染色标记带时间戳这招还顺带解决了环境串扰：测试环境和生产环境的压测标记不同前缀，网关按前缀隔离，两拨人同时压也不互相污染。压测从临时救火动作变成了有纪律的工程实践，发布信心是实打实涨上来的。

五、可复用经验总结

压测流量必须染了色再进网关，这个项目用一次账单污染换来了铁律。不染色，它就和真实流量抢配额、混账单，数据全不可信。影子集群别蹭真实算力，隔离彻底才能压出真瓶颈，我们当初想省资源共用过一次，结果压测曲线被真实负载搅得一团糟。计量走独立通道是底线，别让压测碰真实账单，财务的信任比那点算力贵。那个旧标记残留的坑，让我们此后默认给染色带时间戳自动失效，清理机制不能靠人记。这套染色隔离现在是每次大升级的前置动作，但染色标记得定期换，别有残留。