2. Envoy 基础架构：数据平面与控制平面核心组件解析

Envoy 采用数据平面 (Data Plane) 与控制平面 (Control Plane) 分离的架构设计。数据平面负责处理实际流量，控制平面负责下发配置与策略。理解两者的边界与协作机制，是优化通信延迟、降低 GitOps 同步窗口成本的前提。

2.1 架构总览：数据平面与控制平面的职责边界

Envoy 实例本身是一个数据平面代理，它通过 xDS API 从控制平面（如 Istiod、Kuma CP、自定义 Go 控制面）拉取动态配置。下表列出两者的核心职责与关键差异：

2.2 数据平面核心组件解析

Envoy 数据平面内部由多个工作线程 (Worker Thread) 和一组核心模块组成。每个工作线程独立运行事件循环，不共享锁，从而实现线性扩展。

2.2.1 监听器 (Listener) 与过滤器链 (Filter Chain)

• Listener：绑定端口（如 80、443），接收入站连接。支持 TCP、UDP、QUIC。
• Filter Chain：按协议匹配（SNI、ALPN、端口）选择过滤器链。每个链包含多个 Network Filter（L3/L4）和 HTTP Filter（L7）。
• 典型流程：Listener 接收连接 → 匹配 Filter Chain → 执行 Network Filters（如 TLS 解密、TCP 代理）→ 进入 HTTP Connection Manager → 执行 HTTP Filters（如 RBAC、限流、路由）。

2.2.2 集群 (Cluster) 与端点 (Endpoint)

• Cluster：定义上游服务集群的配置，包括连接池大小、负载均衡算法（轮询、最少请求、一致性哈希）、健康检查类型（HTTP、TCP、gRPC）。
• Endpoint：集群内的具体 IP:Port 实例。通过 EDS（Endpoint Discovery Service）动态更新。
• 负载均衡：Envoy 支持 Zone Aware LB，优先将流量发送到同一可用区的端点，减少跨 AZ 成本。

2.2.3 线程模型与连接池

Envoy 使用 1+N 线程模型：主线程负责配置加载和统计，工作线程处理 I/O。每个工作线程维护独立的连接池，避免跨线程锁竞争。

// 连接池配置示例 (CDS 动态配置片段)
{
  "name": "service-backend",
  "connect_timeout": "0.25s",
  "type": "EDS",
  "lb_policy": "LEAST_REQUEST",
  "circuit_breakers": {
    "thresholds": [
      { "priority": "DEFAULT", "max_connections": 1024, "max_pending_requests": 1024 }
    ]
  }
}

2.3 控制平面核心组件解析

控制平面负责将高级配置（如 VirtualService、DestinationRule）转换为 Envoy 可理解的 xDS 协议。核心组件包括：

2.3.1 配置生成与缓存

• Translator：将 CRD（如 Istio VirtualService）转换为 Envoy 的 JSON/Protobuf 格式。
• Cache：控制平面维护每个 Envoy 实例的 Last Known Config，只推送增量变更（Delta xDS），减少全量推送带来的带宽和解析开销。
• Validation Webhook：在配置下发前校验语法和语义，避免错误配置导致数据平面崩溃。

2.3.2 与 GitOps 的集成点

GitOps 工具（ArgoCD、Flux）将 Git 仓库中的配置同步到 Kubernetes CRD。控制平面监听 CRD 变化，生成 xDS 配置并推送到所有 Envoy 实例。同步窗口成本主要体现在：

• 全量同步：每次 Git 提交都触发所有 Envoy 实例的全量配置重算。
• 增量同步：仅推送变更的 xDS 资源，减少序列化和网络开销。
• 批量合并：在同步窗口内合并多个 Git 提交，避免频繁推送。

2.4 数据平面与控制平面的通信流程

下图展示了一次典型的配置更新流程，从 Git 提交到 Envoy 生效：

2.5 核心组件对 GitOps 同步窗口成本的影响

下表总结了各组件在同步窗口中的成本敏感度及优化方向：