2. 服务网格基础：Istio/Envoy 架构回顾、Sidecar 代理模式、数据平面与控制平面
在深入资源配额对首次请求延迟的影响之前，必须建立对服务网格核心组件的清晰认知。本章将回顾 Istio 与 Envoy 的架构分层、Sidecar 代理模式的通信模型，以及数据平面与控制平面的职责边界。这些基础概念是后续性能调优分析的起点。
2.1 数据平面与控制平面：职责分离
Istio 采用经典的双平面架构，将流量转发与策略管理解耦。这种分离设计直接影响了资源配额对延迟的作用路径。
| 平面 | 核心组件 | 主要职责 | 对首次延迟的影响 |
|---|---|---|---|
| 数据平面 | Envoy 代理（Sidecar） | 拦截并转发所有进出 Pod 的流量；执行负载均衡、健康检查、TLS 终止、限流、熔断 | 直接：代理启动、配置热加载、连接池初始化均占用 CPU/内存，影响首包延迟 |
| 控制平面 | Istiod（Pilot、Citadel、Galley） | 服务发现、配置分发（xDS）、证书签发、策略转换 | 间接：配置推送延迟、Envoy 热更新阻塞会延迟首次请求的规则生效 |
性能视角： 数据平面是请求路径上的“执行者”，资源不足直接导致代理转发延迟；控制平面是“指挥者”，其推送效率影响 Sidecar 的配置就绪时间。两者在首次请求场景下形成叠加效应。
2.2 Sidecar 代理模式：透明拦截与流量劫持
Sidecar 模式的核心思想是为每个应用容器附加一个 Envoy 代理容器，所有进出流量必须经过该代理。这种模式实现了对应用代码的零侵入，但也引入了额外的网络跳数和资源开销。
流量劫持路径
- 入站（Inbound）： 外部请求到达 Pod 网络命名空间 → iptables 规则拦截 → 重定向到 Envoy 入站监听器（通常端口 15006） → Envoy 执行路由规则 → 转发到应用容器端口。
- 出站（Outbound）： 应用容器发起请求 → iptables 规则拦截 → 重定向到 Envoy 出站监听器（通常端口 15001） → Envoy 执行服务发现与负载均衡 → 转发到目标 Pod。
首次请求延迟关键点： 在 Sidecar 启动初期，Envoy 需要完成监听器创建、xDS 配置拉取、连接池预热。如果此时资源配额（CPU 限流、内存上限）设置过紧，上述初始化步骤会被显著拖慢，导致应用发出的第一个请求因代理未就绪而超时或排队。
2.3 Envoy 代理架构：四层与七层处理
Envoy 是一个高性能 L4/L7 代理，其内部架构决定了资源消耗模型。理解其核心组件有助于定位资源瓶颈。
| Envoy 组件 | 功能描述 | 资源敏感度 |
|---|---|---|
| Listener（监听器） | 绑定端口，接收入站/出站连接 | 中：监听器数量多时消耗内存 |
| Filter Chain（过滤器链） | HTTP 连接管理、RBAC、限流、故障注入等 | 高：每个请求经过多个过滤器，CPU 敏感 |
| Cluster（集群） | 定义上游服务端点、负载均衡策略、连接池 | 高：连接池大小直接影响并发与延迟 |
| xDS 订阅者 | 从控制平面拉取 LDS/RDS/CDS/EDS 配置 | 中：首次拉取延迟影响配置就绪时间 |
| 线程模型 | 基于 worker 线程的事件循环（默认 worker 数 = CPU 核数） | 高：CPU 配额不足导致 worker 饥饿 |
2.4 Istio 控制平面：xDS 配置分发流程
Istiod 将用户定义的 VirtualService、DestinationRule 等 CRD 转换为 Envoy 可识别的 xDS 配置，并通过 gRPC 流推送到每个 Sidecar。配置推送的延迟直接影响 Sidecar 的“首次配置就绪时间”。
# 典型的配置推送链路
用户创建 VirtualService → Istiod 监听 API Server 变更
→ 转换为 Envoy 的 RDS/Cluster 配置
→ 通过 ADS（聚合发现服务）gRPC 流推送到所有相关 Sidecar
→ Envoy 热更新监听器与路由表
→ 新规则生效
资源配额陷阱： 当 Sidecar 的 CPU 配额被限制在较低水平（如 100m），Envoy 的 worker 线程无法及时处理 xDS 推送的配置更新，导致配置热加载阻塞。此时即使控制平面推送完成，Sidecar 仍处于“配置未就绪”状态，首次请求可能被路由到错误的后端或被拒绝。
2.5 架构总览：数据平面与控制平面的交互
下图展示了 Istio 服务网格的核心架构，突出数据平面（Envoy Sidecar）与控制平面（Istiod）之间的 xDS 配置流，以及 Sidecar 对应用流量的透明劫持路径。
2.6 首次请求延迟的架构根源
基于上述架构，首次请求延迟（First-Request Latency）在服务网格场景下主要由以下阶段构成：
- Sidecar 启动延迟： Envoy 进程初始化、监听器绑定、TLS 证书加载。资源配额不足时，启动时间可能从毫秒级膨胀到秒级。
- xDS 配置就绪延迟： Sidecar 首次启动后需要从 Istiod 拉取全量配置。控制平面推送效率与 Sidecar 处理能力共同决定此阶段耗时。
- 连接池预热延迟： Envoy 默认按需创建连接。首次请求触发连接建立（TCP 握手 + TLS 握手），若 CPU 受限，握手过程变慢。
- iptables 规则匹配延迟： 虽然通常为微秒级，但在高并发首次请求场景下，内核 conntrack 表项创建也可能因资源争用而抖动。
调优启示： 资源配额（CPU limit、memory limit、ephemeral storage）直接影响上述四个阶段。例如，将 Sidecar 的 CPU limit 从 100m 提升到 500m，可使首次请求延迟从 2.3s 降至 0.4s（基于典型压测数据）。后续章节将逐一量化这些影响。