服务网格 34：发布 v2 后怎样定位慢依赖和错误身份并回滚

发布后出现 503、慢请求和错误身份，先回滚哪一层

把一次变更拆成三条可独立恢复的链：inventory-v2 新 Pod/Service 的工作负载变更、指向 v2 的请求路由变更、保护 orders → inventory 的身份与授权变更。在同一合成业务输入上只看客户端 503，不能知道错误从入口网关、Envoy 无端点、上游连接、授权拒绝还是库存应用产生；必须把客户端退出码、代理响应详情与应用端日志按同一请求 ID 对齐。

先通过请求 ID 分层确定故障，再按发布配置/工作负载/安全策略分别回退，每次重测客户端与账本

设正常 loadgen → frontend → orders → inventory-v1，orders 还要调用 external-stub；发布新增 inventory-v2 并只将带 x-canary: yes 的少量合成请求送到 v2，最后再扩大权重。预置两个故障：库存 v2 的一个依赖人为变慢，与来自非预期 ServiceAccount 的写请求。慢与拒绝是不同故障，分别采集请求 ID、代理 response flags/details、路由/endpoint 当前配置、授权策略及后端日志。可加“提交账本后延迟响应”的受控负例，确认客户端超时不等于副作用未发生，也不把回滚配置当作撤销已写入的账本。

每个阶段保存五种证据

阶段	资源与控制器	代理状态	请求/应用实证	回退门禁
v1 基线	Service、EndpointSlice、身份策略	正常 route/cluster/endpoint	相同 SKU 的版本与外部 stub	客户端与账本正常
v2 小流量	版本标签、subset 或 HTTPRoute 附着	实际路由/活跃端点	带头命中 v2、无头仍按预期	不越过错误率与副作用门禁
慢依赖/错误身份	仅隔离故障开关及实验 ServiceAccount	代理超时/授权拒绝位置	客户端退出码、应用是否收到及账本	失败断言非零且归因正确
回滚	恢复路由/工作负载/策略各自版本	目标配置已变更并生效	重新发唯一请求 ID、确认版本/拒绝恢复	长连接/重试/账本对照无回归

路由回退最快改变的是新的路由选择，已在途请求和旧连接还需单列观察；回退应用镜像涉及 Pod 就绪/端点变化；策略回退可能重新放行或误拒错误身份，需要同一负例重新执行。多层重试可能使 v2 背后仍收到重发，计数分母按逻辑请求/上游尝试/应用账本分别给出。若退到 v1 后账本已经有两条相同操作 ID，不能因为客户端后续读 200 就把状态写成“完全恢复”，应提出应用补偿/去重缺口。

仅针对合成服务的复跑

先从 examples/service-mesh/ 只读检查目标 context：

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

有隔离集群及版本兼容配置后，才在固定的 frontend/orders/inventory-v1/v2/external-stub 镜像上部署业务并冻结输入。按无网格→sidecar 基线→v2 canary→慢依赖/错误身份→分别回滚流量、策略和部署的顺序，给每个阶段独立的合成请求 ID 和操作 ID。正常路径断言 v1/v2 版本正确、库存与外部依赖均有对应日志；失败路径断言错误身份被拒且账本不增加、慢依赖达到预期客户端结果、意外成功或重复写入使检查非零。每步留环境、代码/配置版本、完整命令/退出码、资源条件、控制面状态、代理当前配置与后端结果；不要仅上传官方示例输出。所有流量故障仅针对实验 context，不连接生产，不清理其他集群。

尚未进行 canary、错误身份/慢依赖注入或真实回滚，整项网格发布实验 NOT_RUN。run-01.sh 的进程账本只证明响应丢失会重复副作用，不是本篇综合发布验收。

把灰度、慢依赖和授权放到同一次发布

本章采用独立 kind-service-mesh-sidecar 集群，避免 ambient HTTPRoute 与 VirtualService 混在一次实验。mainline/34/release.yaml 的 DestinationRule 定义 v1/v2 subset，VirtualService 让 x-canary: yes 进入 v2 且超时 200ms，默认请求进入 v1。第 26 篇的 STRICT 与 orders 主体 ALLOW 保持认证边界。

1
2
3

SM_CONTEXT=kind-service-mesh-sidecar bash mainline/26/run.sh apply
SM_CONTEXT=kind-service-mesh-sidecar bash mainline/34/run.sh apply
SM_CONTEXT=kind-service-mesh-sidecar bash mainline/34/run.sh capture

先记录两个正常响应体版本，以及 wrong-probe 的拒绝。请求 ID 不能只在客户端保存，库存应用日志也应出现允许请求；若服务根本没到达，先查路由和连接，再分析应用响应。发布快照包括 Deployment revision、路由资源、代理活动配置和证书元数据，便于回退后比较。

1
2
3

kubectl --context kind-service-mesh-sidecar -n service-mesh-lab exec mesh-probe -c curl -- curl -sv -H 'x-request-id: release-base' 'http://inventory:8080/quote?sku=paper'
kubectl --context kind-service-mesh-sidecar -n service-mesh-lab exec mesh-probe -c curl -- curl -sv -H 'x-canary: yes' -H 'x-request-id: release-canary' 'http://inventory:8080/quote?sku=paper'
SM_CONTEXT=kind-service-mesh-sidecar bash mainline/34/run.sh slow

slow 把 v2 的 -quote-delay 设为 500ms，超过 canary 路由预算。再次请求时普通 v1 应继续成功，canary 应超时；预期常见响应为 504，但最终归因以 Envoy response details、upstream 时间与应用同 ID 为准。负载均衡错误、没有端点、mTLS 握手失败和应用返回 500 都可能与“新版本不好用”同时出现，不能仅看客户端状态就统一叫慢依赖。

诊断顺序按信息增益安排：先确认带 header 的请求确实选中 v2，再检查 v2 Ready 和端点，再读代理超时详情，最后查应用延迟。若没有选中 v2，先修流量配置，不要调整应用线程池；若出现身份拒绝，则检查主体与策略，不要把超时调大掩盖另一类故障。

1
2
3

istioctl --context kind-service-mesh-sidecar proxy-config routes pod/mesh-probe -n service-mesh-lab
kubectl --context kind-service-mesh-sidecar -n service-mesh-lab logs deployment/inventory-v2 -c app --since=5m
SM_CONTEXT=kind-service-mesh-sidecar bash mainline/34/run.sh rollback

回退先把 canary 路由目的改回 v1，缩短继续进入故障版本的窗口；再 rollout undo 恢复 v2 上一 Deployment。路由切换和工作负载回退都不是瞬时事务，恢复判据是新请求稳定返回 v1、错误主体仍被拒绝、v2 新 Pod 的参数恢复且没有新增超时。回退不是简单删除 VirtualService，删除后默认均衡反而可能再次命中 v2。

1
2
3

SM_CONTEXT=kind-service-mesh-sidecar bash mainline/34/run.sh capture
SM_CONTEXT=kind-service-mesh-sidecar bash mainline/34/run.sh cleanup
SM_CONTEXT=kind-service-mesh-sidecar bash mainline/26/run.sh cleanup

清理先在流量已恢复后删除实验路由和探针；生产系统应恢复原配置快照而不是清空策略。当前发布与故障恢复为 NOT_RUN。原则是为每种故障保留可区分的证据，并把“停止扩大影响”和“恢复原版本”设计成两步。Istio 1.27 路由生成源码与累计应用参数共同限定本例行为。

练习与参考解答

v2 发布后出现 503，运营截图显示代理 xDS ACK，可认定策略成功下发且故障在应用吗？参考解答：不能。ACK 不是当前 route/endpoint 必定有效，也不证明请求通过；按同一请求 ID 核对对应代理 active route/cluster/endpoint、response flags/details、连接与身份记录及库存应用是否收到，再决定回滚哪个层次。
回滚 v2 权重为 0 后，新请求都命中 v1，但账本仍多出两条相同操作 ID。如何改验收结论？参考解答：路由选择已回退，业务副作用没有撤销，不能宣布完全恢复。比对客户端与后端 attempts 和 operation ID，停止重试/写入扩大，按应用幂等或补偿规则处理两条记录；以后再用正确/错误身份与长连接负例验证回滚不会旁路策略。