灰度 5% 流量占 20% 是重试放大了

现场是这样的。网关配了 5% 的灰度权重，监控里新版 QPS 却占 20%，成功请求比例正常，失败请求几乎全落在新版，用户侧感知到的错误率被放大。

中间走过弯路，把「网关按连接数而不是请求数分配」当成主因，改完现象没变。

排查方向其实有限，先把可能性排一排。重试请求没有带分桶标记，重新分流；新版失败后回退到旧版被重复计数；sidecar 层的重试又放大一倍。

先按 trace 统计两版真实请求数

python ratio.py --trace trace.jsonl --tag version --window 10m

接着让重试沿用第一次的分桶结果

upstream = pick_by_bucket(uid)  # 重试不重新抽签

再往下核对网关是连接级还是请求级权重

curl -s http://gateway:9090/stats | jq '.upstreams[] | {name:.name, rq:.rq}'

末了关掉 sidecar 重试后再看占比

kubectl patch deploy api -p '{"spec":{"template":{"metadata":{"annotations":{"traffic.sidecar.istio.io/excludeOutboundPorts":"8080"}}}}}'

怎么算真的好了，看的是同一批现象。新版请求占比稳定在 5% 到 6% 之间，失败请求按比例分布，不再集中在新版。

灰度比例要用请求数算，不能看连接数，重试一定要沿用分桶，否则一有失败比例就被放大。线上能稳定复现的问题都不算难，难的是只在大流量下才出现的那种。