2. 服务网格延迟基础：延迟的常见来源与网格放大效应

在服务网格架构中，延迟并非单一来源，而是由网络传输、代理处理、应用逻辑三者叠加而成。更关键的是，网格的 Sidecar 代理模式会引入一种独特的“延迟放大效应”——每一次服务调用都经过多次代理转发，使得微小的单跳延迟被成倍放大。理解这些来源及其相互作用，是构建有效观测标签体系的前提。

2.1 延迟的三大来源

我们将服务网格中的延迟来源划分为三个层次：网络层、代理层和应用层。下表列出了各层的主要延迟因素及其典型量级。

2.2 网格场景下的延迟放大效应

延迟放大效应是服务网格区别于传统微服务架构的核心特征。下图展示了一个典型的 4 跳服务调用链，其中每个服务都通过 Sidecar 代理进行通信。

2.3 延迟放大效应的数学表达

设服务调用链长度为 N（跳数），每跳的代理延迟为 P，网络延迟为 N_net，应用延迟为 A。则端到端延迟 L 可表示为：

L = N × (2 × P + N_net) + A

其中 2 × P 表示每跳包含出站和入站两次代理处理。当 N 较大时，代理延迟成为主导因素。下表对比了不同 N 值下的延迟构成：

2.4 延迟来源的观测标签映射

为了在 Gateway API 观测体系中准确归因延迟，我们需要为每个来源分配特定的标签。下表展示了延迟来源与观测标签的对应关系：

通过上述标签，我们可以将端到端延迟分解为多个可观测的片段。下图展示了延迟分解的瀑布图模型：

2.5 延迟放大效应的典型场景

以下列出三种常见的延迟放大场景，以及对应的观测标签策略：

• 场景一：深度调用链（N > 10）
  特征：代理延迟线性累加，端到端延迟随跳数增长。
  观测标签：hop_count、proxy.latency.per_hop。
• 场景二：频繁 mTLS 重建
  特征：每次新建连接都触发握手，延迟突增。
  观测标签：tls.handshake.count、tls.handshake.latency。
• 场景三：代理队列拥塞
  特征：Sidecar 处理能力不足，请求排队。
  观测标签：proxy.queue.depth、proxy.queue.latency。