3. 延迟诊断基础：延迟的构成与分布

在服务网格中，每一次 API 调用的端到端延迟都不是单一来源，而是由多个阶段叠加而成。理解延迟的构成与分布，是进行延迟回归检查的前提。本章将拆解延迟的三大组成部分，并介绍如何通过 P50/P90/P99 百分位指标量化延迟特征。

3.1 延迟的三大构成

一次典型的服务网格请求，从客户端发起 Sidecar 到目标服务返回响应，其延迟可分解为三个核心阶段：网络延迟、序列化/反序列化延迟、业务逻辑延迟。三者叠加形成最终的用户感知延迟。

3.2 延迟分布：P50 / P90 / P99

单一的平均延迟无法反映真实体验。服务网格治理中，必须使用百分位延迟来量化延迟分布特征。P50（中位数）、P90（第 90 百分位）、P99（第 99 百分位）是三个最核心的指标。

• P50（中位数延迟）：50% 的请求延迟低于该值。反映系统在正常负载下的典型表现，是日常性能基准。
• P90（第 90 百分位延迟）：90% 的请求延迟低于该值。代表大多数用户的体验，常用于 SLA 定义。
• P99（第 99 百分位延迟）：99% 的请求延迟低于该值。捕捉尾部延迟，反映极端情况下的性能瓶颈。

3.3 延迟构成与分布的关联分析

将延迟构成与百分位分布结合，可以精准定位瓶颈。下表展示了不同百分位下各构成阶段的典型占比变化：

3.4 延迟数据采集与计算示例

在服务网格中，通常通过 Envoy 的 Access Log 或 OpenTelemetry 追踪来采集延迟数据。以下是一个基于 Envoy Access Log 的延迟字段示例：

# Envoy Access Log 格式（延迟相关字段）
[%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
  response_code=%RESPONSE_CODE%
  upstream_service_time=%UPSTREAM_SERVICE_TIME%   # 上游服务处理时间（业务逻辑延迟）
  request_duration=%DURATION%                     # 总请求耗时（端到端延迟）
  request_tx_duration=%REQUEST_TX_DURATION%       # 请求传输时间（网络延迟）
  response_rx_duration=%RESPONSE_RX_DURATION%     # 响应接收时间（网络延迟）

基于采集的原始数据，计算 P50/P90/P99 的伪代码如下：

# 延迟百分位计算示例（Python）
import numpy as np

# 假设采集到 1000 个请求的端到端延迟（单位 ms）
latencies = [12, 15, 18, 22, 25, 30, 35, 40, 50, 65, 80, 120, 200, ...]

p50 = np.percentile(latencies, 50)   # 中位数
p90 = np.percentile(latencies, 90)   # 第 90 百分位
p99 = np.percentile(latencies, 99)   # 第 99 百分位

print(f"P50: {p50:.1f} ms")
print(f"P90: {p90:.1f} ms")
print(f"P99: {p99:.1f} ms")