2. Latency 基础概念：延迟、响应时间、服务时间的区别与联系
在构建可观测体系与制定 SLO 时，延迟（Latency）、响应时间（Response Time） 和 服务时间（Service Time） 是三个最基础但极易混淆的指标。它们共同描述了请求从发出到完成的完整时间线，但各自聚焦于不同的时间区间与观察视角。理解三者的区别与联系，是后续设定门限阈值、推导 SLO 目标的数学前提。
2.1 核心定义与时间线模型
一个典型的用户请求生命周期可以拆解为以下阶段：
- 网络传输时间（Network RTT）：请求从客户端到达服务端、响应从服务端返回客户端所消耗的网络往返时间。
- 排队等待时间（Queueing Time）：请求到达服务端后，在任务队列中等待被处理线程/协程调度的空闲等待时间。
- 服务时间（Service Time）：服务端实际执行请求业务逻辑所消耗的 CPU 计算、IO 读写、数据库查询等纯处理时间。
- 响应时间（Response Time）：从客户端发出请求到收到完整响应的总耗时，包含上述所有阶段。
- 延迟（Latency）：通常指系统内部视角下，从请求进入系统到系统开始处理之间的等待时间，即 排队等待时间 的代名词；但在更广泛的语境中，延迟也常被用作响应时间的同义词。
术语澄清： 在 SRE 与可观测性领域，延迟（Latency） 的严格定义是“系统对请求的等待时间”，即请求在队列中等待被服务的时间。然而，在用户感知层面和大多数监控工具（如 Prometheus 的
http_request_duration_seconds）中，延迟指标实际测量的是 响应时间。本课程后续章节中，如无特殊说明，“延迟”均指代用户视角的端到端响应时间。
2.2 三者的核心区别
下表从 观察视角、测量范围、影响因素 和 典型用途 四个维度进行对比：
| 对比维度 | 延迟（Latency） | 响应时间（Response Time） | 服务时间（Service Time） |
|---|---|---|---|
| 观察视角 | 系统内部视角（队列等待） | 用户/客户端视角（端到端） | 服务端处理视角（纯计算） |
| 测量范围 | 请求入队 → 开始处理 | 请求发出 → 响应接收 | 开始处理 → 处理完成 |
| 主要影响因素 | 并发数、队列深度、调度策略 | 网络质量、排队、服务时间 | CPU 性能、IO 延迟、算法复杂度 |
| 典型用途 | 容量规划、背压检测 | 用户体验 SLO、Apdex 评分 | 性能优化、瓶颈定位 |
2.3 数学关系与公式推导
从时间线模型可以推导出三个指标之间的基本数学关系：
响应时间 (RT) = 网络传输时间 (Net) + 排队等待时间 (Queue) + 服务时间 (ST)
延迟 (Latency) = 排队等待时间 (Queue)
服务时间 (ST) = 响应时间 - 网络传输时间 - 排队等待时间在 理想网络环境（网络传输时间可忽略或恒定）下，公式可以简化为：
RT ≈ Queue + ST
Latency = Queue
ST = RT - Latency
关键洞察： 当系统处于低负载时，排队等待时间趋近于 0，此时 响应时间 ≈ 服务时间。当系统负载升高，排队等待时间成为响应时间的主要组成部分，此时 延迟（排队）是响应时间恶化的主要推手。这也是为什么 SLO 门限设定必须同时关注响应时间的高分位数（如 p99）和队列深度指标。
2.4 实际监控中的指标映射
在主流可观测性工具中，这三个概念通常对应不同的指标名称。理解映射关系有助于避免数据误读：
| 概念 | Prometheus 指标示例 | OpenTelemetry 语义 | 说明 |
|---|---|---|---|
| 响应时间 | http_request_duration_seconds |
http.server.duration |
从服务端收到请求到发送完响应头的耗时 |
| 服务时间 | process_cpu_seconds_total（间接） |
需通过 Span 的 duration 减去子 Span 等待时间 |
通常需要 APM 工具（如 Jaeger、Zipkin）的 Span 分析 |
| 延迟（排队） | http_request_queue_duration_seconds |
需自定义 Instrument | 部分框架（如 gunicorn、Netty）内置队列等待指标 |
常见陷阱： 许多监控系统将
http_request_duration_seconds 直接标记为“延迟”，但实际测量的是服务端视角的响应时间（不包含客户端到服务端的网络传输）。在制定面向用户的 SLO 时，必须考虑客户端真实感知的端到端响应时间，这通常需要 真实用户监控（RUM） 或 合成监控（Synthetic Monitoring） 来补充。
2.5 三者联系：从服务时间到 SLO 的推导路径
在 SLO 设定实践中，三个指标构成了一条清晰的推导链路：
- 服务时间 是系统的 基准性能，决定了在零负载下的最优响应时间。
- 延迟（排队） 是系统的 负载敏感度，反映了系统在压力下的弹性表现。
- 响应时间 是用户的 真实体验，是 SLO 目标值的直接度量对象。
通过持续监控服务时间的变化，可以判断性能退化是源于代码变更（服务时间增加）还是负载增长（排队延迟增加），从而精准定位优化方向。
2.6 本章小结
- 延迟 是系统内部的排队等待时间，反映负载压力；响应时间 是用户感知的端到端耗时，是 SLO 的直接度量对象；服务时间 是纯处理耗时，反映系统基准性能。
- 三者的数学关系为：响应时间 = 网络传输 + 延迟（排队） + 服务时间。
- 在监控实践中，需注意工具指标的实际测量范围，避免将服务端响应时间直接等同于用户端响应时间。
- SLO 门限的设定需要以服务时间为基准，叠加合理的排队预算和网络预算，形成可量化的阈值。