【Envoy 数据面】数据面全景：从 Listener 到 xDS 的可编程代理内核
内容提要
本文是Envoy数据面代理内核系列的首篇，介绍Envoy作为API驱动、Filter可编程的数据面代理的定位。文章规划了16篇阅读路线，并确立了五条分析坐标系：请求路径、线程快照、匹配改写、xDS一致性及上游资源。同时讨论了与站内其他文章的分工及开放争论，为后续深入解析Envoy机制奠定基础。
延伸解读
五条坐标系：排障的共用语言
文章提出用请求路径、线程快照、匹配改写、xDS 一致性、上游资源五条轴来分析 Envoy。这五条轴不是抽象概念，而是排障时的具体切入点：延迟或 5xx 要先定位是卡在匹配、编解码、过滤器、路由还是上游池；配置已下发但未生效，要检查 xDS 一致性和 warming 状态。后续章节都会回指这些轴，读者可将其作为理解 Envoy 机制和排查问题的框架。
ACK 不等于配置生效：xDS 一致性的陷阱
文章强调，xDS 的 ACK 只表示客户端接受了更新后的协议语义，并不代表所有依赖已就绪、流量已切到新路由。由于资源间存在依赖（如 Listener 依赖 Route，Cluster 依赖 Endpoint），配置推送后可能出现黑洞或旧路由继续服务的情况。理解这一点有助于避免误判“配置已下发”就等于“已生效”，也是后续章节重点拆解的内容。
API 驱动 vs 文件驱动：运维模式的分野
Envoy 与 Nginx/HAProxy 的本质区别在于，Envoy 将动态配置和过滤器组合作为一等公民，而非“改文件→reload”。这带来热更新和统一控制面的优势，但也牺牲了配置可 diff 进 Git 的简单性。文章将这一争论列为开放问题，并计划在后续章节用 warming/ACK 机制来讨论，而非简单比较延迟。读者可据此权衡两种模式在自身场景中的适用性。
Q&A
Envoy 数据面代理与 Nginx/HAProxy 这类静态配置代理的核心区别是什么？
Envoy 是 API 驱动、Filter 可编程的数据面代理，支持动态配置和热更新，而 Nginx/HAProxy 是配置文件驱动的高性能转发，主要依靠修改文件并 reload 来更新配置。Envoy 将动态配置和过滤器组合作为一等公民，而不是静态配置。
Envoy 数据面代理内核系列文章规划了多少篇？五条分析坐标系是什么？
该系列共规划了 16 篇。五条分析坐标系包括：请求路径轴、线程与快照轴、匹配与改写轴、xDS 一致性轴、上游资源轴。
Envoy 中一次请求从进入到返回的完整路径是怎样的？
请求路径为：accept → listener filters → FilterChainMatch → network filters → (HCM) codec → HTTP filters → Router → upstream pool → response path。
Envoy 的线程模型是怎样的？为什么热路径上几乎无锁？
Envoy 采用事件驱动模型，每个连接绑定到单个 Worker 线程终生。跨线程协调集中在 Main 线程和 Thread Local Storage (TLS) 快照更新。配置通过 TLS 槽位分发为每线程可读快照，因此 Worker 热路径上几乎不需要为读配置加全局锁。
Envoy 中 xDS 的 ACK 表示什么？为什么 ACK 后流量仍可能走旧路由？
ACK 表示客户端接受了这次更新的协议语义，但不等于所有依赖已就绪、流量已切到新路由。因为资源有依赖关系，例如 Listener 可能等待 Route warming，Cluster 可能等待 Endpoint，如果依赖未就绪，流量可能仍走旧路由或出现黑洞。
Envoy 中 Cluster 上的哪些因素会导致路由选对了仍然返回 503？
Cluster 上的连接数、挂起请求、outlier 驱逐、熔断阈值等因素，可能导致即使路由正确，上游请求仍然失败并返回 503。
Envoy 的开放争论中，API 驱动与文件驱动各有什么优缺点？
API 驱动支持热更新和统一控制面，但运维复杂度高；文件驱动运维简单、配置可 diff 进 Git，但更新需要 reload。Envoy 属于 API 驱动，本系列后续章节会用 warming/ACK 机制来讨论，不做延迟排行。
