为什么要在 LDS/RDS/CDS/EDS 上引入 ADS？

Question

在 Envoy 的 XDS（e X tensible D iscovery S ervice）架构中，LDS（Listener Discovery Service）、RDS（Route Discovery Service）、CDS（Cluster Discovery Service）和 EDS（Endpoint Discovery Service）本来是 独立的服务接口 ，客户端（如 Envoy）可以分别去请求它们。但在实际使用中，这种方式存在一些问题，因此引入了 ADS（Aggregated Discovery Service） 。下面是为什么要引入 ADS 的原因：

1. 减少连接和资源开销

• 每一个 XDS 服务（LDS/RDS/CDS/EDS）都需要维护一个 gRPC 流（stream）连接。
• 如果一个 Envoy 实例分别与这四个服务建立连接，那就是 4 个 gRPC stream，占用更多资源。
• ADS 统一了接口，多个资源的推送都通过一个 gRPC 流完成，节省连接资源，提高效率。

2. 简化同步问题（状态一致性）

• LDS、RDS、CDS、EDS 之间有依赖关系，比如：
• LDS 中定义了 listener → 引用 RDS 中的 route_config → route_config 又引用 CDS 中的 cluster → cluster 引用 EDS 中的 endpoint。
• 如果分别通过独立的接口下发这些资源，会出现 状态不同步 的风险。
• 例如，下发了 listener，但 cluster 还没准备好，会导致临时找不到服务。
• ADS 能够在一个连接中统一下发多个资源， 保障下发顺序一致、状态原子性强 。

3. 便于控制面实现与版本控制

• 控制面（如 Istio Pilot）如果分别实现多个服务接口，会变得复杂。
• ADS 把所有资源聚合在一个接口中，只需要维护一套机制来处理请求和响应， 简化了控制面实现 。
• 支持统一的版本控制（如 version_info ）、一致的 ACK/NACK 机制，提高健壮性。

4. 支持增量和订阅机制

• 通过 ADS，Envoy 可以在一个流中声明它对哪些资源感兴趣，实现 动态资源订阅（Resource Subscriptions） 。
• 同时支持 增量更新（Incremental xDS） 和 按需资源加载（on-demand xDS） ，提高了网络和计算效率。

总结一句话

ADS 的引入是为了统一资源发现接口，减少连接开销，确保资源一致性，并简化控制面实现。