慢调用排查实录：高效定界服务网格 Sidecar 性能瓶颈

某车企在测试新业务时，发现某测试集群（A-Test-Cluster）的请求响应时间异常，而业务 POD 内部响应正常，初步排除业务逻辑问题后，故障被定位为网络层面性能瓶颈。本次案例揭示了复杂异构测试环境中的两大挑战：底层架构的“黑盒化”导致根因难以识别，以及架构的多样性（如服务网格和定制化代理）加剧了问题排查的复杂性。通过引入 DeepFlow 的全栈可观测性能力，利用 eBPF 技术追踪请求全生命周期，结合拓扑分析、调用日志和持续剖析，精准定位问题源头为 Sidecar 代理在处理 304 响应时的阻塞缺陷。经过研发团队修复，问题得以解决。本案例展示了 DeepFlow 在复杂环境中快速定界故障的强大能力，其中立、全面的观测数据和跨层级的追踪能力显著提升了性能问题的定位与解决效率，为异构架构下的故障排查提供了可靠支持。

01｜背景介绍

某车企上线了新业务，但在测试过程中发现，同样的请求在不同场景下的响应时间存在显著差异。进一步分析后发现，只有某个测试集群（A-Test-Cluster）的业务 POD 响应时间较长，而其 POD 内部的访问响应时延却正常，因此初步排除了业务本身的问题，并联系网络团队协助排查故障。

01-故障场景

接下来，将分享如何利用 DeepFlow 的全栈可观测性能力，在复杂的异构测试环境中快速定位和解决服务网格的性能瓶颈问题。在本次案例中，测试环境复杂且异构：

• 黑盒化挑战：底层架构（如服务网格和定制化的 SSE 代理版本等）对测试人员而言完全“黑盒”，缺乏直观的可见性和透明度。由于系统内各组件间依赖关系复杂，交互链路较长，问题根因往往隐藏在底层实现中，难以通过传统手段直接定位。
• 架构多样性：各测试集群采用了不同的架构设计，其中部分集群引入了服务网格（Service Mesh），而部分集群未使用网格化架构。同时，服务网格中的代理（如 Envoy）版本不统一，部分代理还针对特定场景的进行了定制化开发（如支持 SSE 协议）。这种架构的异构性和多样化显著增加了问题排查的复杂性。

02｜排障过程

02-排障过程

Step 1：对业务进行实时拨测，固定复现问题并分析相关数据

在本步骤中，我们通过模拟真实环境对业务 POD 发起实时拨测，以确认问题是否能够固定复现，并对复现过程中采集的数据进行深入分析。具体操作如下：在集群 A-Test-Cluster 中，模拟其他 Node，向目标地址 ​​http://10.2*.4*.2*:17**2/Work*​​ 发起 curl 请求，验证问题的稳定复现性。

03-实时拨测

Step 2：在全景拓扑中定位访问慢的路径与具体时间

在全景拓扑中，通过筛选目标服务和指定时间范围，精准定位访问延迟的路径与时间点。在拓扑页面的服务端搜索框中，输入目标业务服务的过滤条件 pod=*-vt--qm-web-*。选择问题发生的时间范围（存在访问延迟的时间段）。系统将生成一张客户端访问 *-vt-qm-web-* 服务（下面统称服务 A）的访问拓扑图。

在生成的拓扑图中，所有响应时延超过预期的访问路径会被标记为红色。分析后发现，拨测服务访问服务 A 时存在响应时延超过 1 分钟的情况。

03-全景拓扑

在拓扑图中点击目标路径，进入右滑框，可查看该路径响应时延的历史曲线。该曲线提供秒级别的精细数据，使问题定位更加精准。通过分析历史曲线，发现目标路径在以下时间点存在明显的响应延迟问题：10:11:00 和 10:52:43。

04-右滑框

Step 3：通过调用日志，分析不同观测点的响应时延，精准定位瓶颈位置

在确认响应慢的时间点和目标调用路径 /work* 后，利用调用日志对不同观测点的响应时延进行分析，逐步缩小问题范围。选定之前发现的异常时间点（如 10:11:00 和 10:52:43）及调用路径 /work*，查询各观测点的调用详情。

对比各观测点的响应时延，发现瓶颈点：Sidecar 代进程（目标服务 A 所在 POD 的代理）出现响应时延超过 1 分钟的情况且响应码都是 304。而服务 A 对应的业务进程在同一时间点的响应是非常快速的（44us）。

05-调用日志

Step 4：通过持续剖析精准定位进程性能瓶颈

在持续剖析界面中，选择 Sidecar 代理进程并指定响应慢的时间范围，生成火焰图以深入分析性能瓶颈。结合 On-CPU 剖析结果可以发现，Sidecar 代理进程大部分时间消耗在 runtime.epollwait 阶段，表明其正在等待 I/O 事件的就绪。

06-持续剖析

Step 5：问题反馈与处理

Sidecar 代理进程处理 /work** API 时，返回 304 Not Modified 的响应，且响应时间异常缓慢。且通过持续剖析分析，发现其在处理 304 响应时会卡住在runtime.epollwait函数上。将该问题反馈给研发团队，进一步分析根因。

集群 A-Test-Cluster 中，为支持大模型应用的测试需求，专门针对 Sidecar 代理发布了特殊版本，以支持 SSE 协议。该版本的 Sidecar 代理对 304 响应（body 为空的场景）未进行正确处理，导致在尝试读取 body 时进入阻塞状态。当前研发已修复 Bug，当前集群的 Sidecar 代理能够正确处理 304 响应，调用已正常。

根因解读：大模型应用采用了流式传输模式，该过程大致为：正常发送数据时，Sidecar 代理逐个 chunk 读取，以 EOF 为 chunk 结束标记，然后将数据递交到后端；但当流为空时，Sidecar 代理依然尝试读取，但却无法获取到 EOF，所以进入等待状态，表现为应用阻塞，在等待一分钟后才发生超时。

07-故障修复

03｜案例总结

DeepFlow 通过全栈观察能力，能高效解决复杂环境中故障定界困难的问题。其核心基于 eBPF 技术，能够覆盖从网络到系统内核到用户态进程的每一个层面，提供对请求全生命周期的深度可观测性：

• 全面覆盖全栈路径：对请求的全路径进行追踪，从应用程序发起请求，经过系统调用、网络传输、容器平台、服务网格等环节，到达数据库服务或对端微服务，形成完整的链路视图。确保在跨组件、跨层级的复杂环境中，所有关键路径都能够清晰可见。
• 中立且充足的观测数据：DeepFlow 提供与架构无关的中立观测数据，无需依赖特定的系统架构或定制化实现，适用于多样化的架构场景。通过实时采集系统调用、网络传输和应用性能数据，帮助快速识别故障位置，精准定位问题根因。
• 高效故障定界：借助 eBPF 技术，DeepFlow 能无侵入捕获网络指标、系统性能与应用进程数据。可在请求链路的任何节点快速发现异常（如延迟、协议异常等），为问题定界提供强有力的支持。