服务网格 10：按版本和请求属性选择后端

“10% 给 v2”是路由意图，还是已发生的调用比例

同一服务链中的 inventory-v1、inventory-v2 返回各自版本标识；第 06 篇已拆开规则声明与代理执行。现在发布 v2：先让带 x-canary: yes 的合成请求稳定到 v2，再测试不带头时按权重选择 v1/v2。Subset 属于后端实例分类，匹配条件属于请求分类，权重属于某条 route 下的目标比例；三者不能写成一项配置。读者应能区分提交的权重、代理选择次数、后端处理次数与最终客户端成功次数。

先按请求头选择 canary 路由，再按权重选择 subset，由后端版本和请求标识核验

图的第一步是请求匹配：若顺序靠前的规则匹配 canary 头，就不再按照后续默认权重规则选择；否则才进入默认路由。v1/v2 subset 必须与实际工作负载的版本标签一致，而不是只看 Deployment 名或镜像 tag。

路由规则、端点与观测单位

在 Istio 风格的配置中，DestinationRule 可给 inventory 定义 v1/v2 标签集合，VirtualService 可按 URI/请求头选目标及配置权重。只有当请求的 host、端口、header 落在相应 VirtualService 作用域内，且目标 subset 有实际可用 endpoint，代理才可能按意图执行；对象都存在不等于当前代理路由已切换。检查第 06–07 篇的资源提交、控制器处理、代理活跃 route/cluster/endpoint，再检查访问日志与库存应用的相同请求 ID。

权重不是“每十个请求必有一个 v2”。如果用独立同分布的简化模型，令选 v2 概率为 0.1，发送 20 次请求，则期望 v2 为 2 次，标准差为 sqrt(20 × 0.1 × 0.9) ≈ 1.34，恰好 0 次的概率为 0.9^20 ≈ 0.122。这些数是理论示意，不是本仓库压测结果，也不是对 Envoy 的具体实现保证。连接复用、负载均衡策略、重试、统计窗口和多个代理各自的采样都会改变可观察的计数。若代理对一个用户请求重试两次，后端看到的尝试数可能超过外部请求数，不能用两种分母计算同一个“灰度百分比”。

优先用显式头路由核对机制，再在固定采样数量、连接复用方式和无重试的条件下检验权重近似值。客户端应为每个用户请求生成不同 ID；后端日志、代理 attempt 记录、响应版本和账本要保持关联，防止读请求与将来的扣减请求混作同一安全场景。代理的权重选择不能保护非幂等写入的业务语义。

对照实验与边界

在隔离集群创建同一 SKU 的 v1/v2 库存应用、版本标签及只作用于实验 namespace 的 DestinationRule/VirtualService。先保存未启用路由时的基线；再对带 x-canary: yes 和无头的请求分别留存输入、代理快照和实际后端日志；最后故意错写 v2 subset 标签，在负例中确认目标没有可用后端或配置未匹配，并让不符预期的断言返回非零。量化权重时同时公布分母、窗口、样本数与连接/重试参数，不把一次小样本偏差称为 Envoy 故障。

安全前置检查（examples/service-mesh/）：

1	`SM_CONTEXT=service-mesh-lab SM_NAMESPACE=service-mesh-lab bash scripts/check-02.sh`

本环境检查的 evidence/02/20261001T130351Z-2539112/ 显示 kubectl 缺失、退出 127；Envoy 固定版二进制也尚未成功下载。因此 subset/head/权重的真实配置和请求对照 NOT_RUN；上段概率仅是清楚标明前提的计算例子。此文不能作为 v2 已经发布或分流的证据，待验收清单在 writing-plans/service-mesh/research/10.md。

练习与参考解答

配置 10% 给 v2，20 次调用均到 v1，是否直接判断配置错误？参考解答：不能。按上述独立概率示意，0 次 v2 有约 12.2% 的概率；先核对实际规则、代理当前路由、样本是否经过该代理以及后端请求 ID，再增大样本量并固定连接和重试条件。真实代理算法与相关性还要单独检验。
保持请求头与权重不变，只把 v2 subset 标签改成 Pod 不具备的标签，会先在哪层暴露？参考解答：API 可能接受语法合法的规则，但对应代理的 cluster/endpoint 缺目标实例；也可能被特定实现提前诊断。必须保存对象状态、当前代理资源及带头请求的失败位置，不能猜一个固定 HTTP 码；若看到请求仍成功到 v2，应先查是否命中了另一条路由。