Envoy 代理基础：架构、核心概念与 xDS 协议
Envoy 是一个高性能、可编程的 L7 代理与通信总线，专为云原生架构设计。其核心设计哲学是网络对应用透明——通过 sidecar 模式注入服务网格，接管所有进出流量，并通过热重载机制实现零停机配置更新。本章将拆解 Envoy 的架构层次、四个核心资源对象以及驱动其动态配置的 xDS 协议。
1. Envoy 整体架构
Envoy 采用单进程多线程模型，主线程负责配置管理与协调，工作线程处理实际 I/O。架构自上而下分为三层：
- 控制面（Control Plane）：通过 xDS 协议从外部获取动态配置，如 Istio、Consul 或自建控制面。
- 配置管理层（Configuration Management）：接收并合并静态/动态配置，生成最终的路由、监听器、集群视图。
- 数据面（Data Plane）：工作线程基于最终配置执行连接处理、TLS 终止、HTTP 路由、负载均衡、健康检查等。
关键设计：配置更新通过“热重启”或“LDS/RDS/CDS/EDS 增量推送”实现，无需重启进程，这是 GitOps 流水线能够实现零停机同步的基础。
2. 四大核心概念
Envoy 的配置模型围绕四个核心资源构建，它们共同定义了流量如何进入、路由、分发到最终目标。
| 资源 | 作用 | 类比 | 动态 API |
|---|---|---|---|
| Listener | 定义 Envoy 监听的 IP:Port 及协议（TCP/HTTP/gRPC） | “大门” | LDS |
| Route | 定义请求匹配规则（域名、路径、Header）与目标集群映射 | “路牌” | RDS |
| Cluster | 定义一组上游服务实例的集合及负载均衡策略 | “服务池” | CDS |
| Endpoint | Cluster 中的具体 IP:Port 实例，包含健康状态 | “池中水滴” | EDS |
实践要点：在 GitOps 流水线中，这四个资源通常对应 Kubernetes CRD（如 Istio VirtualService/DestinationRule）或直接映射为 Envoy 的 xDS JSON/YAML。同步窗口控制的是这些资源的版本切换时机。
3. Listener 与 Route：流量入口与分发
Listener 是流量的第一站。每个 Listener 绑定一个端口，并指定过滤器链（Filter Chain）来处理协议。最常见的过滤器是 HTTP 连接管理器（HCM），它负责解析 HTTP 请求并委托给 Route 进行匹配。
Route 定义匹配规则。一个 Route 配置包含：
- 虚拟主机（VirtualHost）：按域名分组，如
api.example.com。 - 路由规则（RouteMatch）：匹配路径前缀、正则、Header、Query 参数。
- 目标（RouteAction）：转发到指定 Cluster，或执行重定向、直接响应。
# 简化示例：Listener 绑定 8080，通过 HCM 委托给 Route
listeners:
- name: ingress_listener
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match: { prefix: "/api" }
route: { cluster: backend_cluster }
4. Cluster 与 Endpoint：服务发现与负载均衡
Cluster 定义如何连接上游服务。关键配置包括：
- 连接超时、健康检查（主动/被动）。
- 负载均衡策略：轮询（Round Robin）、最少请求（Least Request）、一致性哈希（Ring Hash）、随机（Random）。
- 端点发现类型：静态（Static）、DNS（Strict DNS/Logical DNS）、动态（EDS）。
Endpoint 是 Cluster 下的具体实例。在 Kubernetes 中，每个 Pod IP:Port 就是一个 Endpoint。Envoy 通过 EDS 实时获取 Endpoint 列表，并剔除不健康的实例。
注意：在 GitOps 场景中，Endpoint 的变更频率最高（Pod 扩缩容、滚动更新）。如果每次 Endpoint 变化都触发全量同步，会浪费大量资源。推荐使用 EDS 增量推送，仅传递变化的端点。
5. xDS 协议：动态配置的神经系统
xDS 是 Envoy 与外部控制面之间的一组 gRPC/REST 协议，用于动态发现配置。每个资源类型对应一个独立的发现服务：
| 协议 | 全称 | 发现内容 | 典型更新频率 |
|---|---|---|---|
| LDS | Listener Discovery Service | 监听器配置 | 低（新增/修改端口时） |
| RDS | Route Discovery Service | 路由规则 | 中（灰度发布、路由变更） |
| CDS | Cluster Discovery Service | 集群定义 | 低（新增/删除服务时） |
| EDS | Endpoint Discovery Service | 端点列表 | 高（Pod 扩缩容、滚动更新） |
| SDS | Secret Discovery Service | TLS 证书 | 低（证书轮换时） |
xDS 支持两种推送模式：
- 全量推送（SotW）：每次更新发送完整资源列表，简单但带宽开销大。
- 增量推送（Delta）：仅发送变更的资源，适合高频变化的 EDS 场景，是生产环境推荐模式。
6. 小结：Envoy 配置热更新的基础
理解 Envoy 的架构与核心概念是掌握 GitOps 同步窗口与流水线集成的先决条件：
- Listener + Route 定义了流量的入口与分发规则，对应 GitOps 中的“路由配置”版本。
- Cluster + Endpoint 定义了服务实例与负载均衡，对应“服务发现”版本。
- xDS 协议 提供了动态配置的标准化接口，使得控制面可以按需推送增量更新，实现零停机配置热更新。