2. Envoy xDS 协议基础：xDS 全生命周期、SotW 与 Incremental 模式对比

在 Service Mesh 升级场景中，配置下发延迟是影响服务可用性的核心风险点。要精准定位延迟根因，必须深入理解 Envoy 与控制面（如 Istiod、Kuma CP）之间的通信协议——xDS（Discovery Service）。本章将系统梳理 xDS 的全生命周期，并对比两种主流下发模式：SotW（State of the World）与Incremental（增量），为后续延迟排查奠定协议层基础。

2.1 xDS 协议全生命周期

xDS 并非单一协议，而是一组基于 gRPC 流式通信的发现服务集合，涵盖监听器（LDS）、路由（RDS）、集群（CDS）、端点（EDS）、秘密（SDS）等。其核心生命周期可归纳为以下五个阶段：

1. 订阅（Subscription）：Envoy 启动或配置变更时，向控制面发起特定资源类型的 gRPC 流请求，携带 node 标识与 resource_names 列表。
2. 推送（Push）：控制面根据订阅请求，计算并组装当前全量或增量资源版本，通过 DiscoveryResponse 消息下发。
3. 确认（ACK/NACK）：Envoy 收到响应后，校验资源合法性（如 schema、依赖完整性）。校验通过则应用并回复 ACK（携带新版本号）；失败则回复 NACK（携带错误信息与拒绝版本号）。
4. 收敛（Convergence）：控制面收到 ACK 后更新该 Envoy 的版本水位；收到 NACK 后根据策略重试或回滚。
5. 热更新（Warm-up）：Envoy 对新配置进行预热（如建立连接池、DNS 解析），完成后正式切换流量。

2.2 SotW（全量）模式

SotW（State of the World）是 xDS 协议最经典的下发模式。控制面每次推送时，将指定资源类型的全部资源对象一次性下发给 Envoy，Envoy 用新配置完全替换旧配置。

核心特征

• 全量替换：每次响应包含该类型所有资源，Envoy 直接覆盖本地缓存。
• 版本驱动：控制面维护全局版本号，Envoy 通过 version_info 判断是否需要更新。
• 简单可靠：逻辑清晰，Envoy 无需维护增量状态，控制面也无需跟踪每个 Envoy 的差异。

升级场景中的延迟风险

2.3 Incremental（增量）模式

Incremental（增量）模式（xDS v3 原生支持）只推送发生变更的资源，Envoy 在本地缓存基础上进行增删改操作，无需全量替换。

核心特征

• 增量更新：响应中仅包含新增、修改、删除的资源列表，通过 resources 和 removed_resources 字段标识。
• 无版本号依赖：增量模式使用 system_version_info 和资源级别的版本，Envoy 按资源粒度确认。
• 低开销：控制面只需计算差异，Envoy 只需局部更新，网络传输量大幅降低。

升级场景中的优势

2.4 升级场景中的模式选择建议

在 Service Mesh 升级过程中，选择哪种 xDS 模式直接影响配置下发延迟。以下是基于生产经验的建议：

• 小规模集群（< 500 服务）：SotW 模式足够，延迟通常在毫秒级，且实现简单，便于排查。
• 中大规模集群（500-2000 服务）：强烈建议启用 Incremental 模式，可降低 60%-80% 的推送延迟。
• 超大规模集群（> 2000 服务）：必须使用 Incremental 模式，并配合资源分片（Shard）和限流策略，否则全量推送可能导致控制面 OOM 或 Envoy 预热超时。
• 升级过渡期：如果控制面版本不支持 Incremental（如 Istio 1.10 以下），建议先升级控制面至支持增量模式的版本，再逐步升级数据面。

2.5 延迟排查的关键指标

无论使用哪种模式，以下指标是定位配置下发延迟的核心依据：