📚 课程目录第2章 API延迟基础

2. API延迟基础：延迟的定义、度量单位与用户体验影响

2.1 延迟的定义

在API网关与微服务架构中，延迟（Latency）指从客户端发出请求到收到完整响应所经过的总时间。它衡量的是“等待时间”，而非“处理能力”。延迟是Envoy网关可观测性中最核心的指标之一，直接反映服务链路的响应速度。

  关键概念区分：延迟 ≠ 响应时间。响应时间包含网络传输、排队、处理、序列化/反序列化等全部环节；延迟通常特指端到端的单向或往返耗时。在Envoy中，延迟通常以请求-响应往返时间（RTT）为基准。

2.2 延迟的度量单位

Envoy网关及分布式追踪系统通常使用以下时间单位度量延迟：

单位	符号	换算关系	典型场景
毫秒	ms	1 ms = 1,000 μs	API请求总耗时、上游服务响应时间、Envoy过滤器处理时间
微秒	μs	1 μs = 1,000 ns	Envoy内部连接池获取、TLS握手、HTTP头部解析、内核上下文切换
纳秒	ns	1 ns = 0.001 μs	CPU指令级耗时、内存访问延迟（通常不在API层面直接度量）

实践建议：在Envoy的访问日志（access log）和指标（metrics）中，延迟默认以毫秒（ms）为单位输出。当诊断微服务内部瓶颈时，建议将微秒（μs）作为辅助单位，用于分析Envoy自身的处理开销。

2.3 延迟对用户体验的影响

延迟对用户体验的影响遵循“响应时间阈值法则”，业界公认的参考标准如下：

0–100 ms：用户感知为“即时”，操作流畅无等待感。
100–300 ms：用户能感知轻微延迟，但通常不影响操作连续性。
300–1000 ms：用户明显感到“卡顿”，注意力开始分散。
1–3 s：用户可能中断操作，跳出率显著上升。
> 3 s：大部分用户放弃请求，造成业务损失。

注意：在微服务网关场景中，单个API请求可能经过3–10个上游服务。每个服务增加10 ms延迟，端到端就可能增加30–100 ms，直接跨越用户体验的“可接受”阈值。Envoy网关的延迟诊断必须从全链路视角出发。

2.4 延迟在Envoy网关中的分解

Envoy网关将一次API请求的端到端延迟分解为以下阶段：

网络传输延迟：客户端到Envoy、Envoy到上游服务的网络往返时间。
Envoy内部处理延迟：包括TLS握手、HTTP/2帧解析、路由匹配、过滤器链执行、连接池获取。
上游服务处理延迟：上游业务逻辑执行时间。
响应传输延迟：响应数据从上游服务返回客户端的时间。

2.5 延迟与吞吐量的关系

延迟与吞吐量（Throughput）之间存在相互制约的关系。Envoy网关在高并发场景下，延迟会随吞吐量增加而非线性上升：

低负载区：延迟稳定，吞吐量线性增长。
拐点区：资源（CPU、连接池、线程）接近饱和，延迟开始加速上升。
饱和区：延迟急剧恶化，吞吐量不再增长甚至下降。

  Envoy诊断要点：当观察到延迟P99（第99百分位）与P50（中位数）差距超过5倍时，通常意味着存在长尾延迟问题，可能由连接池耗尽、上游服务慢实例或GC暂停引起。

2.6 延迟度量在Envoy中的实践

Envoy通过以下机制暴露延迟数据：

数据源	指标/字段	单位	说明
集群指标	`envoy_cluster_upstream_rq_time`	ms	上游请求平均延迟，按统计分桶输出
访问日志	`%DURATION%`	ms	请求总耗时（从接收首字节到发送末字节）
访问日志	`%RESPONSE_DURATION%`	ms	上游服务响应时间（排除Envoy内部排队）
追踪	Span duration	μs/ms	分布式追踪中各Span的耗时，支持微秒级精度

# Envoy访问日志格式示例（延迟相关字段）
log_format:
  "%START_TIME% %REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL% 
   %RESPONSE_CODE% %DURATION% %RESPONSE_DURATION% %UPSTREAM_HOST%"

# 输出示例
2025-03-15T10:30:45.123Z GET /api/orders HTTP/1.1 200 245 198 10.0.1.5:8080
# 说明：总延迟245ms，上游服务处理198ms，Envoy内部+网络=47ms

诊断切入点：当 %DURATION% 远大于 %RESPONSE_DURATION% 时，说明瓶颈在Envoy内部或网络传输；反之，瓶颈在上游服务。这是Envoy延迟诊断的第一原则。