3. Envoy动态配置：xDS协议（LDS、RDS、CDS、EDS）与控制平面交互原理
在服务网格架构中，Envoy 作为数据平面代理，其核心优势在于动态配置能力。Envoy 通过 xDS 协议（Discovery Service API）与控制平面（如 Istio Pilot、Consul Connect）进行实时交互，无需重启进程即可更新路由、监听器、集群和端点信息。本章深入剖析 xDS 协议的核心子协议及其交互流程。
3.1 xDS 协议族概述
xDS 并非单一协议，而是一组基于 gRPC 流式通信的发现服务集合。每个子协议负责管理 Envoy 配置的一个独立维度：
| 子协议 | 全称 | 管理资源 | 典型更新场景 |
|---|---|---|---|
| LDS | Listener Discovery Service | 监听器（Listener） | 新增/删除端口监听、修改 TLS 证书 |
| RDS | Route Discovery Service | 路由配置（RouteConfiguration） | 灰度发布、流量拆分、Header 路由 |
| CDS | Cluster Discovery Service | 集群（Cluster） | 新增/删除上游服务、修改负载均衡策略 |
| EDS | Endpoint Discovery Service | 端点（Endpoint） | Pod 扩缩容、健康检查状态变更 |
关键理解： LDS 是入口，RDS 是路由规则，CDS 是集群定义，EDS 是集群成员。四者形成从“流量接入”到“流量转发”的完整链路。
3.2 控制平面与数据平面的交互流程
Envoy 启动后，按照固定的依赖顺序向控制平面发起 xDS 请求。控制平面通过 gRPC 双向流推送增量或全量配置。下图展示了完整的交互架构：
3.3 四阶段交互详解
3.3.1 LDS（Listener Discovery Service）
Envoy 启动后，首先向控制平面发起 LDS 请求。控制平面返回所有需要监听的端口、协议类型（HTTP/TCP）、TLS 证书配置以及过滤器链。每个 Listener 对应一个入站流量入口。
- 请求时机： Envoy 启动时、监听器配置变更时。
- 响应内容： Listener 名称、地址、过滤器链（FilterChain）、TLS 上下文。
- 典型场景： 新增 Sidecar 注入端口、修改 mTLS 证书。
3.3.2 RDS（Route Discovery Service）
当 Listener 配置了 HTTP 连接管理器（HttpConnectionManager）且未内联路由时，Envoy 通过 RDS 获取路由规则。路由规则决定流量如何分发到不同的集群。
- 请求时机： Listener 引用 RouteConfiguration 名称时。
- 响应内容： 虚拟主机（VirtualHost）、路由匹配规则（Path/Header）、目标集群、流量权重。
- 典型场景： 金丝雀发布（5% 流量到 v2）、基于 Header 的灰度路由。
3.3.3 CDS（Cluster Discovery Service）
Envoy 根据路由规则中引用的集群名称，向控制平面请求 CDS。控制平面返回集群的完整定义，包括连接超时、负载均衡算法、熔断阈值等。
- 请求时机： 路由规则引用新集群时、集群配置更新时。
- 响应内容： 集群名称、连接池大小、负载均衡类型（ROUND_ROBIN / LEAST_REQUEST / RING_HASH）、健康检查配置。
- 典型场景： 修改熔断器参数、切换负载均衡策略。
3.3.4 EDS（Endpoint Discovery Service）
CDS 返回的集群若配置为 type: EDS，Envoy 会进一步请求 EDS 获取该集群的端点列表。端点即上游服务的实际 IP:Port 实例。
- 请求时机： CDS 返回 EDS 类型集群时、端点健康状态变化时。
- 响应内容： 端点 IP:Port、健康状态（HEALTHY / UNHEALTHY）、优先级、权重。
- 典型场景： Pod 扩缩容、故障实例自动摘除。
实践要点： 控制平面通常使用 ADS（Aggregated Discovery Service） 将 LDS/RDS/CDS/EDS 合并到同一个 gRPC 流中，减少连接数并保证配置更新的原子性。Istio 默认使用 ADS 模式。
3.4 增量 xDS 与全量 xDS
Envoy 支持两种 xDS 推送模式，控制平面可根据网络规模和变更频率选择：
| 特性 | 全量 xDS（SotW） | 增量 xDS（Delta） |
|---|---|---|
| 推送方式 | 每次推送完整资源列表 | 仅推送变更的资源 |
| 带宽消耗 | 高（资源量大时明显） | 低（仅传输差异） |
| Envoy 处理开销 | 全量替换，CPU 消耗较高 | 局部更新，CPU 消耗低 |
| 一致性保证 | 强（每次都是完整快照） | 依赖控制平面正确计算差异 |
| 推荐场景 | 小规模集群（< 100 服务） | 大规模集群（> 500 服务） |
3.5 交互时序与依赖关系
Envoy 的 xDS 请求遵循严格的依赖顺序，控制平面必须按序响应。下图展示了完整的时序流程：
3.6 控制平面实现对比
| 控制平面 | xDS 实现方式 | 增量支持 | ADS 支持 | 生态特点 |
|---|---|---|---|---|
| Istio Pilot | 基于 gRPC 流，支持 SotW 和 Delta | ✅ 是 | ✅ 是 | Kubernetes 原生，功能最全 |
| Consul Connect | 基于 gRPC 流，支持 SotW | ❌ 否 | ✅ 是 | 与 Consul 服务注册深度集成 |
| Kuma | 基于 gRPC 流，支持 SotW 和 Delta | ✅ 是 | ✅ 是 | 多集群、多租户支持好 |
| 自定义控制平面 | 基于 go-control-plane 库 | 可配置 | 可配置 | 灵活但开发成本高 |
避坑提示： 在自定义控制平面实现中，务必保证 xDS 响应顺序正确。如果先推送 CDS 再推送 LDS，Envoy 会因为找不到引用集群的 Listener 而丢弃配置，导致流量中断。推荐使用 ADS 保证原子性。