2. Istio 架构基础：控制平面与数据平面、Envoy 代理、Pilot、Mixer、Citadel 核心组件
Istio 作为云原生服务网格的事实标准，其架构设计遵循了经典的控制平面与数据平面分离原则。理解这两个平面的职责划分以及核心组件的交互机制，是进行后续存储组件集成与性能基准测试的前提。本章将深入剖析 Istio 的架构骨架，重点拆解 Envoy、Pilot、Mixer 和 Citadel 的功能边界与协作流程。
2.1 控制平面与数据平面：职责分离与通信模型
Istio 将网络治理与安全策略的决策逻辑（控制平面）与流量转发及策略执行（数据平面）解耦，这种架构设计带来了极高的灵活性和可扩展性。
| 维度 | 控制平面 (Control Plane) | 数据平面 (Data Plane) |
|---|---|---|
| 核心职责 | 策略决策、配置分发、证书签发、遥测数据聚合 | 流量拦截、协议转发、负载均衡、健康检查、策略执行 |
| 主要组件 | Pilot、Mixer、Citadel、Galley | Envoy 代理（Sidecar 模式） |
| 通信方式 | 通过 xDS 协议（Discovery Service）下发配置 | 通过 xDS 协议接收配置，通过 Mixer 适配器上报遥测 |
| 故障影响域 | 控制平面中断不影响已建立的连接，但新策略无法生效 | 数据平面中断直接导致业务流量中断 |
| 性能敏感度 | 对延迟不敏感，但对吞吐量（配置推送速率）有要求 | 对延迟、吞吐量、资源消耗极度敏感 |
下图展示了 Istio 控制平面与数据平面之间的核心交互关系，以及各组件在服务网格中的位置。
2.2 Envoy 代理：数据平面的核心执行者
Envoy 是一个高性能的 L7 代理和通信总线，由 Lyft 开源，Istio 将其作为数据平面的默认 Sidecar 代理。Envoy 以 Sidecar 模式注入到每个应用 Pod 中，拦截所有进出 Pod 的流量。
2.2.1 Envoy 的核心能力
- 流量拦截与转发： 通过 iptables 规则透明地劫持入站和出站流量，基于动态配置进行路由转发。
- 协议支持： 原生支持 HTTP/1.1、HTTP/2、gRPC、TCP、WebSocket 等协议，支持协议嗅探和自动切换。
- 负载均衡： 内置丰富的负载均衡算法，包括轮询、最少连接、随机、一致性哈希等。
- 健康检查： 主动和被动健康检查，自动剔除不健康的端点。
- 熔断与重试： 支持熔断器模式、超时控制、自动重试和请求限流。
- 可观测性： 自动生成详细的访问日志、分布式追踪（Trace）和 Prometheus 指标。
2.2.2 Envoy 的 xDS 配置模型
Envoy 通过 xDS 协议从控制平面（Pilot）动态获取配置，这是 Istio 实现动态治理的基础。xDS 包含以下核心 API：
| API 名称 | 全称 | 功能描述 |
|---|---|---|
| LDS | Listener Discovery Service | 配置监听器（端口、协议、过滤器链） |
| RDS | Route Discovery Service | 配置路由规则（域名、路径、权重） |
| CDS | Cluster Discovery Service | 配置上游集群（端点、负载均衡策略） |
| EDS | Endpoint Discovery Service | 配置集群的端点列表（Pod IP 和端口） |
| SDS | Secret Discovery Service | 配置 TLS 证书和密钥（与 Citadel 交互） |
2.3 Pilot：控制平面的流量管理大脑
Pilot 是 Istio 控制平面中负责服务发现和流量管理的核心组件。它负责将用户配置的 VirtualService、DestinationRule 等 CRD 资源转换为 Envoy 能够理解的 xDS 配置，并推送到所有数据平面的 Envoy 代理。
2.3.1 Pilot 的核心职责
- 服务发现抽象： 从平台（Kubernetes、Consul、Eureka 等）获取服务注册信息，统一抽象为 Service Registry。
- 配置转换： 将 Istio 的流量管理 CRD（VirtualService、DestinationRule、Gateway 等）转换为 Envoy 的 xDS 配置。
- 配置分发： 通过 gRPC 流式推送 xDS 配置到所有 Envoy 代理，支持增量更新，减少全量推送带来的性能开销。
- 服务网格一致性： 确保所有 Envoy 代理看到的配置视图一致，避免路由黑洞或策略冲突。
2.3.2 Pilot 的配置推送流程
- 监听变更： Pilot 监听 Kubernetes API Server 上的 Service、Pod、Endpoint 以及 Istio CRD 的变化。
- 生成配置： 将变更事件结合用户定义的流量规则，生成新的 xDS 配置快照。
- 增量计算： 对比当前配置快照与上一次推送的快照，计算出增量变更。
- 流式推送： 通过 gRPC 双向流将增量配置推送到所有受影响的 Envoy 代理。
2.4 Mixer：策略与遥测的中间层
Mixer 是 Istio 早期的策略决策和遥测收集组件，负责在请求经过 Envoy 时执行访问控制、配额管理和指标收集。在 Istio 1.5 之后，Mixer 的功能逐渐被内联到 Envoy 中（通过 Wasm 插件和 Telemetry v2），但其设计思想仍然深刻影响着 Istio 的扩展性。
2.4.1 Mixer 的两种工作模式
| 模式 | 描述 | 性能影响 |
|---|---|---|
| 前置检查 (Check) | Envoy 在转发请求前，向 Mixer 发送 Check 请求，获取是否允许通过、是否限流等决策。 | 增加请求路径延迟（通常 1-5ms），高并发下 Mixer 可能成为瓶颈。 |
| 后置报告 (Report) | Envoy 在请求处理完成后，向 Mixer 发送 Report 请求，上报日志、指标和追踪数据。 | 异步处理，对请求延迟影响较小，但 Mixer 的吞吐能力决定数据是否丢失。 |
2.4.2 Mixer 的适配器架构
Mixer 通过适配器（Adapter）与后端系统集成，支持丰富的生态：
- 日志适配器： Fluentd、Stackdriver、Elasticsearch
- 指标适配器： Prometheus、StatsD、Datadog
- 配额适配器： Redis、Memcached
- 授权适配器： OPA (Open Policy Agent)、自定义 RBAC
2.5 Citadel：安全与身份管理基石
Citadel 是 Istio 的安全组件，负责管理服务网格中的证书签发、身份认证和密钥轮换。它使得服务间通信可以默认启用 mTLS（双向 TLS），实现零信任网络。
2.5.1 Citadel 的核心功能
- 证书签发： 为每个 Service Account 签发 X.509 证书，绑定服务身份。
- 密钥轮换： 定期轮换证书和私钥，默认轮换周期为 24 小时，降低密钥泄露风险。
- 身份认证： 验证服务间的 mTLS 握手，确保通信双方的身份合法。
- CA 集成： 支持与外部 CA（如 HashiCorp Vault、cert-manager）集成，实现企业级证书管理。
2.5.2 Citadel 的证书分发流程
- 请求发起： Envoy 通过 SDS 协议向 Citadel 请求证书。
- 身份验证： Citadel 验证 Envoy 所在 Pod 的 Service Account 和 JWT 。
- 证书签发： Citadel 使用根 CA 签发短期有效的证书，并通过 gRPC 返回给 Envoy。
- 证书缓存： Envoy 缓存证书，在证书过期前自动发起轮换请求。
下图展示了 Citadel 与 Envoy 之间的证书交互流程，以及 mTLS 在服务间通信中的位置。
2.6 组件协作全景：一次请求的完整路径
为了更直观地理解 Istio 各组件的协作关系，下面以一个典型的 HTTP 请求为例，描述请求从进入网格到返回响应的完整路径。
- 流量进入： 客户端请求到达目标 Pod 的 Envoy Sidecar（入站监听器）。
- 策略检查： Envoy 根据 Pilot 下发的 LDS/RDS 配置，匹配路由规则。如果启用了 Mixer Check，Envoy 会向 Mixer 发送 Check 请求。
- mTLS 握手： 如果目标服务启用了 mTLS，Envoy 使用 Citadel 签发的证书与目标 Envoy 进行双向 TLS 握手。
- 负载均衡： Envoy 根据 CDS/EDS 配置，从健康端点列表中选择一个目标实例。
- 请求转发： Envoy 将请求转发到目标 Pod 的应用容器。
- 遥测上报： 请求处理完成后，Envoy 生成访问日志和指标，通过 Mixer Report 或 Telemetry v2 上报。
2.7 本章小结
Istio 的架构设计体现了云原生微服务的核心思想：通过控制平面与数据平面的分离，实现治理逻辑的集中管理和流量执行的分布式处理。Envoy 作为高性能数据平面代理，承担了流量转发和策略执行的重任；Pilot、Mixer 和 Citadel 则分别负责流量管理、策略遥测和安全身份。理解这些组件的职责边界和交互协议，是后续进行存储组件集成和性能基准测试的基础。