2. Envoy 架构基础：核心组件、线程模型与配置热加载

Envoy 是 Istio 服务网格的数据面核心，其架构设计围绕高性能、可扩展和动态配置展开。理解 Envoy 的四大核心组件（Listener、Cluster、Endpoint、Filter）、线程模型以及配置热加载机制，是进行故障注入与隔离验证的理论基础。

2.1 核心组件与数据流

Envoy 采用四层（L4）与七层（L7）代理混合架构，其核心组件构成了一条完整的请求处理流水线。下图展示了请求从进入 Envoy 到被转发至上游服务的完整路径。

2.1.1 组件职责对比

2.2 线程模型：主线程 + Worker 线程

Envoy 采用 单进程多线程 架构，核心设计原则是 无共享（shared-nothing）。主线程负责配置管理和协调，Worker 线程负责实际的 I/O 和请求处理。

2.3 配置热加载与 xDS 协议

Envoy 支持两种配置更新方式：热重启（Hot Restart） 和 动态 xDS（Discovery Service）。在 Istio 环境中，xDS 是主要方式。

2.3.1 配置更新方式对比

2.3.2 xDS 资源类型与故障注入关系

• LDS (Listener Discovery Service)：动态下发 Listener 配置，包括 Filter 链。故障注入 Filter 的插入和移除通过 LDS 实时更新。
• RDS (Route Discovery Service)：动态下发路由规则。故障注入的百分比、延迟时长、错误码等参数在 VirtualHost 或 Route 级别配置。
• CDS (Cluster Discovery Service)：动态下发 Cluster 配置。用于故障域隔离时切换上游集群。
• EDS (Endpoint Discovery Service)：动态下发 Endpoint 列表。用于摘除故障实例或调整权重。

{
  "name": "envoy.filters.http.fault",
  "typed_config": {
    "@type": "type.googleapis.com/envoy.extensions.filters.http.fault.v3.HTTPFault",
    "delay": {
      "fixed_delay": "5s",
      "percentage": {
        "numerator": 50,
        "denominator": "HUNDRED"
      }
    }
  }
}

2.4 架构总结与演练映射

Envoy 的组件化设计使得故障注入和隔离验证可以精确控制在以下维度：

• 入口维度：通过 Listener 和 Filter 链，在请求进入时注入故障。
• 路由维度：通过 RDS 动态调整路由规则，将流量导向故障集群或正常集群。
• 上游维度：通过 CDS/EDS 动态摘除故障 Endpoint，实现实例级隔离。
• 线程维度：Worker 线程的独立性保证了故障注入不会影响其他 Worker 的正常连接。