1.2.5　xDS协议

图1-3所示为Service Mesh的控制平面，读者在了解服务网格时可能看到过，每个方块代表一个服务的实例，例如，Kubernetes中的一个Pod（其中包含了Sidecar 代理）。xDS协议控制了Istio服务网格中所有流量的具体行为，即将图1-3中的方块链接到了一起。

图1-3

xDS协议是由Envoy提出的，在Envoy v2版本的API中最原始的xDS协议指的是CDS（Cluster Discovery Service）、EDS（Endpoint Discovery Service）、LDS（Listener Discovery Service）和RDS（Route Discovery Service），后来在Envoy v3版本中xDS协议又发展出了Scoped Route Discovery Service（SRDS）、Virtual Host Discovery Service（VHDS）、Secret Discovery Service（SDS）、Runtime Discovery Service（RTDS）。

下面通过两个服务的通信了解xDS协议，如图1-4所示。

图1-4

图1-4中的箭头不是流量进入Proxy后的路径或路由，也不是实际顺序，而是虚拟的一种xDS接口处理顺序。其实在各个xDS协议之间也是有交叉引用的。

支持xDS协议的代理可以通过查询文件或管理服务器动态发现资源。概括地讲，这些发现服务及其相应的API被称作xDS。Envoy通过订阅（Subscription）方式获取资源，订阅方式有以下3种。

•文件订阅：监控指定路径下的文件。发现动态资源的最简单方式就是将其保存于文件中，并将路径配置在configSource中的path参数中。

•gRPC流式订阅：每个xDS API可以单独配置ApiConfigSource，指向对应的上游管理服务器的集群地址。

•轮询REST-JSON轮询订阅：单个xDS API可以对REST端点进行同步（长）轮询。

Istio使用gRPC流式订阅的方式配置所有的数据平面的Sidecar Proxy。下面总结关于xDS协议的要点。

•CDS、EDS、LDS、RDS是最基础的xDS协议，都可以独立更新。

•所有的发现服务（Discovery Service）可以连接不同的管理服务，也就是说管理xDS的服务器可以有多个。

•Envoy在原始xDS协议的基础上进行了一系列扩充，增加了SDS（密钥发现服务）、ADS（聚合发现服务）、HDS（健康发现服务）、MS（Metric服务）、RLS（速率限制服务）等API。

•为了保证数据一致性，若直接使用xDS原始API，则需要保证按照CDS→EDS→LDS→RDS的顺序更新。这是遵循电子工程中的先合后断（Make-Before-Break）原则的，即在断开原来的连接之前先建立好新的连接，应用在路由里就是为了防止在设置了新的路由规则时无法发现上游集群而导致流量被丢弃的情况，类似于电路里的断路。

•CDS用于设置服务网格中有哪些服务。

•EDS用于设置哪些实例（Endpoint）属于这些服务（Cluster）。

•LDS用于设置实例上监听的端口以配置路由。

•RDS是最终服务间的路由关系，应该保证最后更新RDS。