📚 课程目录第4章 Envoy基础架构回顾

4. Envoy 基础架构回顾：Listener、Cluster、Endpoint、Route 配置模型

Envoy 的流量治理能力建立在四层核心资源模型之上：Listener（监听器）、Cluster（集群）、Endpoint（端点）和 Route（路由）。理解这四者的关系与配置方式是掌握 Envoy 流量控制工程的前提。本章从故障域隔离的视角重新梳理这一基础架构，为后续章节的灰度发布、熔断限流、故障注入等高级场景打下坚实的配置基础。

4.1 四层资源模型概述

Envoy 的配置模型可以抽象为一个“入口 → 路由 → 集群 → 端点”的线性数据流。每个层次承担独立的职责，并通过 xDS 协议（如 LDS、RDS、CDS、EDS）动态下发，实现控制面与数据面的解耦。

资源类型	xDS 协议	核心职责	故障域隔离作用
Listener	LDS	定义 Envoy 监听的端口、协议、过滤器链	按端口/协议隔离入口流量，避免不同服务共享监听
Route	RDS	定义请求匹配规则（域名、路径、Header）与目标集群	按路由规则隔离流量路径，实现灰度/蓝绿分流
Cluster	CDS	定义上游服务集群的连接池、负载均衡、健康检查策略	按集群隔离后端服务，独立配置熔断、超时、重试
Endpoint	EDS	定义集群中的具体后端实例（IP:Port）及状态	按端点粒度隔离故障实例，支持主动/被动健康检查

关键认知：在集群升级场景中，故障域隔离的本质就是在这四个层次上分别设置“隔离边界”。例如，通过 Route 将 10% 流量路由到新版本集群，通过 Cluster 为新版本集群配置更短的超时时间，通过 Endpoint 标记异常实例并自动摘除。

4.2 Listener：流量入口的故障隔离边界

Listener 是 Envoy 接收外部流量的第一道关卡。每个 Listener 绑定一个 IP 地址和端口，并挂载一组过滤器链（Filter Chain）。在故障域隔离设计中，Listener 的隔离策略包括：

端口隔离：不同服务使用不同端口监听，避免单一端口故障影响所有服务。
协议隔离：HTTP、TCP、gRPC 等协议使用不同的 Listener 配置，防止协议解析异常扩散。
过滤器链隔离：通过 FilterChainMatch 按 SNI、ALPN、源 IP 等条件匹配不同过滤器链，实现租户级隔离。

# Listener 配置示例：按端口隔离两个服务
static_resources:
  listeners:
  - name: http_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 80 }
    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: "/" }
                route: { cluster: backend_cluster }
  - name: admin_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 9901 }
    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
          codec_type: AUTO
          stat_prefix: admin
          route_config:
            name: admin_route
            virtual_hosts:
            - name: admin
              domains: ["*"]
              routes:
              - match: { prefix: "/" }
                route: { cluster: admin_cluster }

4.3 Cluster：后端服务的故障隔离单元

Cluster 是 Envoy 对上游服务组的抽象。每个 Cluster 独立管理连接池、负载均衡算法、健康检查、熔断器和超时配置。在集群升级中，Cluster 是故障域隔离的核心单元：

版本隔离：为旧版本和新版本分别创建独立的 Cluster，通过 Route 控制流量比例。
熔断隔离：每个 Cluster 独立配置熔断阈值，避免一个版本的故障拖垮整个网关。
健康检查隔离：不同 Cluster 使用不同的健康检查策略（如 HTTP 健康检查 vs TCP 健康检查）。

# Cluster 配置示例：两个版本独立集群
clusters:
- name: backend_v1_cluster
  connect_timeout: 0.25s
  type: STRICT_DNS
  lb_policy: ROUND_ROBIN
  load_assignment:
    cluster_name: backend_v1_cluster
    endpoints:
    - lb_endpoints:
      - endpoint:
          address:
            socket_address: { address: 10.0.1.10, port_value: 8080 }
  circuit_breakers:
    thresholds:
    - priority: DEFAULT
      max_connections: 100
      max_pending_requests: 10
      max_requests: 1000
      max_retries: 3
- name: backend_v2_cluster
  connect_timeout: 0.5s
  type: STRICT_DNS
  lb_policy: LEAST_REQUEST
  load_assignment:
    cluster_name: backend_v2_cluster
    endpoints:
    - lb_endpoints:
      - endpoint:
          address:
            socket_address: { address: 10.0.2.10, port_value: 8080 }
  circuit_breakers:
    thresholds:
    - priority: DEFAULT
      max_connections: 50
      max_pending_requests: 5
      max_requests: 500
      max_retries: 1

4.4 Endpoint：实例级别的故障隔离粒度

Endpoint 是 Cluster 中的具体后端实例。Envoy 通过 EDS 动态管理 Endpoint 的加入、移除和状态变更。在故障域隔离中，Endpoint 层提供最细粒度的控制：

主动健康检查：Envoy 定期向 Endpoint 发送健康探测请求，失败后自动标记为 unhealthy。
被动健康检查（异常检测）：基于连续 5xx 响应、连接超时等指标，动态将异常 Endpoint 踢出负载均衡池。
端点权重：通过权重控制流量分配到不同 Endpoint 的比例，实现金丝雀发布时的实例级灰度。

常见陷阱：在集群升级期间，如果只依赖 Endpoint 层的健康检查而忽略 Cluster 层的熔断配置，当大量 Endpoint 同时进入“抖动”状态时，健康检查风暴可能导致控制面负载飙升。建议在 Cluster 层设置合理的熔断阈值，在 Endpoint 层设置合理的健康检查间隔和异常检测参数。

4.5 Route：流量调度与故障转移的决策层

Route 位于 Listener 和 Cluster 之间，负责将请求匹配到目标 Cluster。Route 配置是故障域隔离中最灵活的一层，支持多种匹配条件和流量控制策略：

路由特性	故障域隔离应用场景	配置示例
权重路由	金丝雀发布：10% 流量到新版本 Cluster	`weighted_clusters` 指定多个 Cluster 及权重
Header 匹配	按用户身份/请求来源隔离流量	`headers: {name: "x-canary", value: "true"}`
路径前缀匹配	按 API 版本隔离后端服务	`prefix: "/v2/"` 路由到 v2 Cluster
故障转移	主 Cluster 不可用时自动切换到备用 Cluster	`request_mirror_policy` 或 `retry_policy`

# Route 配置示例：基于权重和 Header 的灰度路由
route_config:
  name: gray_route
  virtual_hosts:
  - name: backend
    domains: ["*"]
    routes:
    - match:
        prefix: "/"
        headers:
        - name: "x-version"
          exact_match: "v2"
      route:
        cluster: backend_v2_cluster
    - match:
        prefix: "/"
      route:
        weighted_clusters:
          clusters:
          - name: backend_v1_cluster
            weight: 90
          - name: backend_v2_cluster
            weight: 10

4.6 四层模型协同工作流

下面通过一张内联 SVG 图展示 Envoy 四层资源模型在集群升级场景中的协同工作流，突出故障域隔离的边界划分：

4.7 配置模型与 xDS 协议的关系

Envoy 的配置模型通过 xDS 协议实现动态下发，这是实现故障域隔离工程化的关键基础设施。下表总结了四层资源与 xDS 协议的对应关系及动态更新能力：

资源类型	xDS 协议	动态更新方式	故障域隔离价值
Listener	LDS	全量更新或增量更新（Incremental LDS）	不停机修改监听端口或添加新协议入口
Route	RDS	按 VirtualHost 粒度更新	实时调整灰度流量比例，无需重启 Envoy
Cluster	CDS	全量更新或增量更新	动态添加/删除集群，实现版本隔离
Endpoint	EDS	按 LocalityLbEndpoints 粒度更新	秒级摘除故障实例，保障可用性

  工程实践建议：在集群升级场景中，推荐优先使用 EDS 动态调整 Endpoint 权重来实现金丝雀发布，而不是频繁修改 Route 配置。因为 EDS 变更只影响目标 Cluster 内的实例分布，不会触发 Route 层的全量路由重算，控制面压力更小，收敛速度更快。

4.8 本章小结

Envoy 的 Listener、Route、Cluster、Endpoint 四层配置模型构成了流量治理的完整骨架。从故障域隔离的角度看：

Listener 负责入口隔离，按端口/协议划分故障边界。
Route 负责流量调度隔离，支持权重、Header、路径等多种灰度策略。
Cluster 负责后端服务隔离，独立配置熔断、超时、健康检查。
Endpoint 负责实例级隔离，通过主动/被动健康检查实现故障自愈。