Envoy 基础回顾：架构概览与核心配置
在深入故障注入与自动化回滚护栏之前，必须牢固掌握 Envoy 的基础架构与配置模型。Envoy 并非简单的代理，而是一个高性能、可编程的 L3/L4/L7 数据平面，其核心设计围绕 Listener、Cluster、Route 三大抽象展开，并通过 xDS 协议实现动态、热更新的配置管理。本节将系统回顾这些基础概念，为后续的故障注入实验奠定坚实的知识基础。
Envoy 架构概览
Envoy 采用单进程多线程架构，主线程负责配置管理与统计刷新，工作线程通过非阻塞事件循环处理网络 I/O。其内部组件按功能分层，形成清晰的数据处理流水线。
核心设计原则： Envoy 将数据平面与控制平面解耦。数据平面负责高效转发，控制平面（如 Istiod）通过 xDS 协议下发配置，使得 Envoy 可以在不重启进程的情况下动态调整路由、负载均衡、故障注入等行为。
三大核心配置：Listener / Cluster / Route
Envoy 的静态或动态配置围绕三个核心资源构建。理解它们之间的关系是编写任何 Envoy 配置（包括故障注入策略）的前提。
| 配置资源 | 作用域 | 关键字段 | 与故障注入的关系 |
|---|---|---|---|
| Listener | 定义 Envoy 监听的 IP:Port 及协议 | address, filter_chains, listener_filters |
故障注入过滤器挂载在 Listener 的 HTTP 连接管理器过滤器链中 |
| Cluster | 定义上游服务集群（后端实例组） | hosts, lb_policy, circuit_breakers, health_checks |
故障注入的目标是发往 Cluster 的流量；断路器与健康检查影响故障注入的可见性 |
| Route | 定义请求匹配规则与转发目标 | match, route, weighted_clusters, request_headers_to_add |
故障注入可以按路由粒度（特定 path、header、vCluster）生效 |
配置层次提示： 一个 Listener 可以包含多个 Route Table；一个 Route 可以指向多个 Cluster（通过权重路由）。故障注入过滤器通常配置在 HTTP Connection Manager 的
http_filters 数组中，位于 Router 过滤器之前。
xDS 协议与动态配置
xDS（Discovery Service）是 Envoy 动态配置的核心协议族。控制平面（如 Istiod、Kong Mesh、自定义控制面）通过 gRPC 流或 REST-JSON 将配置推送到 Envoy 节点，实现零停机配置更新。
主要的 xDS 资源类型包括：
- LDS (Listener Discovery Service) — 动态下发 Listener 配置。
- RDS (Route Discovery Service) — 动态下发 Route 配置。
- CDS (Cluster Discovery Service) — 动态下发 Cluster 配置。
- EDS (Endpoint Discovery Service) — 动态下发 Cluster 的端点（后端实例 IP:Port）列表。
- SDS (Secret Discovery Service) — 动态下发 TLS 证书与密钥。
配置示例：静态配置中的故障注入
以下是一个简化的 Envoy 静态配置片段，展示了 Listener、Route、Cluster 以及故障注入过滤器的基本结构。在实际生产环境中，这些配置通常通过 xDS 动态下发。
static_resources:
listeners:
- name: ingress_listener
address:
socket_address: { address: 0.0.0.0, port_value: 8080 }
filter_chains:
- filters:
- 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: "/api" }
route: { cluster: backend_cluster }
http_filters:
- name: envoy.filters.http.fault
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.http.fault.v3.HTTPFault
delay:
fixed_delay: 5s
percentage: { numerator: 10, denominator: HUNDRED }
abort:
http_status: 503
percentage: { numerator: 5, denominator: HUNDRED }
- name: envoy.filters.http.router
clusters:
- name: backend_cluster
connect_timeout: 0.25s
type: STRICT_DNS
lb_policy: ROUND_ROBIN
load_assignment:
cluster_name: backend_cluster
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address: { address: backend-service, port_value: 3000 }
配置顺序关键： 在
http_filters 列表中，故障注入过滤器必须位于 Router 过滤器之前。如果顺序颠倒，故障注入将不会生效，因为请求在到达故障注入过滤器之前已经被路由并转发到上游。
Envoy 配置模型与自动化回滚护栏的关联
理解 Envoy 的架构与配置模型，是设计自动化回滚护栏测试验证方案的基础。以下表格总结了关键关联点：
| Envoy 概念 | 在回滚护栏测试中的角色 |
|---|---|
| Listener + HCM | 故障注入过滤器的挂载点；测试验证需要确认过滤器是否按预期注入到指定 Listener 的过滤器链中 |
| Route 匹配 | 按 path、header、method 等条件限定故障注入范围；回滚护栏需验证匹配逻辑是否在配置更新后仍正确 |
| Cluster + 端点 | 故障注入的目标上游；回滚护栏需验证故障注入是否仅影响目标 Cluster，而不影响其他 Cluster 的流量 |
| xDS 动态更新 | 回滚护栏的核心场景：模拟故障注入配置的推送、验证 Envoy 热更新后的行为、检测配置回滚是否及时恢复 |