延迟的构成要素：网络延迟、计算延迟、冷启动延迟、数据库延迟、外部API调用延迟

在 Serverless 架构中，一次 API 请求的端到端延迟并非单一因素导致，而是由多个独立环节的耗时叠加而成。只有将延迟拆解为可观测的构成要素，才能精准定位瓶颈。本章逐一剖析五大核心延迟来源：网络延迟、计算延迟、冷启动延迟、数据库延迟、外部 API 调用延迟。

2.1 延迟构成全景图

下图展示了从客户端发起请求到收到响应的完整链路，每个阶段都可能引入延迟。理解这张图是后续诊断的基础。

2.2 五大延迟要素详解

2.3 网络延迟

网络延迟是客户端到 Serverless 平台之间数据传输的耗时。在分布式系统中，这是最不可控但最容易测量的延迟来源。

• 公网传输：数据包经过多个路由节点，受物理距离和网络拥塞影响。跨区域调用（如从欧洲到美国）通常增加 100-300ms。
• DNS 解析：首次域名解析可能耗时 20-50ms，使用 DNS 缓存可降至 1ms 以内。
• TLS 握手：HTTPS 连接需要 1-2 次往返，增加 30-100ms 延迟。启用会话复用可显著降低。
• API 网关转发：网关本身引入 5-20ms 处理延迟，包括请求校验、路由匹配和鉴权。

2.4 计算延迟

计算延迟指函数代码实际执行所消耗的 CPU 时间。在 Serverless 中，计算延迟与分配的内存成正比——内存越大，CPU 性能越强。

• 代码效率：循环嵌套、未优化的算法、冗余的序列化/反序列化都会增加计算延迟。
• 依赖加载：每次调用时加载的第三方库（如 ORM、模板引擎）可能占用 10-50ms。
• 内存配置：128MB 内存的函数 CPU 性能约为 600MHz，而 1024MB 可达 2.4GHz，计算密集型任务差异显著。

// 示例：计算延迟对比（Node.js）
// 低效实现：每次调用都解析 JSON
function handler(event) {
  const data = JSON.parse(event.body);  // 每次解析
  // ... 业务逻辑
}

// 高效实现：预编译或缓存解析结果
const parser = new JSONParser();  // 初始化一次
function handler(event) {
  const data = parser.parse(event.body);  // 复用解析器
  // ... 业务逻辑
}

2.5 冷启动延迟

冷启动是 Serverless 特有的延迟来源。当没有空闲实例处理请求时，平台需要从零初始化一个运行环境，包括下载代码、启动运行时、执行初始化逻辑。

2.6 数据库延迟

数据库延迟包括连接建立、查询执行和数据传输三个部分。在 Serverless 架构中，由于函数实例频繁创建和销毁，数据库连接管理成为关键挑战。

• 连接建立：每次新建数据库连接需要 10-50ms（TCP 握手 + 认证）。使用连接池或代理层可复用连接。
• 查询执行：慢查询、全表扫描、缺少索引是主要元凶。一个未优化的 JOIN 查询可能耗时 500ms+。
• 数据传输：返回大量数据行会增加网络传输时间。只查询需要的字段和行数。
• 锁竞争：高并发写入时，行锁或表锁导致等待，延迟可能飙升到秒级。

-- 慢查询示例（缺少索引）
SELECT * FROM orders WHERE customer_id = 12345;  -- 全表扫描，耗时 800ms

-- 优化后（添加索引）
CREATE INDEX idx_customer_id ON orders(customer_id);
SELECT order_id, amount, status FROM orders WHERE customer_id = 12345;  -- 索引扫描，耗时 5ms

2.7 外部 API 调用延迟

Serverless 函数经常需要调用第三方服务（如支付网关、消息推送、AI 模型）。这些外部调用的延迟完全不受你控制，但会直接拖慢整个 API 响应。

• 网络开销：每次 HTTP 请求的 DNS 解析、TCP 连接、TLS 握手合计 30-100ms。
• 服务端处理：第三方服务的业务处理时间，从 10ms（简单查询）到 2s（复杂 AI 推理）不等。
• 重试机制：超时或错误时的重试会成倍增加延迟。指数退避策略虽然可靠，但会显著延长响应时间。
• 串行 vs 并行：多个外部 API 串行调用时，延迟累加；改为并行调用可大幅降低总耗时。

2.8 延迟叠加效应与诊断优先级

实际生产环境中，五大延迟要素并非独立存在，而是相互叠加。例如：冷启动导致函数初始化慢，进而使数据库连接超时，触发重试，最终外部 API 调用也因等待而超时——形成“延迟雪崩”。