【网络工程】网关选型对比：Nginx vs HAProxy vs Envoy vs Traefik
内容提要
本文系统对比了Nginx、HAProxy、Envoy和Traefik四种主流反向代理/网关，从设计哲学、架构模型、协议支持、可观测性、扩展机制和性能六个维度分析，指出各有适用场景：Nginx适合传统Web，HAProxy擅长高性能负载均衡，Envoy面向云原生Service Mesh，Traefik简化容器化部署。建议根据团队经验和场景选型，可混合部署，并给出灰度迁移策略。
延伸解读
选型需结合团队经验与场景
文章强调没有“最好”的代理，只有最适合的。Nginx适合传统Web，HAProxy擅长高性能负载均衡，Envoy面向云原生Service Mesh，Traefik简化容器化部署。选型时需考虑团队熟悉度、社区活跃度、商业支持等因素，避免盲目追求技术先进性。
热更新与动态配置差异显著
四个代理在配置更新方式上差异明显：Nginx依赖reload，HAProxy支持Seamless Reload和Runtime API，Envoy通过xDS API实现动态配置，Traefik自动发现服务。对于需要频繁调整路由或动态上下线的场景，Envoy和Traefik更具优势，而Nginx和HAProxy在静态配置下更稳定。
可观测性影响故障排查效率
Envoy和Traefik原生支持Prometheus指标和分布式追踪，HAProxy提供丰富的Stats页面，而Nginx开源版指标较少。在生产环境中，丰富的可观测性数据能帮助快速定位问题，选型时应根据监控需求权衡。
性能与功能需权衡
Nginx和HAProxy在原始性能上接近，Envoy因功能丰富有额外开销，Traefik作为Go实现性能稍弱。但实际中，Envoy的功能带来的运维效率通常远超性能差异，Traefik在大多数业务场景下性能也不是瓶颈。
Q&A
Nginx、HAProxy、Envoy、Traefik 这四种网关在设计哲学上有什么不同？
Nginx 从 Web 服务器起步，定位为 Web 服务器加反向代理，适合传统 Web 场景；HAProxy 从一开始就专注高性能 TCP/HTTP 负载均衡，功能集最深；Envoy 是云原生时代的产物，设计核心是 API 驱动的配置（xDS），适合 Service Mesh 和动态微服务环境；Traefik 的设计理念是自动化，自动从容器平台发现服务并配置路由，面向 DevOps 和容器化环境。
在配置热更新方面，Nginx、HAProxy、Envoy、Traefik 各有什么特点？
Nginx 通过 reload 实现热更新，新旧 Worker 短暂共存，旧连接排空，更新粒度是全量，延迟秒级；HAProxy 支持 Seamless Reload，通过 fd 传递实现零连接丢失，也支持 Runtime API 动态更新单个服务器，更新粒度可以是全量或单服务器；Envoy 通过 xDS API 动态推送配置，原子性应用，零连接影响，更新粒度按资源类型，延迟亚秒级；Traefik 自动发现配置源变化，原子更新路由表，零连接影响，更新粒度按路由，延迟亚秒级。
Envoy 在协议支持和负载均衡算法方面有哪些独特优势？
Envoy 原生支持 HTTP/2 上游、gRPC、HTTP/3、UDP 代理等，协议支持全面；负载均衡算法丰富，包括 P2C、Maglev、Ring Hash 等高级算法，适合云原生环境。
在可观测性方面，Nginx、HAProxy、Envoy、Traefik 各有什么特点？
Nginx 开源版内置指标少（约7个），需要第三方模块支持 Prometheus；HAProxy 指标覆盖度最全，原生支持 Prometheus exporter；Envoy 指标粒度最细，原生支持 Prometheus 和分布式追踪；Traefik 内置指标约50个，原生支持 Prometheus 和分布式追踪，并提供内置 Dashboard。
Nginx、HAProxy、Envoy、Traefik 的扩展机制分别是什么？
Nginx 支持 C 模块和 Lua（通过 OpenResty），生态最丰富；HAProxy 原生不支持扩展，但支持 Lua（SPOE）和外部进程；Envoy 支持 C++ Filter、Lua Filter、Wasm 扩展和外部进程（ext_authz/ext_proc）；Traefik 支持 Go 中间件和实验性的 Wasm 扩展。
在性能方面，Nginx、HAProxy、Envoy、Traefik 各有什么表现？
Nginx 和 HAProxy 在原始性能上接近，都是 C 实现，事件驱动模型，HAProxy 在纯负载均衡场景略有优势；Envoy 性能开销来自丰富功能，但实际生产中功能带来的运维效率通常远超性能差异；Traefik 作为 Go 实现，原始性能有差距，Go 的 GC 可能引入延迟抖动，但对大多数业务场景（<50,000 RPS）不是瓶颈。
根据文章，在 Kubernetes 环境中应该选择哪个网关？
文章建议在 Kubernetes 环境中，可以使用 Traefik 或 Nginx 作为 Ingress，其中 Traefik 自动发现 K8s Service/Ingress，配置简单；Nginx Ingress Controller 更成熟稳定。如果使用 Service Mesh，Envoy 是默认数据面。
文章推荐的从旧网关迁移到新网关的灰度迁移策略是什么？
文章推荐分四个阶段：1. 并行部署，新代理接收镜像流量；2. 流量切分，通过 DNS/LB 分流，如老代理90%新代理10%，监控对比；3. 逐步切换，如50%/50%，确认无退化后继续；4. 完全切换，新代理100%，老代理保留7天作为回滚保险。
