【Envoy 数据面】数据面全景：从 Listener 到 xDS 的可编程代理内核

站内 Envoy 架构剖析 已经把线程模型、Filter Chain 与 xDS 名词铺成一张地图；网关选型 与 Service Mesh 回答「要不要上 Envoy / Sidecar」。读者仍缺一角：一次连接如何穿过 Listener → FilterChainMatch → Network/HTTP filter → Router → Upstream，以及「控制面已推送」如何变成 Worker 上可服务的配置快照——或为何仍会黑洞。

本文是「Envoy / 数据面代理内核」系列第 1 篇，只做三件事：

1. 画出 Envoy 相对静态配置代理、节点级 Envoy、eBPF 数据面的生态位。
2. 钉住后续章节共用的五条坐标系，并交代设计谱系与开放争论。
3. 给出与站内系列的分工，以及 16 篇阅读路线。

本文是「Envoy / 数据面代理内核」系列第 1 篇（共 16 篇）。→ 系列目录

篇目	核心内容
第 1 篇 · 数据面全景	生态位、主线坐标系、系列路线
第 2 篇 · Main / Worker	配置快照与几乎无锁
第 3–6 篇 · 接入路径	Listener → HCM → Router
第 9–11 篇 · xDS	资源树、ACK、warming

版本锚定：Envoy v1.39.0（2026-07-14）官方 Architecture overview / Threading model 与同 tag 源码树。本篇以定位与路线为主，不粘贴未执行的 config_dump / stats 输出。

一、生态位：Envoy 补哪一角

Nginx / HAProxy 擅长「配置文件驱动的高性能转发」；Service Mesh 选型文讨论的是部署税；Cilium 节点级 Envoy 讨论的是「何时把 L7 从 sidecar 挪到节点」。它们优化的瓶颈不同——格子不是互斥，而是默认把什么当一等公民。

flowchart TB
  subgraph proxies ["Proxy paradigms"]
    NGX["Nginx / HAProxy<br/>file-driven L4/L7"]
    ENV["Envoy<br/>API-driven filter dataplane"]
    NODE["Per-node Envoy<br/>Cilium L7 redirect"]
    EBPF["eBPF L3/L4<br/>kernel datapath"]
  end
  subgraph control ["Control / product layers"]
    MESH["Service Mesh / Gateway<br/>architecture 76 / network 60"]
  end
  NGX -.->|"need dynamic config + rich L7"| ENV
  EBPF -.->|"L7 policy redirect"| NODE
  NODE --> ENV
  ENV --> MESH

一句话：本系列占住「API 驱动、Filter 可编程、配置可热更新的数据面内核」那一格——不替代网关选型表，也不重写控制面产品手册。

主线引擎取 Envoy v1.39.0：文档与源码 tag 对齐，适合做「从 accept 到 ACK」的连续拆解。Istio / Gateway API 只在边界篇出现，避免第 1 篇变成控制面目录。

二、设计谱系：API 驱动数据面从哪分叉

2.1 工作定义

本系列默认的 Envoy 数据面：

• Listener：接受连接；经 listener filters 与 FilterChainMatch 选中一条 filter chain。
• Network filter：在连接字节流上工作；HTTP Connection Manager（HCM） 是最常见的 L7 入口。
• HTTP filter：在已解码的请求/响应事件上工作；Router 通常是链上的终端过滤器，负责选 cluster、发往上游。
• Cluster / Endpoint：上游逻辑组与具体地址；连接池、熔断、outlier 挂在这一层。
• xDS：控制面通过 LDS/RDS/CDS/EDS/SDS（及 ADS 聚合）推送上述对象。

这与「只会 proxy_pass」共享「反向代理」一词，但运行时不变量不同：Envoy 把动态配置与过滤器组合做成一等路径，而不是「改文件 → reload」。

2.2 学术与工程谱系（本系列回指）

1. 可编程中间盒 / 软件数据面：从早期用户态代理与 NFV 叙事，到把策略从静态配置挪到 API——Envoy 公开设计强调 universal data plane 与动态发现，而不是再做一个「更好的 Nginx 配置方言」。
2. 事件驱动与几乎无共享状态：官方 Threading model 钉死「连接绑定到单个 Worker 终生」；跨线程协调集中在 Main 与 Thread Local Storage（TLS）快照更新。这与 libevent 系 Reactor 同宗，但多了配置分发与 xDS 状态机。
3. xDS 作为配置协议：资源类型形成依赖树（Listener 指向 Route，Route 指向 Cluster，Cluster 指向 Endpoint）；SotW（State-of-the-World）与 Incremental/Delta 是同一问题的两种推送经济学——第 10 篇展开。

谱系收束句：产品层争论「要不要 Mesh」；内核层争论「动态配置与 Filter 组合的语义是否可审计」。 后者才是本系列主战场。

2.3 开放争论（先立靶，后各章拆）

三、五条坐标系（后续章节回指）

后面每一篇都会落到下面某一条轴上。第 1 篇只钉名字，不展开源码。

3.1 请求路径轴

accept → listener filters → FilterChainMatch → network filters
      → (HCM) codec → HTTP filters → Router → upstream pool → response path

延迟与 5xx 的归因必须先回答：卡在匹配、编解码、过滤器、路由，还是上游池？ → 第 3–8、15 篇。

3.2 线程与快照轴

Main 处理 xDS / Admin / stats 刷新；Worker 跑事件循环。配置经 TLS 槽位分发为每线程可读快照。Worker 热路径上几乎不为「读配置」加全局锁——但快照切换的时机与引用计数决定「新旧配置并存窗口」。→ 第 2、11–12 篇。

3.3 匹配与改写轴

Listener filters（TLS Inspector、Proxy Protocol、original_dst 等）在 创建 Connection / 选 FilterChain 之前 enrich 元数据。选错 chain 表现为「连上了但协议全错」，不是「upstream 挂了」。→ 第 3–4 篇。

3.4 xDS 一致性轴

资源有依赖：Listener 可能等 Route warming；Cluster 可能等 Endpoint。ACK 表示「客户端接受了这次更新的协议语义」，不等于「所有依赖已就绪、流量已切到新路由」。黑洞与旧路由多落在这条轴。→ 第 9–11、15 篇。

3.5 上游资源轴

Cluster 上的连接数、挂起请求、outlier 驱逐、熔断阈值，决定「路由选对了仍 503」。→ 第 7–8、15 篇。

四、与站内系列的分工

五、16 篇地图与阅读建议

最小路径：01 → 02 → 03 → 06 → 09 → 15。
联调控制面：再补 10 → 11 → 12。
做网关选型：01 → 14 → 16，并外链 60 / 76。

六、参考资料（本篇）

规范 / 官方文档（A）

• Envoy Proxy, Architecture overview / Threading model, docs for v1.39.0（或同版本 docs 树；避免未标明的 latest-dev 断言）。
• Envoy Proxy, xDS REST and gRPC protocol（资源类型与依赖叙述）。

源码（A）

• envoyproxy/envoy tag v1.39.0：source/server/、source/common/（后续篇钉具体路径）。

站内对照

• Envoy 架构剖析
• 网关选型
• Service Mesh

实验台账

• 本篇无命令输出；不写 QPS / 延迟数字。

七、小结

1. Envoy 的生态位是 API 驱动、Filter 可编程的数据面，不是「又一个静态反向代理」。
2. 五条坐标系（请求路径、线程快照、匹配改写、xDS 一致性、上游资源）是后续排障的共用语言。
3. 与 57 的分工：单篇建立地图；本系列回答路径与「配置已下发却未生效」。
4. 开放争论先立靶：推送经济学、部署形态、扩展隔离——各章用机制拆，不提前做产品排名。

→ 系列目录 · 下一篇：Main / Worker 与配置快照