Istio XDS 配置生成实现

Envoy 按照使用场景可以分为 3 种。

1）model.Sidecar：Sidecar 模式，和应用服务一块部署在容器中，对进出应用服务的流量进行拦截。2）model.Router：Router 模式，作为独立的代理服务，对应用的 L4/L7 层流量进行代理。3）model.Ingress：Ingress 模式，作为集群入口的 Ingress 代理，对集群的入口流量进行拦截和代理。

其中，Router 模式与 Ingress 模式均属于和应用服务不在一起部署的纯代理场景，在 XDS 配置方面没有任何区别，因此从 XDS 响应消息生成的角度看，可以归为一类，称为 Gateway 模式。

对于 Sidecar 模式来说，Envoy 负责服务出入方向流量的透明拦截，并且出入方向的流量在监听管理、路由管理等方面有很大的区别，因此 Sidecar 的 XDS 配置均按照出入方向分别进行组织和管理。入流量一般称为 Inbound，出流量一般称为 Outbound。

由于 Router 模式和 Ingress 模式均属于单独的代理模式，在 XDS 配置管理方面没有大的差异，可以统一为 Gateway 模式，因此在 XDS 管理配置上可以划分为 Sidecar Inbound 模式、Sidecar Outbound 模式和 Gateway 模式。

这几个模式下的 XDS 配置生成的方式也都比较类似，首先获取当前模式下 Sidecar 对应的服务列表，然后基于服务列表，拼装相应的 XDS 信息。

1. Inbound Sidecar

Inbound 方向代表的是发往本节点的流量，同时 Inbound 只会将请求转发到和当前 Sidecar 部署在同一个部署单元上的服务节点上，因此 Inbound 方向的集群信息和路由信息都比较确定，只需要获取到当前 Sidecar 节点对应的服务信息即可。

对于 HTTP 来说，这里会拼装 HTTP 对应的路由信息，具体包含 clusterName 集群信息和 VirtualHost 信息。由于 Inbound 方向使用单一的集群、单一的 VirtualHost，并且集群固定只有一个节点信息（本机节点），因此 Inbound 方向的路由查找和流量转发比较确定。Inbound 方向的 VirtualHost 称为“Inbound|http|instance.Endpoint.ServicePort.Port”。

对于 TCP 来说，Inbound 方向的路由信息当前未按照具体的协议类型进行区分，直接通过 TCP Proxy 的方式进行路由，这样只能进行全局的统计和管控，无法对 Inbound 方向的流量进行协议相关的链路治理和管控。

2. Outbound Sidecar

Outbound 方向代表的是从当前节点发往本节点外的流量，因此首先需要获取当前节点服务对应的上游服务列表，对于有作用域相关设置的 Sidecar 来说，需要根据作用域设置获取服务列表，对于没有作用域相关设置的 Sidecar 来说，返回的是注册中心的所有服务列表，因此当集群和服务规模比较大时，为了减少大量无效的 XDS 交互，需要设置相应的作用域信息。

获取到服务列表之后，需要根据服务当前支持的协议信息进行 XDS 响应消息的拼装，对于 HTTP 协议来说，一般通过 80 端口号对外提供服务，因此多个 HTTP Outbound 服务可以共用一个监听器“0.0.0.0：80”，使用统一的 HTTPConnManager 对不同 HTTP Outbound 服务进行管理，使用 80 端口号作为 Rds 配置的 RouteConfigName，Rds 对应的具体路由配置由 RDS 协议负责解析。

由于具体的应用协议不同，TCP 协议并且不像 HTTP 协议那样拥有知名端口号，因此无法直接使用端口号作为监听器标识。对于这类协议，一般会采用虚拟 IP 地址作为服务的监听标识。

3. Gateway

对于 Gateway 模式来说，Gateway 对应的服务信息和路由信息通过 Istio 核心资源 Gateway 指定。Gateway 节点配置生成时，首先根据当前 Gateway 节点的工作负载标签，获取匹配的 Gateway 核心资源列表，然后将这些核心资源列表进行合并处理，产出一个逻辑的 Gateway，逻辑 Gateway 包括 Gateway 节点 XDS 配置生成需要的元数据信息，根据这些信息就可以拼装生成相应的 XDS 响应消息。