Envoy 基础:架构、xDS 协议与核心资源概念

Envoy 是云原生服务网格的数据面核心组件,以高性能 C++ 实现,专为大规模微服务通信而设计。理解 Envoy 的架构、配置协议以及核心资源模型,是掌握服务网格成本优化的前提——错误的配置不仅导致延迟增加,还会造成不必要的资源消耗。

Envoy 整体架构

Envoy 采用单进程多线程架构,主线程负责配置管理与统计收集,工作线程处理实际网络 I/O。其内部模块分为三层:

  • Listener(监听器)层:接收来自下游(客户端)的入站连接,支持 TCP、HTTP、TLS 等协议。
  • Filter(过滤器)链层:对流量进行拦截、观测、路由、改写等处理,是 Envoy 可扩展性的核心。
  • Cluster(集群)层:管理上游(后端服务)的连接池、负载均衡、健康检查与熔断。
成本视角: 工作线程数、连接池大小、过滤器链长度直接影响 CPU 与内存开销。生产环境中建议按 2 × CPU 核数 设置工作线程,避免线程争抢导致的性能退化。
Envoy 内部架构分层图 Envoy 内部架构分层 Listener 层 接收下游连接 · 端口绑定 · TLS 终止 · 协议检测 Filter 链层 HTTP 路由 · RBAC · 限流 · 日志 · 故障注入 · 观测 可插拔 · 链式执行 · 影响延迟与 CPU 开销 Cluster 层 连接池 · 负载均衡 · 健康检查 · 熔断 · 统计 配置变更通过 xDS 动态下发,无需重启进程

xDS 协议:动态配置的神经中枢

xDS(Discovery Service)是 Envoy 与控制面(如 Istiod)之间的标准配置协议。控制面通过 gRPC 流或 REST 推送资源,Envoy 实时热更新,无需重启。核心 xDS 类型包括:

xDS 类型 全称 管理资源 成本影响
LDS Listener Discovery Service Listener 配置(端口、协议、过滤器链) 过多 Listener 增加内存与文件描述符
RDS Route Discovery Service HTTP 路由规则(域名、路径、权重) 路由表过大导致匹配延迟上升
CDS Cluster Discovery Service Cluster 定义(端点发现方式、负载均衡策略) Cluster 数量影响连接池内存
EDS Endpoint Discovery Service 后端实例 IP:Port 列表 端点频繁变更触发大量连接重建
SDS Secret Discovery Service TLS 证书与私钥 证书轮换频率影响 CPU
优化建议: 在 GitOps 同步窗口内,将 LDS/RDS/CDS/EDS 的更新合并为一次批量推送,避免逐条下发导致的控制面与数据面 CPU 尖峰。

核心资源概念:Listener / Cluster / Endpoint

这三个资源构成了 Envoy 流量路由的三角模型:

  • Listener:定义 Envoy 在哪个 IP:Port 上监听,以及如何处理入站流量。每个 Listener 可绑定多个 Filter 链。
  • Cluster:定义一组提供相同服务的上游主机,以及连接池、负载均衡策略(轮询、最少请求、一致性哈希等)。
  • Endpoint:Cluster 下的具体后端实例(IP + 端口),通常由 EDS 动态发现,也可静态配置。
Listener / Cluster / Endpoint 三角关系 Listener → Cluster → Endpoint 三角关系 Listener 0.0.0.0:8080 · HTTP 路由规则 Cluster service-backend · 轮询 EDS 发现 Endpoint 1 10.0.1.5:8080 Endpoint 2 10.0.1.6:8080 Endpoint 3 10.0.1.7:8080 一个 Listener 可路由到多个 Cluster;一个 Cluster 可包含多个 Endpoint

Envoy 在服务网格中的位置

在 Istio 服务网格中,Envoy 以 Sidecar 代理 的形式注入到每个 Pod 中,形成数据面。控制面 Istiod 通过 xDS 向所有 Envoy 下发配置。Envoy 承担以下关键职责:

  • 流量拦截与转发:通过 iptables 规则劫持 Pod 的入站和出站流量,全部经过 Envoy 处理。
  • 服务间通信安全:自动启用 mTLS,加密所有网格内流量。
  • 可观测性:生成详细的访问日志、指标(Prometheus)和分布式追踪(Jaeger/Zipkin)。
  • 流量管理:实现金丝雀发布、超时重试、熔断、限流等高级路由策略。
成本陷阱: 每个 Sidecar 默认占用约 50–100 MB 内存。在 1000 个 Pod 的集群中,仅 Sidecar 就消耗 50–100 GB 内存。通过精细化配置(如裁剪不必要的 Filter、调整连接池大小)可降低 30%–50% 的资源开销。

Envoy 配置示例(静态)

以下是一个最小静态配置,展示 Listener、Cluster 和 Endpoint 的声明方式:

static_resources:
  listeners:
  - name: listener_http
    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: "/" }
                route: { cluster: service_backend }
          http_filters:
          - name: envoy.filters.http.router

  clusters:
  - name: service_backend
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: service_backend
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address: { address: 10.0.1.5, port_value: 8080 }
        - endpoint:
            address:
              socket_address: { address: 10.0.1.6, port_value: 8080 }
成本优化点: 静态配置适合小规模测试环境。生产环境务必使用 xDS 动态下发,避免配置变更导致 Envoy 重启,造成连接中断和 CPU 尖峰。

小结