【Envoy 数据面】选型收束：机制排除树与系列开放问题
内容提要
本文总结Envoy数据面代理内核系列终章，提出选型排除树：先判断是否需要动态L7策略与xDS，再对比Nginx/HAProxy、Sidecar、节点级Envoy及eBPF的机制差异。强调Envoy优势在于可ACK配置与Filter组合，并讨论部署形态、开放问题（如xDS规模、Sidecar税、Wasm、HTTP/3）及阅读路径回收，主张以机制而非跑分选型。
延伸解读
排除树的核心：先问机制，再谈选型
文章提出的排除树强调，选型不应从品牌或性能跑分出发，而应先判断是否需要动态L7策略与xDS。若不需要，Nginx/HAProxy的文件reload路径可能更合适；若需要，再进一步考虑Filter链、xDS树等。这一机制导向的决策框架，有助于避免因“云原生”等模糊理由而盲目采用Envoy。
混合部署的代价：两套排障坐标
文章指出，边缘用Envoy做L7入口、东西向L4交给eBPF/CNI、少数服务保留sidecar的混合部署是常见实践，但代价是必须维护两套排障坐标。这意味着排障时需明确流量先进了哪一层，并分别应用相应的观测与诊断工具，增加了运维复杂度。
开放问题：用机制语言量化，而非跑分
系列开放问题如xDS规模、Sidecar税、Wasm、HTTP/3分叉等，文章主张用机制语言去量化，例如测量ACK延迟分布、sidecar RSS、Wasm p99增量、QUIC特有失败旗标，而不是再写无口径的延迟排行榜。这为后续研究或实践提供了具体方向。
Q&A
Envoy 选型排除树的第一步是什么？
先判断是否需要动态 L7 策略和通过 API 热更新的配置（即 xDS）。如果不需要，则倾向于选择 Nginx/HAProxy 这类文件驱动配置的代理；如果需要，再进一步判断是否需要 Filter 链和丰富的 L7 能力。
在什么情况下应该选择 Nginx/HAProxy 而不是 Envoy？
当主路径是稳定的 L4/L7 转发，配置变更可以通过文件与受控 reload 完成，且不需要完整的 xDS 控制面时，应选择 Nginx/HAProxy。Envoy 的优势在于动态配置和 Filter 组合，如果缺乏可持续的 xDS 控制面，强行使用 Envoy 反而会增加复杂度。
Sidecar Envoy、节点级 Envoy 和 eBPF 在部署形态上有什么区别？
Sidecar Envoy 为每个工作负载部署一个代理，策略贴近负载，但代价是内存、跳数和配置扇出；节点级 Envoy 通过 BPF/重定向将 L7 流量收至每节点共享代理，减少每 Pod 的税，但存在节点容量和多租户干扰问题；eBPF 在内核处理 L3/L4，不解析完整 HTTP 语义，适合仅需 L4 身份和路径的场景。三者不是互斥品牌，内核可能仍是同一套 Envoy 机制。
Envoy 相比 Nginx/HAProxy 在配置和扩展模型上有哪些核心优势？
Envoy 以 xDS 资源树为核心，支持配置的 warming 和 ACK 确认，扩展模型包括 Network/HTTP filter、Wasm 和外置服务；而 Nginx/HAProxy 以文件配置为主，扩展依赖模块或 Lua。Envoy 的优势在于动态配置和 Filter 组合，适合需要控制面持续推送和按请求组合策略的场景。
混合部署中，边缘用 Envoy、东西向用 eBPF 的常见模式有什么代价？
混合部署的代价是两套排障坐标：流量可能先进边缘 Envoy 再进入 eBPF 路径，排障时需要明确流量经过的每一层，增加了复杂度。
Envoy 系列文章提到的开放问题有哪些？
开放问题包括：xDS 规模与推送经济学（如 SotW 带宽与 Incremental 复杂度权衡）、Sidecar 税 vs 共享数据面、Wasm 扩展 vs 原生 Filter、HTTP/3/QUIC 与 TCP 路径分叉、可观测成本与归因上限。这些问题需要带着坐标系和排除树去量化，而不是简单比较延迟。
为什么说 Envoy 不是默认赢家？
Envoy 赢在动态配置、Filter 组合和可观测落点成为一等公民的时候；但如果运维只需要 Git 中可 diff 的配置文件，且没有控制面预算，Envoy 的优势就无法发挥，反而可能增加复杂度。
