服务网格 25：503、连接重置与尾延迟如何定位
先问“哪一跳”，再问“是什么错误”
一个用户请求进入 frontend → orders 调用链（orders 先调用 inventory，成功后再调用 external-stub）。客户端的 503、连接重置或一次很慢的成功响应，分别只是客户端这一观察点的事实。DNS 解析、EndpointSlice、代理路由、上游连接、mTLS、授权、应用处理、回包和遥测管道都可能改变症状；控制台上的一张 503 截图无法确定故障发生在哪层。
先记录一个有唯一请求 ID 的正常样本，包括当前应用版本、带实际 endpoint 的 Service、所选代理的 route/cluster、双方代理访问日志、应用日志、客户端出口码与延迟。故障时先找第一个和正常样本不同的观察点：DNS 不通时不必先改 JWT；已有 endpoint 也不证明端口在监听；mTLS 握手失败不等同于授权 DENY；AuthorizationPolicy 被拒绝时也不该优先调整重试次数。每换一个诊断假设，都要说明它能解释哪条证据、还有哪条证据不能解释。
| 分层 | 需要的证据 | 不能代替的事实 |
|---|---|---|
| 服务发现 | DNS 查询、Service/EndpointSlice、Pod 就绪与实际端口 | 域名能解析不保证 endpoint 可用 |
| 代理配置 | Istio 资源状态、同步、当前 route/cluster/endpoint | API 接受规则不保证这次请求经过目标代理 |
| 连接与安全 | 出站/入站连接、证书身份、TLS/授权拒绝位置 | 只看 HTTP 状态分不清 TLS 与授权 |
| HTTP 与应用 | 两侧代理的 response flags/details、请求 ID、应用处理与副作用账本 | 应用返回 503 和代理生成 503 不等价 |
| 用户体验与遥测 | 客户端耗时、采样窗口、trace 父子关系与导出集合 | 无 trace 不证明无请求；目标服务 p99 不等于用户 p99 |
三份不公开故障标签的诊断卷宗
在隔离的实验集群只使用合成服务与数据。先保存相同输入下的正常调用，再由注入者独立准备三个场景，交给诊断者时隐藏故障标签，但保留真实的资源快照、请求和遥测；诊断者不得通过脚本名称猜答案。
卷宗 A：请求返回 503。 将库存测试 Service 指向没有应用监听的端口，但不删除 route，也不把应用改为主动返回 503。诊断者要证明代理本次使用的 cluster/endpoint 与目标端口是什么，找到连接失败证据，并核对库存应用没有处理该 ID；随后只修复端口并复测。若实际返回的并非 503，也应按真实代码记录，不为贴合标题而改写结果。另用应用级空候选上游分支做对照，比较相同状态码在代理和应用日志中的不同痕迹；这里“空候选上游”不是 Kubernetes 空 EndpointSlice。
卷宗 B：连接在上游处理中断。 当前累计应用没有确定性的“收到指定 ID 后立即断开 TCP”接口；实现时要在隔离测试桩中控制一次连接中断，明确使用的协议、断开时机及是否已经发送响应头。诊断者核对两侧代理的实际结束原因、重试次数、客户端收到的是 reset、503 还是其他错误，不能仅根据 connection reset 字样断定哪方主动断开。没有测试桩或握手/连接取证时，这一卷宗保留 NOT_RUN，不拿 Envoy 返回一个人为的 HTTP 503 冒充 TCP reset。
卷宗 C：慢而不是立刻失败。 使用已有 inventory 的 -quote-delay，选择比正常延迟明显更长、且有明确客户端及代理超时预算的参数。分别比较 frontend 客户端耗时、库存应用处理时间、上游尝试数、库存端的延迟分布与客户端最终状态。若客户端已经超时，库存仍可能继续处理；第 13 篇的进程实验仅说明过应用取消边界，不能替代理的真实 timeout 和重试记录。修复可以是找出慢依赖、调整合理预算或减少不必要尝试，但必须有同一输入条件下的复测。
| 卷宗 | 故障请求、配置/日志/指标/trace | 最小修复与相同条件复测 |
|---|---|---|
| A：503/连接失败及应用返回对照 | NOT_RUN：无 Kubernetes/Istio/Envoy | 待实测 |
| B：上游连接重置 | NOT_RUN：无确定性测试桩及代理 | 待实现与实测 |
| C：尾延迟 | NOT_RUN：无代理与采集端 | 待实测 |
验收不要求三种故障共享同一个状态码，反而要求诊断能排除至少一个似是而非的候选原因。导出原始请求、资源版本、代理当前配置、应用和代理同 ID 日志、查询窗口及修改前后证据；若观测后端没有部署，日志、指标、追踪三项不能填“通过”。本文只给出方法和待执行判据，没有做集群故障注入，也没有运行回滚。
练习与参考解答
- 库存 Service 有 EndpointSlice，客户端仍报 503，应马上重新创建 Pod 吗？参考解答：不应。先核对 endpoint 的就绪、实际监听端口、代理活跃 endpoint 与连接失败详情；盲目重建会抹掉现场，也不能区分错误端口与应用 503。
- 把库存延迟调高后请求失败，能用一条客户端 504 证明瓶颈在库存业务代码吗？参考解答：不能。要核对具体超时执行点、请求是否进入库存、代理是否重试、客户端 deadline 及应用处理时间；没有这些证据只能报告现象。
官方资料与系列导航
- Istio 调试 Envoy 配置 与 istioctl analyze：资源到实际代理的检查入口。
- Envoy response code details：区分上游连接与路由结束原因。
- Istio Security、标准指标 和 追踪概览：分别核对安全执行点、观测边界和传播缺口。
系列导航：24 自动追踪为什么仍会断链 → 25 503、连接重置与尾延迟如何定位（本文）→ 26 Ambient 数据面。
