企业灰度发布 13：全链路灰度与流量泳道，怎样让版本身份穿过调用链
单服务灰度只回答“请求是否进入 A-v2”。在真实微服务里，A 还会调用 B、C 和消息系统。如果 A-v2 的新协议只被 B-v2 理解，却随机调用到 B-v1，入口的 5% 控制毫无意义；如果所有下游都固定调用 canary，又可能因为某个服务没有灰度版本而整条链失败。
全链路灰度的目标，是让一个被识别为灰度的请求尽量沿着 canary 版本传播，形成 Traffic Swimlane，同时对缺失版本、异步调用、后台任务和数据副作用定义明确的回落与隔离。
泳道需要一个可信的流量身份
入口可以根据内部账号、租户、Cookie 或实验分组生成 lane=gray 上下文。这个标记必须由可信 Gateway 写入：先删除外部同名 header，再根据认证结果生成；服务间调用传播，普通业务代码不能任意把 stable 请求升级为灰度。
标记还应包含 release/experiment id，而不是永远使用一个 gray=true。多个团队同时发布时，共用一个灰度标签会让 A 的测试流量误入 B 的另一次实验。标识需要作用域、TTL、签名或受信网络边界，并避免进入用户可见响应。
每一跳都要执行“优先灰度、允许回落”
路由策略通常是：带当前 lane 标识且目标存在匹配 canary endpoint 时，进入 canary；没有匹配 endpoint 时，按策略回到 stable。这样团队可以只发布调用链中的部分服务，不必先复制完整环境。
回落必须可观察。如果 B 没有 canary，A-v2→B-v1 可能是兼容设计，也可能掩盖漏部署。代理指标和 trace 要记录 intended lane、actual destination version 与 fallback reason。平台在 promotion 前检查是否存在不允许的回落，而不是只看入口命中率。
对于强耦合协议变更，可把某些依赖声明为 canary-required：缺失 B-v2 时请求直接失败或不允许开启入口流量。对于后向兼容依赖，则允许 stable fallback。这个选择来自上下文契约，不能由网络层猜测。
异步消息会切断 HTTP 上下文
请求写入消息系统后，header 不会自动随业务事件传播。事件 envelope 要显式携带 trace context 和受控 lane/release metadata；消费者根据策略选择 canary consumer group 或在同一 consumer 内分发。必须防止这些元数据成为永久业务字段，发布结束后历史消息仍可能在队列中。
Kafka 等系统不适合简单让两个 consumer group 同时处理同一正式副作用，否则会重复扣款。可使用独立灰度 topic、按 key 分区、路由层或只读 shadow consumer，具体取决于是否允许双处理。异步泳道比 HTTP 路由更需要领域设计。
数据隔离有三种等级
最轻是共享生产数据，canary 执行真实读写，适合完全后向兼容且低风险的改动；最接近真实，但副作用不可自动撤销。第二种是共享读、隔离写，把 canary 写入影子表或拦截外部动作，适合功能验证，但无法证明正式写链。第三种是独立数据环境，通过脱敏快照或事件复制构建，隔离最强，数据新鲜度和成本也最高。
平台应按业务能力选择，不应声称一种泳道适合所有服务。支付、通知、库存和推荐的副作用性质完全不同。每个 lane 模板需要声明允许的外部系统、写策略、数据清理和退出条件。
泳道数量会导致配置与容量爆炸
为每个分支复制整套微服务既昂贵又难治理。更可持续的模型是基线稳定环境 + 少数按需 canary workload，路由在存在灰度版本处“浮上泳道”，缺失时回落。平台限制同时活跃 lane 数、每条 lane 的 TTL 和资源配额，发布结束自动清理临时路由与工作负载。
还要防止路由规则组合爆炸。若每个服务都写一套 header match，规则难以审查。可用统一 Gateway API/Istio 生成器，根据服务目录和 release graph 生成有限规则，并在提交前计算会影响的代理与 host。
OpenKruise 的 End-to-End Canary 提供了什么
Kruise Rollouts 允许多个应用的 Rollout 共享 TrafficRouting，并通过 patchPodTemplateMetadata 给 canary Pod 标记，让服务发现或 Mesh 把灰度调用继续路由到下游 canary；下游不存在时可回到 stable。它把泳道作为正式发布策略，而不是一组散落的手写路由。
这不代表引入 Kruise 后问题全部消失。入口可信标识、异步消息、数据副作用、兼容声明和观测仍需要平台设计。控制器负责工作负载与路由协调，业务语义仍由领域团队负责。
全链路灰度的验收证据
| 证据 | 需要证明 |
|---|---|
| 入口身份 | 外部无法伪造，目标 cohort 稳定 |
| Trace | 每一跳 intended/actual version 可见 |
| 回落记录 | 缺失 canary 的位置与原因可查询 |
| 异步链路 | 消息元数据、消费版本和幂等正确 |
| 数据策略 | 正式写、影子写和外部副作用边界清楚 |
| 清理 | lane 到期后路由、Pod、数据和凭证可回收 |
下一篇收束整个系列：把 GitOps、发布控制器、Istio、Prometheus、策略、审批、审计和多集群协调组合成一套企业灰度发布平台，并给出分阶段建设顺序。