2. Envoy 基础架构：线程模型、核心概念与 xDS 协议
Envoy 作为高性能的七层代理，其架构设计围绕非阻塞事件驱动与动态配置下发展开。理解线程模型、核心抽象（Listener/Cluster/Endpoint）以及 xDS 协议，是掌握 Envoy 访问控制策略与运行基线核验的基础。
2.1 线程模型：单进程多线程架构
Envoy 采用 单进程多线程 模型，主线程负责配置管理与统计刷新，工作线程负责实际的 I/O 与请求处理。这种设计避免了多进程模型下的共享内存开销，同时通过线程绑定（Thread Affinity）实现高并发。
--concurrency 参数控制工作线程数，通常设置为物理 CPU 核心数。
2.2 三大核心抽象：Listener、Cluster、Endpoint
Envoy 的配置模型围绕三个核心概念构建，它们构成了流量处理的基本链路：Listener（监听器）→ Filter（过滤器链）→ Cluster（集群）→ Endpoint（端点）。
| 概念 | 角色 | 关键属性 | 访问控制关联 |
|---|---|---|---|
| Listener | 流量入口，监听端口并接收连接 | 地址、端口、过滤器链、TLS 上下文 | RBAC 过滤器、IP 白名单在此生效 |
| Cluster | 上游服务集群，定义连接目标与负载均衡策略 | 类型（EDS/STRICT_DNS/STATIC）、连接超时、健康检查 | 熔断、限流、异常检测在此配置 |
| Endpoint | 具体的后端实例（IP:Port） | 地址、端口、健康状态、元数据 | 通过元数据实现灰度路由与基线核验 |
2.2.1 Listener：流量入口
Listener 定义了 Envoy 如何接收来自下游的流量。每个 Listener 可以绑定多个端口，并通过 过滤器链（Filter Chain） 对流量进行匹配与处理。在访问控制场景中，envoy.filters.network.rbac 和 envoy.filters.http.rbac 过滤器通常挂载在 Listener 的过滤器链上。
listeners:
- name: ingress_listener
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
filter_chains:
- filters:
- name: envoy.filters.network.rbac
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.rbac.v3.RBAC
rules:
action: ALLOW
policies:
"allow-whitelist":
permissions:
- any: true
principals:
- remote_ip: { address_prefix: "10.0.0.0/8" }
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match: { prefix: "/" }
route: { cluster: backend_service }
http_filters:
- name: envoy.filters.http.router2.2.2 Cluster：上游服务集群
Cluster 定义了 Envoy 如何将请求转发到上游服务。它支持多种服务发现类型，其中 EDS（Endpoint Discovery Service） 是最灵活的方式，允许控制平面动态管理端点。Cluster 也是配置熔断、连接池、负载均衡策略的载体。
clusters:
- name: backend_service
type: EDS
eds_cluster_config:
eds_config:
resource_api_version: V3
api_config_source:
api_type: GRPC
transport_api_version: V3
grpc_services:
- envoy_grpc:
cluster_name: xds_cluster
connect_timeout: 0.25s
lb_policy: LEAST_REQUEST
circuit_breakers:
thresholds:
- priority: DEFAULT
max_connections: 1000
max_pending_requests: 5002.2.3 Endpoint：具体实例
Endpoint 是 Cluster 下的具体后端实例。在云原生环境中，Endpoint 通常对应 Pod 的 IP:Port。通过 端点元数据（Endpoint Metadata），Envoy 可以实现精细化的路由策略，例如将带有 version: v2 标签的请求只路由到元数据中包含 canary: true 的端点。
security_baseline: passed）是控制平面决策的重要依据。不满足基线的端点应被标记为 UNHEALTHY 或通过元数据过滤掉。
2.3 xDS 协议概述：动态配置的核心
xDS 是 Envoy 与控制平面之间的 发现服务（Discovery Service） 协议族。它基于 gRPC 流式传输，实现了配置的实时下发与热更新，无需重启 Envoy 进程。
2.3.1 核心 xDS 类型
| 协议 | 全称 | 资源内容 | 更新频率 |
|---|---|---|---|
| LDS | Listener Discovery Service | Listener 配置（端口、过滤器链、TLS） | 低（新增/删除监听端口时） |
| RDS | Route Discovery Service | 路由规则（域名、路径匹配、流量拆分） | 中（灰度发布、策略变更时） |
| CDS | Cluster Discovery Service | Cluster 配置（服务发现类型、熔断、负载均衡） | 中（新增/删除服务时） |
| EDS | Endpoint Discovery Service | Endpoint 列表（IP:Port、健康状态、元数据） | 高（Pod 扩缩容、滚动更新时） |
| SDS | Secret Discovery Service | TLS 证书、私钥 | 低（证书轮换时） |
2.3.2 xDS 工作流程
- 订阅（Subscribe）：Envoy 启动后，向控制平面（如 Istiod）发起 gRPC 流订阅请求，声明需要监听哪些资源类型（如 LDS、CDS）。
- 推送（Push）：控制平面将当前配置作为 初始快照（Initial Snapshot） 推送给 Envoy。
- 增量更新（Incremental Update）：当配置发生变化时，控制平面仅推送变更部分（Delta xDS），Envoy 热更新对应资源。
- ACK/NACK：Envoy 每次收到更新后，会回复 ACK（成功应用）或 NACK（校验失败），控制平面据此判断配置是否生效。
2.3.3 xDS 与访问控制策略的集成
在云原生运行基线核验场景中，xDS 协议扮演了 策略下发通道 的角色：
- LDS 携带 RBAC 规则：控制平面根据基线要求，动态生成包含 RBAC 过滤器的 Listener 配置，通过 LDS 下发给 Envoy。
- EDS 携带端点元数据：控制平面将基线核验结果（如
security_baseline: passed）写入 Endpoint 的元数据中，Envoy 根据元数据进行路由决策。 - CDS 携带熔断阈值：当基线核验发现某个服务异常时，控制平面可通过 CDS 动态调整该 Cluster 的熔断阈值，实现快速降级。