【网络工程】网关选型对比：Nginx vs HAProxy vs Envoy vs Traefik

反向代理和网关是基础设施层最关键的组件之一——选错了不会让系统立刻出问题，但会在规模增长后暴露出越来越多的痛点：配置管理困难、缺少动态服务发现、可观测性不够、性能到瓶颈。

Nginx、HAProxy、Envoy、Traefik 是当前最主流的四个选择。它们各有设计哲学，适用于不同的场景。本文不做”哪个最好”的简单排名——没有最好的工具，只有最适合的工具。我们从架构模型、配置方式、协议支持、可观测性、扩展机制和性能特征六个维度做系统对比，帮你在自己的场景下做出有依据的选择。

一、设计哲学与定位

四个项目诞生于不同的时代，面向不同的问题：

Nginx 从 Web 服务器起步，逐步扩展为反向代理和负载均衡器。它的优势在于生态成熟、文档丰富、性能出色。Nginx Plus（商业版）和 OpenResty（Lua 扩展）补充了开源版本的功能短板。

HAProxy 从一开始就定位为高性能负载均衡器。它在 TCP 和 HTTP 负载均衡领域有最深的功能集——ACL 规则引擎、Stick Table、Runtime API 都是其他项目难以匹敌的。

Envoy 是云原生时代的产物，由 Lyft 开发后捐献给 CNCF。它的设计核心是 API 驱动的配置（xDS 协议），天生适合 Service Mesh 和动态微服务环境。

Traefik 的设计理念是”自动化”——自动从 Docker、Kubernetes、Consul 等发现服务并配置路由，无需手动写配置文件。它面向 DevOps 工程师和容器化环境。

二、架构模型对比

2.1 进程与线程模型

Nginx:
┌──────────┐
│  Master  │ ← 管理 Worker，热重载
├──────────┤
│ Worker 1 │ ← 单线程，epoll 事件循环
│ Worker 2 │ ← 每个 Worker 独立处理连接
│ Worker 3 │
│ Worker 4 │
└──────────┘

HAProxy:
┌──────────┐
│  Master  │ ← 管理 Worker（HAProxy 2.0+）
├──────────┤
│ Thread 1 │ ← 多线程模型（HAProxy 1.8+）
│ Thread 2 │ ← 共享内存空间
│ Thread 3 │ ← Stick Table 在线程间共享
│ Thread 4 │
└──────────┘

Envoy:
┌──────────────────┐
│    Main Thread   │ ← xDS 通信、管理
├──────────────────┤
│ Worker Thread 1  │ ← per-worker 事件循环
│ Worker Thread 2  │ ← TLS（Thread Local Storage）
│ Worker Thread 3  │ ← 连接绑定到 Worker
│ Worker Thread 4  │
└──────────────────┘

Traefik:
┌──────────────────┐
│   Go Runtime     │ ← 单进程，Go 调度器管理
├──────────────────┤
│ Goroutine Pool   │ ← 每个连接一个 goroutine
│ Provider Watcher │ ← 监听配置源变更
│ Configuration    │ ← 动态路由更新
└──────────────────┘

工程含义：

2.2 配置热更新

配置更新是生产运维中最频繁的操作。四个项目的方式差异巨大：

Nginx：

# 修改配置文件后
nginx -t && nginx -s reload

# 行为：
# 1. Master 读取新配置
# 2. 启动新 Worker（使用新配置）
# 3. 旧 Worker 停止接受新连接
# 4. 旧 Worker 处理完已有请求后退出
# 5. 新旧 Worker 短暂共存

# 代价：
# - 新 Worker 需要重建连接池
# - TLS Session Cache 不共享（除非用共享内存）
# - 如果旧请求处理很慢，旧 Worker 会长时间存在

HAProxy：

# Seamless Reload（HAProxy 1.8+）
systemctl reload haproxy

# 行为：
# 1. 启动新进程
# 2. 通过 Unix socket 传递 listen fd 给新进程
# 3. 新进程接管 listen socket
# 4. 旧进程排空已有连接后退出

# 优势：
# - 零连接丢失
# - Stick Table 通过 peers 同步到新进程

# Runtime API 动态更新（不需要 reload）
echo "set server backend/app1 state drain" | socat - /run/haproxy/admin.sock
echo "set server backend/app1 weight 0" | socat - /run/haproxy/admin.sock
echo "add server backend/app3 10.0.1.12:8080" | socat - /run/haproxy/admin.sock

Envoy：

# Envoy 的核心设计：xDS API 驱动配置
# 不需要 reload——配置通过 gRPC 流推送

# xDS 配置源
dynamic_resources:
  lds_config:
    resource_api_version: V3
    api_config_source:
      api_type: GRPC
      grpc_services:
        - envoy_grpc:
            cluster_name: xds_cluster

# 行为：
# 1. Control Plane 推送新配置
# 2. Envoy 原子性地应用新路由/集群
# 3. 已有连接不中断
# 4. 新连接使用新配置

# Hot Restart（二进制升级时使用）
envoy --restart-epoch 1  # 增加 epoch 触发热重启

Traefik：

# Traefik 自动发现，无需手动配置
# Kubernetes Ingress 示例
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-app
  annotations:
    traefik.ingress.kubernetes.io/router.entrypoints: websecure
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: app-svc
                port:
                  number: 8080

# 行为：
# 1. Traefik 监听 Kubernetes API
# 2. 检测到 Ingress 变更
# 3. 原子性地更新内部路由表
# 4. 无需 reload，零连接影响

2.3 热更新对比总结

三、协议支持对比

3.1 L4 / L7 协议支持

3.2 负载均衡算法

3.3 健康检查

Nginx 开源版的健康检查依赖被动检测（请求失败后标记 down）。主动健康检查需要 Nginx Plus 或第三方模块（如 nginx_upstream_check_module）。

四、可观测性对比

可观测性（Observability）是生产环境选型的关键考量——出了问题能不能快速定位？

4.1 指标（Metrics）

Nginx：

# 开源版：stub_status（7 个基础指标）
server {
    location /nginx_status {
        stub_status;
    }
}
# Active connections / accepts / handled / requests
# Reading / Writing / Waiting

# Nginx Plus：150+ 指标（JSON API）
# 包括每个 upstream server 的详细指标
# 请求延迟直方图、SSL 统计等

# 开源替代：VTS 模块（nginx-module-vts）
# 提供 Prometheus 兼容输出

HAProxy：

# Stats 页面（丰富的实时指标）
frontend stats
    bind *:8404
    stats enable
    stats uri /stats
    stats refresh 10s
    stats admin if TRUE

# Prometheus exporter（原生支持，HAProxy 2.0+）
frontend stats
    bind *:8405
    http-request use-service prometheus-exporter if { path /metrics }

HAProxy 的指标覆盖度最全：每个 frontend/backend/server 都有独立的计数器，包括连接数、请求数、字节数、错误数、响应时间分布、队列深度、健康检查状态等。

Envoy：

# Envoy 原生提供 Prometheus 兼容指标
admin:
  address:
    socket_address:
      address: 0.0.0.0
      port_value: 9901

# 访问 /stats/prometheus 获取所有指标
# Envoy 的指标粒度最细：
# - 每个 Cluster 的连接/请求/错误/延迟
# - 每个 Listener 的连接/拒绝
# - 每个 Filter 的处理统计
# - 断路器状态、重试统计、异常检测统计

Traefik：

# traefik.yml
metrics:
  prometheus:
    entryPoint: metrics
    addEntryPointsLabels: true
    addRoutersLabels: true
    addServicesLabels: true
    buckets:
      - 0.1
      - 0.3
      - 1.2
      - 5.0

entryPoints:
  metrics:
    address: ":8082"

4.2 可观测性对比总结

4.3 分布式追踪

Envoy 和 Traefik 原生支持分布式追踪，可以自动注入 trace header：

# Envoy 追踪配置
http_connection_manager:
  tracing:
    provider:
      name: envoy.tracers.opentelemetry
      typed_config:
        "@type": type.googleapis.com/envoy.config.trace.v3.OpenTelemetryConfig
        grpc_service:
          envoy_grpc:
            cluster_name: otel_collector
  # 自动传播 trace context
  # 支持 B3、W3C Trace Context、Jaeger 格式

Nginx 和 HAProxy 需要第三方模块或依赖应用层传播 trace header。

五、扩展机制对比

5.1 扩展方式

5.2 Nginx 扩展生态

Nginx 的扩展生态最为成熟：

Nginx 扩展层次：
├── C 模块（第三方）
│   ├── nginx-module-vts（虚拟主机流量统计）
│   ├── ngx_brotli（Brotli 压缩）
│   ├── nginx_upstream_check_module（主动健康检查）
│   └── njs（JavaScript 扩展）
├── OpenResty（Lua 生态）
│   ├── lua-resty-redis（Redis 客户端）
│   ├── lua-resty-jwt（JWT 验证）
│   ├── lua-resty-limit-traffic（限流）
│   └── lua-resty-upstream-healthcheck
└── Nginx Plus API
    ├── Dynamic upstream management
    ├── Key-Value store
    └── 详细 metrics API

OpenResty 示例——JWT 验证：

-- /etc/nginx/lua/jwt_auth.lua
local jwt = require "resty.jwt"

local function authenticate()
    local auth_header = ngx.var.http_Authorization
    if not auth_header then
        ngx.status = 401
        ngx.say('{"error": "missing authorization header"}')
        return ngx.exit(401)
    end
    
    local token = auth_header:match("Bearer%s+(.+)")
    if not token then
        ngx.status = 401
        return ngx.exit(401)
    end
    
    local jwt_obj = jwt:verify("secret-key", token)
    if not jwt_obj.verified then
        ngx.status = 403
        ngx.say('{"error": "invalid token"}')
        return ngx.exit(403)
    end
    
    -- 将用户信息传递给上游
    ngx.req.set_header("X-User-ID", jwt_obj.payload.sub)
end

authenticate()

5.3 Envoy 扩展机制

Envoy 的 Wasm 扩展是最灵活的：

// Rust proxy-wasm 示例：请求头注入
use proxy_wasm::traits::*;
use proxy_wasm::types::*;

struct RequestHeaders;

impl Context for RequestHeaders {}

impl HttpContext for RequestHeaders {
    fn on_http_request_headers(
        &mut self, _: usize, _: bool
    ) -> Action {
        // 添加自定义头
        self.add_http_request_header(
            "x-request-id",
            &uuid::Uuid::new_v4().to_string(),
        );
        
        // 基于请求路径做路由决策
        if let Some(path) = self.get_http_request_header(":path") {
            if path.starts_with("/internal") {
                self.send_http_response(403, vec![], None);
                return Action::Pause;
            }
        }
        
        Action::Continue
    }
}

Envoy 的 ext_authz Filter 支持外部授权服务：

http_filters:
  - name: envoy.filters.http.ext_authz
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.ext_authz.v3.ExtAuthz
      grpc_service:
        envoy_grpc:
          cluster_name: auth_service
      failure_mode_allow: false
      with_request_body:
        max_request_bytes: 8192
        allow_partial_message: true

5.4 Traefik 中间件

Traefik 的中间件链设计简洁直观：

# Traefik 动态配置
http:
  routers:
    app:
      rule: "Host(`app.example.com`)"
      middlewares:
        - rate-limit
        - compress
        - headers
      service: app-service

  middlewares:
    rate-limit:
      rateLimit:
        average: 100
        burst: 50
    
    compress:
      compress:
        excludedContentTypes:
          - text/event-stream
    
    headers:
      headers:
        customRequestHeaders:
          X-Forwarded-Proto: "https"
        stsSeconds: 63072000
        stsIncludeSubdomains: true

  services:
    app-service:
      loadBalancer:
        servers:
          - url: "http://10.0.1.10:8080"
          - url: "http://10.0.1.11:8080"

六、性能特征对比

6.1 基准测试方法论

代理/网关的性能比较需要注意测试条件的一致性：

# 测试环境标准化
# - 相同硬件（4 核 8G，SSD）
# - 相同 Linux 内核版本
# - 相同网络配置（禁用 offload 以保证公平）
# - 相同后端（返回固定大小响应）
# - 相同 TLS 配置（ECDSA P-256，TLS 1.3）

# 后端模拟服务器
# 使用 wrk 自带的简单 Lua 脚本返回固定响应

# 测试维度：
# 1. HTTP 小响应吞吐量（RPS）
# 2. HTTP 大响应带宽（throughput）
# 3. 新建 TLS 连接速率
# 4. 延迟分布（P50/P95/P99）
# 5. 长连接并发数上限

6.2 性能特征总结

基于公开基准测试数据和社区经验的总结（非实测，不同环境结果差异很大）：

关键观察：

1. Nginx 和 HAProxy 在原始性能上接近，都是 C 实现，事件驱动模型。HAProxy 在纯负载均衡场景下略有优势（更少的代码路径）。

2. Envoy 的性能开销来自其丰富的功能。Filter Chain、xDS、详细指标采集都有 CPU 开销。但在实际生产中，Envoy 的功能带来的运维效率通常远超性能差异。

3. Traefik 作为 Go 实现，在原始性能上有差距。Go 的 GC 可能引入延迟抖动。但对于大多数业务场景（< 50,000 RPS），这个差距不是瓶颈。

6.3 资源消耗对比

内存消耗（空闲状态，无流量）：
- Nginx:    ~5 MB（Master + 4 Workers）
- HAProxy:  ~10 MB（单进程 + 4 线程）
- Envoy:    ~30 MB（Main + 4 Workers + Admin）
- Traefik:  ~50 MB（Go Runtime + Dashboard）

内存消耗（10,000 并发连接）：
- Nginx:    ~80 MB
- HAProxy:  ~200 MB（bufsize 更大）
- Envoy:    ~300 MB（per-connection 状态更多）
- Traefik:  ~400 MB（Go goroutine 开销）

CPU 消耗（10,000 RPS，HTTP 代理，非 TLS）：
- Nginx:    ~15% 单核
- HAProxy:  ~12% 单核
- Envoy:    ~25% 单核
- Traefik:  ~35% 单核

七、场景选型建议

7.1 选型决策矩阵

7.2 场景分析

场景一：中小型 Web 应用

推荐：Nginx

理由：
- 静态文件服务 + 反向代理 + TLS 终止一体化
- 配置简单，文档多，团队学习成本最低
- 性能远超需求
- 生态成熟，出问题容易找到答案

配置复杂度：低
运维成本：低

场景二：大规模微服务（非 K8s）

推荐：HAProxy

理由：
- Runtime API 支持动态上下线服务器
- Stick Table 支持复杂的会话保持和限流
- ACL 规则引擎支持灵活的路由规则
- 性能和稳定性经过大规模验证
- Stats 页面提供丰富的实时监控

配置复杂度：中
运维成本：中

场景三：Kubernetes + Service Mesh

推荐：Envoy（作为 Sidecar）+ Traefik 或 Nginx（作为 Ingress）

理由：
- Envoy 是 Istio/Linkerd 的默认数据面
- xDS 协议让配置管理完全自动化
- 原生分布式追踪和丰富指标
- Traefik 自动发现 K8s Service/Ingress
- 或用 Nginx Ingress Controller（更成熟）

配置复杂度：高（初始），低（日常）
运维成本：中

场景四：边缘 API 网关

推荐：Kong（基于 Nginx/OpenResty）或 Envoy-based 网关（如 Ambassador）

理由：
- 需要认证、限流、日志、转换等插件
- Kong 有最丰富的插件生态
- Envoy-based 网关更适合已有 Envoy 生态的团队

替代方案：
- 如果功能需求简单 → Nginx + Lua
- 如果已经用 K8s → Traefik + 中间件

配置复杂度：中
运维成本：中

7.3 灰度迁移策略

从一个代理迁移到另一个不应该是”大爆炸”式切换。推荐的灰度迁移方法：

阶段 1：并行部署
┌──────────┐     ┌──────────────┐
│ 老代理    │ ──→ │  后端服务    │
│ (100%)   │     │              │
└──────────┘     └──────────────┘
┌──────────┐     ┌──────────────┐
│ 新代理    │ ──→ │  后端服务    │
│ (0%)     │     │  （镜像流量） │
└──────────┘     └──────────────┘

阶段 2：流量切分
DNS/LB 分流：老代理 90% / 新代理 10%
监控对比：延迟、错误率、功能完整性

阶段 3：逐步切换
老代理 50% / 新代理 50%
确认无退化后 → 老代理 10% / 新代理 90%

阶段 4：完全切换
新代理 100%，老代理保留 7 天作为回滚保险

具体操作示例——使用 DNS 权重实现流量切分：

# Route 53 加权路由
# 老代理记录权重 90
aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "old-proxy",
        "Weight": 90,
        "TTL": 60,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

# 新代理记录权重 10
aws route53 change-resource-record-sets --hosted-zone-id ZONE_ID \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "new-proxy",
        "Weight": 10,
        "TTL": 60,
        "ResourceRecords": [{"Value": "10.0.2.10"}]
      }
    }]
  }'

7.4 迁移配置翻译

从一个代理迁移到另一个是常见需求。关键原则：

迁移风险评估：
1. 配置翻译的完整性（所有规则都能迁移吗？）
2. 功能差异（缺少的功能用什么替代？）
3. 性能基线对比（新方案性能至少不退化）
4. 运维工具链兼容性（监控、日志、告警）

Nginx → Envoy 迁移：

核心变化：
- 配置文件 → xDS API（或静态 YAML）
- location 匹配 → Route 匹配
- upstream → Cluster
- proxy_pass → Route action

注意事项：
- Nginx 的正则匹配能力 > Envoy（Envoy 的路由匹配更结构化）
- Nginx 的静态文件服务在 Envoy 中没有对应物
- OpenResty Lua 逻辑需要用 Wasm 或 ext_proc 替代

HAProxy → Nginx 迁移：

核心变化：
- frontend/backend → server 块 + upstream
- ACL 规则 → map / if / location
- Stick Table → 第三方限流模块或 Lua
- Runtime API → Nginx Plus API 或脚本

注意事项：
- HAProxy 的 ACL 表达能力 > Nginx（可能需要 Lua）
- HAProxy 的 Seamless Reload > Nginx 的 reload
- HAProxy 的 Stats 页面 > Nginx stub_status（需要 VTS 模块补充）

7.4 不要忽视的因素

技术选型不只看功能和性能，还要考虑：

八、总结

我的工程建议：

1. 没有”最好”的代理。Nginx 在 Web 场景最成熟，HAProxy 在负载均衡领域最强，Envoy 在云原生和 Service Mesh 中不可替代，Traefik 在容器化 DevOps 中最省心。选择的依据是你的场景和团队，不是技术的”先进性”。

2. 大多数团队应该从 Nginx 开始。它的学习曲线最平缓，文档最多，90% 的场景都能覆盖。只有当你遇到它解决不了的问题时（动态配置、Service Mesh、高级负载均衡），再考虑迁移。

3. Envoy 的学习曲线很陡但回报很高。如果你的基础设施向 Kubernetes + Service Mesh 演进，现在开始学 Envoy 是值得的。xDS 的配置管理能力在大规模微服务中是其他方案做不到的。

4. HAProxy 在纯负载均衡场景被低估。它的 ACL、Stick Table、Runtime API 的组合在复杂路由和限流场景中非常强大。如果你需要一个”不出意外”的负载均衡器，HAProxy 是最稳的选择。

5. Traefik 适合”我只想让它工作”的场景。如果你用 Docker Compose 或 Kubernetes，Traefik 的自动发现能力可以让你几乎零配置地跑起来。但要注意它的性能天花板和功能边界。

6. 混合部署是常态。大型系统中经常看到 Nginx 做边缘、HAProxy 做内部 L4 LB、Envoy 做 Service Mesh Sidecar 的组合。不要执着于”统一技术栈”——让每个组件做它最擅长的事。

上一篇：代理性能调优：缓冲、Keepalive 与连接复用

下一篇：CDN 架构原理：PoP、边缘节点与 Origin Shield