原文地址：https://www.envoyproxy.io/docs/envoy/latest/api-docs/xds_protocol

xDS REST and gRPC protocol

envoy可通过文件系统、一个或多个管理服务器来发现各种动态资源。这些服务发现和他们相对应的API统称为xDS。通过定阅方式获取资源,如监控指定的文件路径、gRPC流或轮询REST-JSON URL。后两种使用DiscoveryRequest来发送请求消息。所有的资源包含在DiscoveryResponse响应消息中。下面,我们将讨论每种订阅类型。

1. 资源类型

xDS API中的每个配置资源都有一个与之关联的类型。资源类型遵循版本控制方案。

v2 xDS的资源如下：

• envoy.api.v2.Listener

• envoy.api.v2.RouteConfiguration

• envoy.api.v2.ScopedRouteConfiguration

• envoy.api.v2.route.VirtualHost

• envoy.api.v2.Cluster

• envoy.api.v2.ClusterLoadAssignment

• envoy.api.v2.Auth.Secret

• envoy.service.discovery.v2.Runtime

下面会提到类型URL的概念，它采用type.googleapis.com/<资源类型>的格式。例如，对于cluster资源，其类型为type.googleapis.com/envoy.api.v2.Cluster。envoy的各种请求和管理服务器的响应中都声明了资源类型URL。

2. 文件订阅

实现动态配置的最简单的方法就是把配置文件放在ConfigSource中指定的一个众所周知的路径中。Envoy将使用inotify （ macOS上的kqueue ）来监视文件的更改，并在更新时解析文件中的DiscoveryResponse原型。DiscoveryResponse响应支持二进制protobufs、JSON、YAML和proto文本格式。

对于文件系统订阅超过stats计数器和日志的ACK/NACK更新，没有可用的机制。如果发生配置拒绝更新，那么xDS API的最后一个有效配置将继续应用。

3. gRPC流订阅

3.1 api流程

对于典型的HTTP路由场景，客户端配置的核心资源类型是Listener,RouteConfiguration,Cluster和ClusterLoadAssignment。每个Listener资源可以指向一个RouteConfiguration资源，RouteConfiguration资源可以指向一个或多个Cluster资源，每个Cluster资源可以指向一个ClusterLoadAssignment资源。

envoy在启动时获取所有Listener和Cluster资源。然后，它获取Listener和Cluster资源所需的任何RouteConfiguration和ClusterLoadAssignment资源。实际上，每个Listener或Cluster资源都是特使配置树的一部分的根。

非代理客户机（如gRPC）可能从只获取它感兴趣的特定Listener资源开始。然后获取这些Listener资源所需的RouteConfiguration资源，然后获取这些RouteConfiguration资源所需的任何Cluster资源，最后获取ClusterLoadAssignment资源请求

3.2 xDS传输协议的变种

3.2.1 四个变种

流GRPC使用的xDS传输协议有四个变体，涵盖二维的所有组合。

第一个方面是全量（State of the World）和增量。全量方法是由xDS使用的最初机制，其中客户端必须在每个请求中指定它感兴趣的所有资源名称（在LDS/CDS中发出通配符请求时除外），并且服务器必须返回客户端在每次请求中订阅的所有资源（ (在LDS/CDS中）。这意味着如果客户机已经订阅了99个资源，并且想添加一个额外的资源，那么它必须发送一个包含所有100个资源名称的请求，而不仅仅是一个新资源名称。然后服务器必须发送所有100个资源进行响应，即使已经订阅的99个资源没有改变（在LDS / CDS中）。这种机制可能是一个可伸缩性限制，这就是为什么引入了增量式协议变体的原因。增量方法允许客户端和服务器仅指示相对于其先前状态的增量，即客户端可以声明它希望添加或删除对特定资源名称的订阅，而无需重新发送那些未更改的订阅。服务器只能发送那些已更改的资源的更新。增量协议还提供了一种延迟加载资源的机制。关于增量协议，请参见下文的增量xDS。

第二个方面是针对每种资源类型使用单独的gRPC流，而不是将所有资源类型聚合到单个gRPC流中。前一种方法是xDS使用的原始机制，它提供了最终的一致性模型。对于需要显式控制顺序的环境，增加了后一种方法。有关详细信息，请参阅下面的最终一致性注意事项。

因此，xDS传输协议的四个变体是：

• 全量xDS：SotW，为每种资源类型提供单独的gRPC流

• 增量xDS：增量的、针对每种资源类型的单独的gRPC流。

• 全量ADS：SotW，所有资源类型的聚合流

• 增量ADS：所有资源类型的增量聚合流。

3.2.2 各变体RPC服务及方法

对于非聚合协议变体，每种资源类型都有一个单独的RPC服务。每个RPC服务都可以为全量和增量协议变体提供一个方法。下面是每种资源类型的RPC服务和方法：

Listener：监听器发现服务(LDS)

- 全量：ListenerDiscoveryService.StreamListener

- 增量：ListenerDiscoveryService.DeltaListeners

RouteConfiguration：路由发现服务(RDS) 

- 全量: RouteDiscoveryService.StreamRoutes 

- 增量: RouteDiscoveryService.DeltaRoutes

ScopedRouteConfiguration：范围路由发现服务（SRDS）

- 全量: ScopedRouteDiscoveryService.StreamScopedRoutes 

- 增量: ScopedRouteDiscoveryService.DeltaScopedRoutes

VirtualHost：虚拟主机发现服务(VHDS) 

- 全量: N/A 

- 增量: VirtualHostDiscoveryService.DeltaVirtualHosts

Cluster: 集群发现服务 (CDS) 

- 全量: ClusterDiscoveryService.StreamClusters 

- 增量: ClusterDiscoveryService.DeltaClusters

ClusterLoadAssignment: 终端发现服务 (EDS) 

- 全量: EndpointDiscoveryService.StreamEndpoints 

- 增量: EndpointDiscoveryService.DeltaEndpoints

Secret: 秘密发现服务 (SDS) 

- 全量: SecretDiscoveryService.StreamSecrets 

- 增量: SecretDiscoveryService.DeltaSecrets

Runtime: 运行期发现服务 (RTDS) 

- 全量: RuntimeDiscoveryService.StreamRuntime 

- 增量: RuntimeDiscoveryService.DeltaRuntime

在聚合协议变体中，所有资源类型复用在单个gRPC流上，其中每个资源类型被视为聚合流中的独立逻辑流。实际上，它只是通过将每种资源类型的请求和响应作为单个聚合流上的一个单独的子流来处理，将上述所有单独的API组合到一个单独的流中。聚合协议变种的RPC服务和方法包括：

全量：AggregatedDiscoveryService.StreamAggregatedResources

增量：AggregatedDiscoveryService.DeltaAggregatedResources

所有全量方法的请求类型为DiscoveryRequest，响应类型为DiscoveryResponse。

增量增量方法的请求类型为DeltaDiscoveryRequest，响应类型为DeltaDiscoveryResponse。

3.2.3 配置使用哪个变体

在xDS API中，ConfigSource消息指示如何获取特定类型的资源。

如果ConfigSource包含GRPC ApiConfigSource，那么它将指向管理服务器的上游集群；这将为每个xDS资源类型启动一个独立的双向GRPC流，潜在地指向不同的管理服务器。

如果ConfigSource包含AggregatedConfigSource，则它告诉客户端使用ADS。

目前，希望为客户机提供一些本地配置，告诉它如何获取监听器和群集资源。其中，监听资源可以包括指示如何获取RouteConfiguration资源的ConfigSource，集群资源可以包括指示如何获取ClusterLoadAssignment资源的ConfigSource。

3.2.4 客户端配置

在envoy中，bootstrap文件包含两个ConfigSource消息，一个指示如何获取Listener资源，另一个指示如何获取Cluster资源。它还包含一个单独的ApiConfigSource消息，指示如何联系ADS服务器，当ConfigSource消息（无论是在引导文件中，还是在从管理服务器获得的监听器或群集资源中）包含AggregatedConfigSource消息时，将使用该消息。

在使用xDS的GRPC客户端中，只支持ADS，bootstrap文件中包含ADS服务器名称，所有资源都使用ADS服务器名称。Listener和Cluster资源中的ConfigSource消息必须包含AggregatedConfigSource消息。

3.3 xDS传输协议

3.3.1 传输API版本

除了上面描述的资源类型版本之外，xDS线路协议还有一个与之相关的传输版本。这为诸如DiscoveryRequest和DiscoveryResponse之类的消息提供了类型版本控制。

3.3.2 ACK/NACK和资源实例版本控制

每个xDS流以来自客户端的DiscoveryRequest开始，指定要订阅的资源列表、与订阅的资源对应的类型URL、节点标识符和一个空的version_info。

除了上述在类型级别运行的资源和传输类型版本控制计划之外，envoy还拥有一个资源实例版本。与资源/传输类型不同，这不是API的一个属性，而是通过xDS交付的命名资源的特定修订的反映。

一个EDS request的例子如下：

version_info:
node: { id: envoy }
resource_names:
- foo
- bar
type_url: type.googleapis.com/envoy.api.v2.ClusterLoadAssignment
response_nonce:

管理服务器可以立即回复，也可以在请求的资源可用时回复，例如，使用DiscoveryResponse。

version_info: X
resources:
- foo ClusterLoadAssignment proto encoding
- bar ClusterLoadAssignment proto encoding
type_url: type.googleapis.com/envoy.api.v2.ClusterLoadAssignment
nonce: A

3.3.3 ACK

如果更新应用成功，则version_info为X，如序列图所示：

3.3.4 NACK

如果Envoy拒绝了配置更新X，它将用error_detail填充及其先前的版本（在本例中是空的初始版本）进行答复。error_detail在message字段中填充的确切错误消息周围有更详细的信息：

在时序图中，使用如下格式进行消息缩写：

• DiscoveryRequest: (V=version_info,R=resource_names,N=response_nonce,T=type_url)

• DiscoveryResponse: (V=version_info,R=resources,N=nonce,T=type_url)
  

在NACK后，新版本的API更新成功。：

3.3.5 ACK/NACK语义汇总

• xDS客户端应该从管理服务器接收到每个发现响应ACK或NACK。

• 像所有其他请求一样，来自DiscoveryResponse的nonce作为response_nonce发送。如资源更新中所述，在某些竞争条件下使用所述随机数来消除ACK和NACK之间的歧义。

• ACK表示配置更新成功，并包含来自DiscoveryResponse的version_info。

• NACK表示配置更新失败，并包含先前（现有）的version_info。

• 只有NACK应该填充error_detail。

3.3.6 多版本控制和节点标识

；；；

3.3.7 何时发送更新

；；；

3.3.8 客户端如何指定返回哪些资源

；；；

3.3.9 客户端行为

；；；

3.3.10 响应分组

；；；

3.3.11 删除资源

；；；

3.3.12 请求的资源不存在

；；；

3.3.13 退订资源

；；；

3.3.14 单流多资源请求

；；；

3.3.15 资源更新

；；；

3.4 资源变暖

；；；

3.5 聚合发现服务

；；；

3.6 增量xDS

；；；

4. 轮询REST-JSON订阅

略