2. Istio 架构深度解析：控制平面与数据平面、Pilot、Mixer、Citadel、Envoy 代理角色

在诊断服务网格 API 延迟时，理解 Istio 的架构分层是定位代理链路建立瓶颈的前提。Istio 将网络功能拆分为控制平面与数据平面，二者通过 xDS 协议（Discovery Service）进行配置下发。首次请求延迟的根因，往往就隐藏在这两个平面的交互细节中。

2.1 整体架构：控制平面与数据平面

下图展示了 Istio 1.5+ 版本后的架构形态。控制平面合并为单一的 istiod 组件，内部包含 Pilot、Mixer（已废弃但概念保留）、Citadel 的核心逻辑；数据平面由注入到 Pod 中的 Envoy 代理构成。

2.2 Pilot：服务发现与配置下发核心

Pilot 是控制平面中与数据平面交互最频繁的组件。它负责将高层路由规则（VirtualService、DestinationRule）转换为 Envoy 可理解的 xDS 配置。

2.3 Citadel：证书管理与 mTLS 握手

Citadel（在 1.5+ 版本中集成在 istiod 内）负责生成和分发 X.509 证书，用于服务间 mTLS 通信。首次请求的延迟中，证书获取与握手往往占据较大比重。

• 证书生命周期： Citadel 通过 SDS（Secret Discovery Service）将证书推送给 Envoy，默认证书有效期 24 小时。
• 首次握手流程： Envoy 启动后向 Citadel 请求证书 → Citadel 验证 Pod 身份（通过 ServiceAccount）→ 签发证书 → Envoy 加载证书 → 与对端 Envoy 完成 TLS 握手。
• 延迟影响： 证书签发与分发通常需要 50-200ms，若 Citadel 使用自建 CA 且未预热，首次请求可能额外增加 500ms+ 的延迟。

2.4 Envoy 代理：数据平面的核心执行者

Envoy 是 Istio 数据平面的唯一代理，所有流量劫持、策略执行、TLS 终止都在此完成。从延迟诊断角度看，Envoy 的启动顺序与配置就绪状态直接决定了首次请求的成败。

2.5 Mixer：历史角色与当前替代方案

在 Istio 1.5 之前，Mixer 是独立的策略检查与遥测组件。由于 Mixer 作为外部进程调用会引入显著的延迟（通常 5-20ms/请求），社区在 1.5 版本后将其功能内联到 Envoy 的 Wasm 扩展或 Telemetry v2 中。

• 旧架构延迟问题： Mixer 作为独立进程，每次请求都需要通过 gRPC 调用 Mixer 进行策略检查，增加了网络往返和序列化开销。
• 当前最佳实践： 使用 Envoy 内置的 Wasm 或 Stats 插件替代 Mixer，将策略执行与遥测采集下沉到数据平面，消除额外的 RPC 延迟。
• 对首次请求的影响： 旧版 Mixer 架构下，首次请求需要等待 Mixer 策略缓存预热，延迟更高；新版内联架构下，首次请求延迟主要来自 xDS 与 SDS，不再受 Mixer 影响。

2.6 组件交互时序：首次请求延迟的完整链路

将上述组件串联起来，首次请求的延迟可以分解为以下阶段。每个阶段都可能成为瓶颈。

1. Pod 启动 → Envoy 初始化： iptables 规则注入，Envoy 进程启动。
2. Envoy 向 Pilot 发起 xDS 订阅： 请求 LDS、RDS、CDS、EDS 配置。
3. Envoy 向 Citadel 发起 SDS 请求： 获取 mTLS 证书。
4. Envoy 完成配置预热： Listener、Cluster、Secret 全部就绪。
5. 应用发起首次请求： 请求被 iptables 劫持到 Envoy。
6. Envoy 执行路由匹配与负载均衡： 选择目标端点。
7. Envoy 与对端 Envoy 完成 mTLS 握手： 双向证书验证。
8. 请求转发至目标应用容器： 首次请求完成。