1. 课程导论：云原生网关延迟诊断的挑战与多团队协作的痛点

在微服务架构全面云原生化后，API 网关（如 Envoy、Kong、APISIX）成为所有流量的统一入口。一次用户请求的端到端延迟，往往跨越网关、多个微服务、中间件与基础设施层。当延迟异常出现时，诊断工作不再是单个团队能独立完成的任务，而演变为一场跨团队、跨技术栈的“接力赛”。

1.1 云原生网关延迟诊断的核心挑战

传统单体应用下的“登录机器 → 查看日志 → 定位慢 SQL”三板斧，在云原生环境中已完全失效。网关延迟诊断面临以下四大结构性挑战：

1.2 多团队协作的典型痛点

在一次典型的网关延迟故障中，通常涉及以下四个角色，每个角色都有其独特的视角和盲区：

1. 网关团队（平台/SRE）： 掌握全局流量入口，能看到 P99 延迟飙升，但无法穿透到上游服务内部。
2. 业务团队（微服务开发者）： 掌握业务逻辑和数据库查询，但缺乏网关层的上下文（如 Header、路由规则）。
3. 基础设施团队（K8s/网络）： 掌握节点、网络、DNS 状态，但难以将基础设施抖动与具体业务请求关联。
4. 可观测性平台团队： 负责维护监控、日志、链路追踪系统，但往往不参与具体故障排查。

这种分工导致协作中频繁出现以下“断点”：

• 信息传递失真： 网关团队在 Slack 中截图一张 Grafana 面板，业务团队无法从中获取 Trace ID 或精确的请求参数。
• 上下文丢失： 故障交接时，口头描述“下午 3 点延迟很高”，但缺乏可复现的精确时间窗口和请求样本。
• 工具不互通： 网关团队使用火焰图分析 CPU 热点，业务团队使用 Jaeger 查看调用链，两者无法叠加分析。
• 责任边界模糊： 延迟在网关侧增加 200ms，但网关团队认为是上游服务慢，业务团队认为是网关限流，陷入“踢皮球”僵局。

1.3 延迟诊断的协作断层：从指标到根因

下图展示了从“发现延迟异常”到“定位根因”的完整路径中，多团队协作的典型断层位置：

1.4 课程目标：用“延迟火焰图”统一诊断语言

本课程的核心主张是：将“延迟火焰图”作为多团队协作的标准诊断工件。火焰图天然具备以下优势，使其成为跨团队沟通的理想媒介：

• 可视化直观： 一眼看出“宽栈”即瓶颈，无需深入阅读日志或指标曲线。
• 信息密度高： 一张火焰图可包含时间、调用栈、耗时占比、并发度等多维信息。
• 可交接性强： 火焰图是静态文件（SVG/HTML），可嵌入工单、文档、Slack，且支持交互式缩放。
• 语言无关： 无论团队使用 Go、Java、Python 还是 Rust，火焰图的呈现形式完全一致。