【Envoy 数据面】选型收束：机制排除树与系列开放问题

前 15 篇把 Envoy 钉成可排障的数据面内核：路径、快照、匹配、xDS、上游池、扩展与观测。选型若再写成「各有优劣看场景」，等于把机制丢掉。本文用机制排除树收束——先问不变量，再决定要不要 Envoy、以什么形态部署。

本文是「Envoy / 数据面代理内核」系列第 16 篇（终章）：对照 Nginx/HAProxy 与 sidecar / 节点 Envoy / eBPF，回收系列阅读路径，并列出仍开放的问题。不发明 POC 延迟排名；产品对比细节外链站内已有篇章。

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

篇目	核心内容
第 15 篇 · 生产排障	五轴故障清单
第 16 篇 · 选型收束	排除树、部署形态、开放问题、阅读回收

版本锚定：机制结论对齐 Envoy v1.39.0。与 网关选型、Service Mesh、Cilium 分工：那些文负责产品叙事与税；本文负责「内核能力是否必要」。

一、先排除，再选择

flowchart TD
  need{"Need dynamic L7 policy<br/>+ hot config via API?"}
  need -->|"no"| file["Nginx / HAProxy<br/>file-driven path"]
  need -->|"yes"| rich{"Need filter chain,<br/>xDS tree, rich L7?"}
  rich -->|"no"| l4["L4 LB / eBPF LB<br/>may suffice"]
  rich -->|"yes"| deploy{"Per-service identity<br/>and policy isolation?"}
  deploy -->|"yes"| side["Sidecar Envoy"]
  deploy -->|"shared node L7"| node["Per-node Envoy"]
  deploy -->|"L3/L4 only"| ebpf["eBPF datapath"]

Envoy 不是默认赢家：它赢在「动态配置 + Filter 组合 + 可观测落点」成为一等公民的时候；它输在运维只要 Git 里一份可 diff 的 conf、且没有控制面预算的时候。

排除树要诚实对待组织约束：没有可持续的 xDS 控制面（或托管等价物），强行上 Envoy 只会把「文件 reload」换成「半手工 ADS + 不可解释 NACK」。机制能力不等于编制齐全。

二、Envoy vs Nginx / HAProxy（机制差，非跑分）

站内 network/60 已从协议、运维与生态做横向表。本系列补充的判决句是：

• 选 Nginx/HAProxy：主路径是稳定 L4/L7 转发，变更可走文件与受控 reload，不需要全量 xDS 经济学。
• 选 Envoy：主路径是控制面持续推送、按请求组合策略，且要用同一套数据面语义跨网关与（可选）mesh。

把「云原生」当选型理由不够；把「是否需要可 ACK 的资源依赖树」当理由才够。

实务上常见的混合并不违反排除树：边缘用 Envoy（或 Envoy Gateway）做 L7 入口，东西向 L4 交给 eBPF/CNI，仅对少数需要细粒度 HTTP 策略的服务保留 sidecar。混合的代价是两套排障坐标——第 15 篇的清单要标明流量先进了哪一层。

三、Sidecar vs 节点级 Envoy vs eBPF

排除提示：

1. 只要 L4 身份与路径：优先问 eBPF/CNI，而不是先铺 sidecar。
2. 要 L7 但要砍 sidecar 税：节点级 Envoy 或 Ambient 类架构是「部署形态」选择；数据面内核仍可能是 Envoy——税从「每 Pod」挪到「每节点/每关键路径」。
3. 要每服务差异化 HTTP 策略且爆炸半径隔离：sidecar 仍难被节点共享代理完整替代。

本系列不裁决 Istio Ambient vs Cilium Mesh 产品胜负；只要求选型者能指出延迟与失败落在用户态 Filter 还是内核跳转。

若最终仍选择 sidecar Envoy，请把第 14–15 篇的观测与排障清单写进发布门禁：否则「机制正确」会输给「每实例一张不可读的 Grafana」。

四、系列阅读路径回收

五条坐标系（第 1 篇）到终章仍然够用：选型争议要么落在「要不要 API 驱动路径」，要么落在「代理跳放在哪」，很少落在营销形容词上。

写给后续维护者的一句：改 Envoy 版本或换控制面时，先重跑第 15 篇清单里与 ACK/warming/drain 相关的门禁，再更新本篇排除树的假设；机制漂移比品牌更名更常见。

五、系列级开放问题

下列问题有工程与社区争议，本系列给了机制语言，但不假装已关闭：

5.1 xDS 规模与推送经济学

大规模 EDS 抖动时，SotW 带宽与 Incremental 复杂度如何权衡？ACK 延迟与「配置已生效」SLO 应如何定义才不会变成虚假门禁？（入口：第 10–11、15 篇；官方 xDS 协议文档。）

5.2 Sidecar 税 vs 共享数据面

内存与跳数税是否总是大于每服务隔离收益？节点级 Envoy / Ambient / eBPF 混合后，故障域与安全域如何重新划线？（入口：architecture/76、k8s-network/13。）

5.3 Wasm 扩展 vs 原生 Filter

隔离与多语言能否补偿 ABI、延迟与运维工具链成本？哪些策略应留在原生 C++ filter，哪些必须外置服务？（入口：第 13 篇、architecture/97。）

5.4 HTTP/3 / QUIC 与 TCP 路径分叉

Codec、连接迁移、超时与连接池语义在 HTTP/3 上与 HTTP/1·2 何处分叉？排障坐标是否要为 QUIC 单开一轴？（入口：第 5 篇；官方 HCM/QUIC 文档。）

一个可检验的子问题：同一套 Route/Cluster 配置下，HTTP/3 特有的连接迁移与 0-RTT 失败，能否被现有 RESPONSE_FLAGS / cluster 统计充分表达，还是必须引入协议专用信号？

5.5 可观测成本与归因上限

全量 access log、高基数 stats tag、高采样 tracing 同时打开时，数据面 CPU 与后端存储谁先爆？代理信号与 可观测性系列 的平台治理如何接轨才不双写两套真相？（入口：第 14 篇。）

这些问题不要求一篇终章「拍板」。它们要求后续文章或事故复盘带着坐标系与排除树回去量：量的是 ACK 延迟分布、sidecar RSS、Wasm p99 增量、QUIC 特有失败旗标——而不是再写一张无口径的延迟排行榜。

终章立场可以收成一句：Envoy 数据面值得写 16 篇，是因为它把动态配置与 Filter 失败变成可命名的机制；选型与开放问题若离开这些名字，讨论会退回品牌口号。

六、参考资料

规范 / 官方文档（A）

• Envoy Proxy v1.39.0，Architecture overview / Threading model / xDS protocol / Hot restart。
• 本系列各篇文末 A 级引用（Listener、HCM、Cluster、Observability）。

站内对照

• 系列目录
• 第 15 篇 · 生产排障
• 第 1 篇 · 数据面全景
• 网关选型对比
• Service Mesh
• Cilium 与节点级 Envoy
• 可观测性工程
• Envoy 架构剖析（单篇地图）

实验台账

• 本篇无跨代理 benchmark；选型依据为机制排除，非跑分。

七、小结

1. 用排除树选型：先问动态 L7 / xDS / 身份隔离是否必要，再选 Nginx、HAProxy、Envoy 或 eBPF。
2. Sidecar、节点 Envoy、eBPF 优化的是部署税与能力边界，不是三个互斥品牌；内核仍可能是同一套 Envoy 机制。
3. 系列回收：坐标系 → 路径 → xDS → 观测 → 排障 → 本篇收束。
4. 开放问题留下：xDS 规模、sidecar 税、Wasm、HTTP/3 分叉、观测成本——后续工作应带着这些坐标回去量，而不是重开名词大战。
5. 与姊妹文的边界：60 / 76 / Cilium 管产品与税；本系列管「一次请求与一次推送如何失败」——终章把两者接回同一张排除树。

→ 上一篇：生产排障 · 系列目录