1 - xDS基本术语
在深入了解xDS之前，必须了解 xds 和 envoy 使用的术语。
基本术语
官方文档
以下内容来自envoy官方文档:
https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology
A few definitions before we dive into the main architecture documentation. Some of the definitions are slightly contentious within the industry, however they are how Envoy uses them throughout the documentation and codebase, so c’est la vie.
在我们深入了解主要的架构文档之前，有几个定义。其中一些定义在行业内略有争议，但这些定义是Envoy在整个文档和代码库中的使用方式，所以这就是生活。
Host: An entity capable of network communication (application on a mobile phone, server, etc.). In this documentation a host is a logical network application. A physical piece of hardware could possibly have multiple hosts running on it as long as each of them can be independently addressed.
主机: 一个能够进行网络通信的实体（手机上的应用程序、服务器等）。在本文档中，主机是逻辑网络应用。一个物理硬件上可能有多个主机在运行，只要它们能独立寻址。
Downstream: A downstream host connects to Envoy, sends requests, and receives responses.
下游：下游主机连接到Envoy，发送请求并接收响应。
Upstream: An upstream host receives connections and requests from Envoy and returns responses.
上游: 上游主机接收来自Envoy的连接和请求并返回响应。
Listener: A listener is a named network location (e.g., port, unix domain socket, etc.) that can be connected to by downstream clients. Envoy exposes one or more listeners that downstream hosts connect to.
监听器: 监听器是命名的网络位置（例如：端口、unix domain socket等），可以被下游客户端连接。Envoy暴露一个或多个监听器，下游主机可以连接到这些监听器。
Cluster: A cluster is a group of logically similar upstream hosts that Envoy connects to. Envoy discovers the members of a cluster via service discovery. It optionally determines the health of cluster members via active health checking. The cluster member that Envoy routes a request to is determined by the load balancing policy.
集群：集群是Envoy连接到的逻辑上相似的一组上游主机。Envoy通过服务发现来发现集群的成员。它可以选择通过主动健康检查来确定集群成员的健康状况。Envoy通过负载平衡策略决定将请求路由到某个集群成员。
Mesh: A group of hosts that coordinate to provide a consistent network topology. In this documentation, an “Envoy mesh” is a group of Envoy proxies that form a message passing substrate for a distributed system comprised of many different services and application platforms.
网格：协调提供一致网络拓扑结构的一组主机。在本文档中，“Envoy mesh"是一组Envoy代理，它们构成了分布式系统的消息传递基础，这个分布式系统由很多不同服务和应用程序平台组成。
Runtime configuration: Out of band realtime configuration system deployed alongside Envoy. Configuration settings can be altered that will affect operation without needing to restart Envoy or change the primary configuration.
运行时配置：外置实时配置系统，和 Envoy 一起部署。可以更改配置设置，影响操作，而无需重启 Envoy 或更改主要配置。
对术语的理解
下面这个图可以更好的帮助理解上述术语的概念和含义：
- 主机/上游/下游：请求由下游主机发起，envoy通过监听器接收到请求之后转发给上游主机
- 符合转发要求的上游主机可能有多个，这多个上游主机被称为"集群”，envoy通过负载均衡算法选择其中进行请求转发
其他术语
和xDS相关的其他概念还有：
| 概念 | 描述 |
|---|---|
| Management Server | 实现v2 Envoy API的逻辑服务器。 这不一定是单个物理机器，因为它可以被复制/分片， 并且用于不同xDS API的API服务可以在不同的物理机器上实现。 |
区域概念
| Concept | 概念 | 描述 |
|---|---|---|
| Locality | 区域性 | Envoy实例或端点运行的位置。这包括地域/region，分区/zone和子分区/sub-zone标识。 |
| Region | 地域 | 分区（zone）所在的地理区域。 |
| Zone | 分区 | AWS中的Availability Zone (AZ), GCP中的Zone |
| Sub-zone | 子分区 | Envoy实例或端点在分区内运行的位置。这允许在分区内存在多个负载均衡目标。 |
术语的中文翻译
envoy和xds的术语在翻译中文时，为了保持一致，建议遵循envoy文档翻译小组的约定：
https://github.com/cloudnativeto/envoy/blob/zh/docs/root/term.md
参考文档
- https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/intro/terminology
- https://www.servicemesher.com/envoy/intro/arch_overview/terminology.html：servicemesher社区翻译的envoy官方文档中文版本
- Envoy v2 APIs for developers: 在这里还补充有其他一些术语，但这个文章地址失效了，新版本中尚没有找到对应的内容。TODO：待查找。
2 - xDS核心概念
监听器、路由、集群和端点是xDS的四个核心概念。
Envoy代理模式：请求转发
xDS的术语中定义了主机、上游、下游等概念，这些是envoy作为代理的基本工作模式：请求转发。即接收一个来自下游主机的请求，然后根据各种逻辑进行处理和决策，最后将请求转发给某个上游主机。
请求转发相关的xDS概念
| Concept | 概念 | 描述 |
|---|---|---|
| Listener | 监听器 | 监听器是命名网地址（例如，端口、unix domain socket等)，可以被下游客户端连接。Envoy 暴露一个或者多个监听器给下游主机连接 |
| Router | 路由 | 路由是一组将虚拟主机(virtual hosts)与群集(cluster)匹配的规则(rule)，允许您创建流量转移规则 |
| Cluster | 集群 | 集群是指 Envoy 连接到的逻辑上相同的一组上游主机 |
| Endpoint | 端点 | Envoy将“端点(Endpoint)”定义为群集(Cluster)中可用的IP和端口 |
转发概念示意图如下：
Listener
Listener：Envoy工作的基础 简单理解，Listener是Envoy打开的一个监听端口，用于接收来自Downstream（客户端）连接。Envoy可以支持复数个Listener。多个Listener之间几乎所有的配置都是隔离的。Listener配置中核心包括监听地址、Filter链等。
Listener对应的配置/资源发现服务称之为LDS。LDS是Envoy正常工作的基础，没有LDS，Envoy就不能实现端口监听（如果启动配置也没有提供静态Listener的话），其他所有xDS服务也失去了作用。
Router
Router：上下游之间的桥梁 Listener可以接收来自下游的连接，Cluster可以将流量发送给具体的上游服务，而Router则决定Listener在接收到下游连接和数据之后，应该将数据交给哪一个Cluster处理。它定义了数据分发的规则。虽然说到Router大部分时候都可以默认理解为HTTP路由，但是Envoy支持多种协议，如Dubbo、Redis等，所以此处Router泛指所有用于桥接Listener和后端服务（不限定HTTP）的规则与资源集合。
Route对应的配置/资源发现服务称之为RDS。Router中最核心配置包含匹配规则和目标Cluster，此外，也可能包含重试、分流、限流等等。
Cluster
Cluster：对上游服务的抽象 在Envoy中，每个Upstream上游服务都被抽象成一个Cluster。Cluster包含该服务的连接池、超时时间、endpoints地址、端口、类型（类型决定了Envoy获取该Cluster具体可以访问的endpoint方法）等等。
Cluster对应的配置/资源发现服务称之为CDS。一般情况下，CDS服务会将其发现的所有可访问服务全量推送给Envoy。与CDS紧密相关的另一种服务称之为EDS。CDS服务负责Cluster资源的推送。而当该Cluster类型为EDS时，说明该Cluster的所有endpoints需要由xDS服务下发，而不使用DNS等去解析。下发endpoints的服务就称之为EDS。
Endpoint
xDS和请求转发概念的对应关系
在Envoy v2 API中，RDS路由指向集群，CDS提供集群配置，通过EDS发现集群成员。
xDS API 示意图如下：
参考文档
3 - xDS的ADS
为什么有了LDS/RDS/CDS/EDS，还要引入ADS？
4 - envoy的filter机制
Envoy通过Filter机制提供了极为强大的可扩展能力。
Filter：强大源于可扩展
Filter，通俗的讲，就是插件。通过Filter机制，Envoy提供了极为强大的可扩展能力。在Envoy中，很多核心功能都使用Filter来实现。比如对于Http流量和服务的治理就是依赖HttpConnectionManager（Network Filter，负责协议解析）以及Router（负责流量分发）两个插件来实现。利用Filter机制，Envoy理论上可以实现任意协议的支持以及协议之间的转换，可以对请求流量进行全方位的修改和定制。强大的Filter机制带来的不仅仅是强大的可扩展性，同时还有优秀的可维护性。Filter机制让Envoy的使用者可以在不侵入社区源码的基础上对Envoy做各个方面的增强。
Filter本身并没有专门的xDS服务来发现配置。Filter所有配置都是嵌入在LDS、RDS以及CDS（Cluster Network Filter）中的。
参考文档：
5 - 增量xDS
增量xDS
增量xDS
Envoy通过xDS协议与控制面实现配置数据的交换。当控制面检测中配置变化（比如通过Kubernetes Watch到新service或者其他的CRD资源更新），会向Envoy发送一个discoveryResponse来将更新后的配置下发到Envoy。之后，Envoy主线程在接受到数据之后，通过向各个工作线程中追加配置更新事件来完成配置的实际更新和生效。
但是，需要注意的是，控制面下发的discoveryResponse是一个全量的配置。换言之，哪怕是修改了一条路由中的一个小小请求头匹配，所有Listener、Cluster、Router都必须更新，Envoy会用接受到的新配置替换旧配置。使用现有更新方案虽然逻辑简单明了，但是在负载较多、配置量较大时，会造成大量的流量浪费和不必要的计算开销。
尤其是对于Sidecar模式下的Envoy，该问题会更加的明显。网格中服务需要访问其他服务时，其流量首先会被Envoy Sidecar所拦截，之后由Sidecar将请求转发给对应的服务。由于Sidecar并不了解其代理的服务依赖网格中哪些其他服务，所以它会记录服务网格中所有服务的相关信息。但是，事实上一个网格服务往往只会依赖网格中少量的几个服务。
因为上述问题，Envoy社区提出了delta xDS方案，实现增量的xDS配置更新。简单的说，在delta增量更新方案中，当配置发生变化时，只有发生变化的一项配置（配置的最小单位为一个完整的proto message）需要下发和更新。
基于delta增量更新方案，可以实现以下三种新的功能：
- Lazy loading：按照具体需要订阅相关资源。全量xDS中，每个Envoy Sidecar都会缓存大量的Cluster配置，但是实际部分Cluster从未被访问过，甚至将数据流量导向此类Cluster的相关路由配置都不存在，此类的Cluster配置只会浪费内存和降低Envoy效率。使用delta增量更新方案，可以在实际的配置被使用时再订阅该资源，从控制面获取相关配置（首次访问性能会受到一定影响）。
- 增量更新：当部分资源更新时，如某个Cluster配置发生变化，某条Router修改了参数，那么只有对应的Cluster或Router配置会被下发和更新。在负载较多、配置量较大时，该功能可以有效减少网络内因配置更新而引入的数据流量。
- 缓存擦除（或者说on demand loading**）**：根据Envoy当前负载实际请求动态调整订阅资源类型，对于不再活跃的配置，取消订阅，从Envoy内存中擦除，直到相关配置再次被使用。通过该功能，可以有效限制Envoy配置所占用的数据量，在超大规模应用场景中，可以有效减少Envoy内存开销。
参考文档：