【HAProxy 数据面】选型收束：机制排除树与系列开放问题
内容提要
本文为HAProxy数据面系列终章，通过排除树对比Nginx、Envoy、eBPF选型：HAProxy适合深度L4/L7负载均衡与热改运行态；Nginx偏Web反代；Envoy需API驱动；eBPF仅L3/L4。强调机制优势须支付迁移税，并列出stick-table一致性、QUIC成熟度、运维可观测性等开放问题，建议按排障坐标选型而非品牌口号。
延伸解读
排除树的价值在于诚实评估迁移成本
文章强调，选型不能只看机制优势，还要考虑迁移税。如果团队已深度使用Nginx，其故障手册、看板、证书流水线都围绕Nginx构建，仅因HAProxy Runtime更强就迁移，可能低估排障方言切换成本。机制优势必须能支付迁移税，否则应先优化现有reload纪律，再评估是否换内核。
混合部署可行，但需明确排障坐标
文章指出，边缘HAProxy做L7入口、东西向L4交给eBPF、少数服务挂Envoy sidecar的混合模式并不犯规，但代价是多套排障坐标。第13篇的故障清单需标明流量先进了哪一层，否则排障时难以定位问题。这提醒读者，混合架构虽灵活，但运维复杂度会显著增加。
开放问题聚焦运维一致性而非性能
文章列出的开放问题集中在stick-table一致性、QUIC成熟度、reload与Runtime可观测性，而非延迟排名。例如，stick-table在peers分区时可能造成策略分裂，QUIC的H3失败能否用现有日志表达，以及如何确保Git与内存配置一致。这些问题直接关系到生产环境的可靠性，选型时应优先考虑。
Q&A
HAProxy、Nginx、Envoy 和 eBPF 在选型上分别适合什么场景？
HAProxy 适合需要深度 L4/L7 负载均衡、热改运行态和强 ACL/stick-table 的场景；Nginx 适合 Web 反向代理和静态资源服务；Envoy 适合需要 API 驱动配置树和 Filter 组合的云原生环境；eBPF 适合仅需 L3/L4 内核路径转发的场景。
HAProxy 的 Runtime API 和 reload 机制相比 Nginx 的 reload 有什么优势？
HAProxy 通过 Runtime API 可以在不中断服务的情况下热改权重、状态、表和 map，而 Nginx 主要依赖文件配置和 reload，动态运维能力较窄。HAProxy 的 seamless reload 通过 -x 和 sockpair 实现平滑交接，减少进程级变更。
在什么情况下应该选择 Envoy 而不是 HAProxy？
当组织需要 ACK-able API 配置树、Filter 链组合以及跨网关/mesh 统一数据面语义时，Envoy 是更合适的选择。如果已经押注 xDS 控制面经济学，或者需要 sidecar 模式，Envoy 优于 HAProxy。
eBPF 在负载均衡中的定位是什么？它适合处理哪些场景？
eBPF 适合仅需 L3/L4 转发和身份识别的场景，不需要完整 HTTP 应用语义。它通过内核路径转发，延迟和跳数税低，但缺乏 L7 深度策略能力。
HAProxy 的 stick-table 在跨 reload 时如何保持一致性？有哪些开放问题？
HAProxy 通过 peers 机制在 reload 时同步 stick-table 数据，但存在表容量、过期、跨线程更新和 peers 分片在极大键空间下的延迟与一致性权衡问题。开放问题包括满表驱逐与 peers 断连的可观测性，以及安全封禁场景下 peers 分区可能导致策略分裂。
HAProxy 3.4 中 QUIC/HTTP/3 的成熟度如何？有哪些限制？
HAProxy 3.4 支持 QUIC frontend，但存在 mux、超时、连接迁移和排障信号上的分叉，Runtime/reload 对 QUIC listener 有动态删除限制。H3 特有失败可能无法用现有 httplog 和 show sess 完全表达，需要协议专用计数器。
在 HAProxy 中，如何确保配置的真相一致？有哪些可观测性建议？
建议将配置的 SLO 钉在磁盘 mtime、reload 完成或 show * 断言上，并生成机器可读的证据包（文件哈希 + reload 世代 + 抽样 show stat 字段），使 Git 与内存一致成为门禁。同时，应避免故意让真相分叉，如少用动态 server 和长期只活在内存的 map。
HAProxy 选型时，如何避免被品牌口号误导？
应基于机制排除树，先明确需求（如是否需要深度 L4/L7、API 驱动、L3/L4 等），再选择对应产品。同时考虑迁移税，如团队已有的排障方言和运维流程，机制优势必须能支付迁移税。
