Nginx vs Envoy vs Traefik:云原生网关的性能基准测试与百万并发场景下的架构取舍
Nginx vs Envoy vs Traefik:云原生网关的性能基准测试与百万并发场景下的架构取舍
一、背景与动机
在云原生架构中,API网关(Gateway)是流量入口的核心组件,负责请求路由、负载均衡、认证鉴权、限流熔断等功能。随着微服务规模的扩大和流量增长,网关的性能和可扩展性成为关键瓶颈。
目前主流的云原生网关方案包括:
- Nginx:经典的高性能反向代理,成熟稳定,生态丰富。
- Envoy:Lyft开源的高性能代理,CNCF毕业项目,Istio默认数据平面。
- Traefik:现代化的云原生网关,自动服务发现,配置简单。
本文通过系统的性能基准测试,深度对比这三种网关在以下维度的表现:
- 吞吐量:每秒请求数(RPS)
- 延迟:P50、P99延迟
- 并发能力:支持的最大并发连接数
- 资源消耗:CPU和内存占用
- 功能完整性:负载均衡算法、健康检查、TLS性能等
graph TB
A[客户端请求] --> B[API网关]
B --> C[Nginx]
B --> D[Envoy]
B --> E[Traefik]
C --> C1[上游服务1]
C --> C2[上游服务2]
C --> C3[上游服务N]
D --> C1
D --> C2
D --> C3
E --> C1
E --> C2
E --> C3
C1 --> F[性能监控]
C2 --> F
C3 --> F
F --> F1[Prometheus]
F --> F2[Grafana]
style B fill:#e1f5fe
style C fill:#fff3e0
style D fill:#e8f5e9
style E fill:#fce4ec
style F fill:#f3e5f5
二、网关架构与技术特性对比
2.1 Nginx:经典高性能反向代理
架构特点:
- 多进程模型:Master进程管理Worker进程,Worker进程处理请求。
- 事件驱动:基于epoll/kqueue的事件驱动模型,高性能。
- 模块化设计:核心模块+第三方模块,扩展性强。
核心配置示例:
# nginx.conf - Nginx高性能配置
worker_processes auto; # 自动设置为CPU核心数
worker_cpu_affinity auto; # CPU亲和性绑定
worker_rlimit_nofile 65535; # 文件描述符限制
events {
worker_connections 65535; # 每个Worker的最大连接数
use epoll; # Linux下使用epoll
multi_accept on; # 一次接受多个连接
}
http {
# 基础配置
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
keepalive_requests 10000; # 每个连接的最大请求数
# 缓冲区优化
client_body_buffer_size 128k;
client_max_body_size 10m;
client_header_buffer_size 4k;
large_client_header_buffers 4 32k;
# 超时优化
client_body_timeout 12;
client_header_timeout 12;
send_timeout 10;
# Gzip压缩
gzip on;
gzip_vary on;
gzip_min_length 1024;
gzip_types text/plain text/css application/json application/javascript;
# upstream配置(负载均衡)
upstream backend {
# 负载均衡算法:least_conn(最少连接)
least_conn;
# 上游服务器
server backend1.example.com:8080 weight=5 max_fails=3 fail_timeout=30s;
server backend2.example.com:8080 weight=5 max_fails=3 fail_timeout=30s;
server backend3.example.com:8080 backup; # 备份服务器
# 连接池
keepalive 32; # 保持32个空闲连接
}
# Server配置
server {
listen 80 reuseport; # SO_REUSEPORT(需要Nginx 1.9.1+)
server_name gateway.example.com;
# 访问日志(关闭以提升性能)
access_log off;
location / {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 超时设置
proxy_connect_timeout 5s;
proxy_send_timeout 60s;
proxy_read_timeout 60s;
# 缓冲区
proxy_buffering on;
proxy_buffer_size 32k;
proxy_buffers 64 32k;
}
}
}
性能优化要点:
- 启用reuseport:
listen 80 reuseport,每个Worker独立监听端口,减少锁竞争。 - 调整Worker数量:设置为CPU核心数。
- 优化缓冲区:根据请求大小调整缓冲区。
- 关闭访问日志:如果不需要,关闭
access_log off以提升性能。
2.2 Envoy:云原生高性能代理
架构特点:
- 多线程模型:主线程+工作线程,每个线程运行一个事件循环。
- 基于Libevent:使用Libevent实现跨平台事件驱动。
- 丰富功能:内置服务发现、负载均衡、熔断器、追踪等。
核心配置示例(YAML):
# envoy.yaml - Envoy配置
static_resources:
listeners:
- name: listener_http
address:
socket_address:
address: 0.0.0.0
port_value: 80
per_connection_buffer_limit_bytes: 32768 # 连接缓冲区限制
filter_chains:
- filters:
- name: envoy.filters.network.http_connection_manager
typed_config:
"@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
stat_prefix: ingress_http
route_config:
name: local_route
virtual_hosts:
- name: backend
domains: ["*"]
routes:
- match:
prefix: "/"
route:
cluster: backend_service
http_filters:
- name: envoy.filters.http.router
clusters:
- name: backend_service
connect_timeout: 5s
type: STRICT_DNS # 服务发现类型
lb_policy: LEAST_REQUEST # 负载均衡策略:最少请求
lb_subset_config:
fallback_policy: DEFAULT_SUBSET
default_subset:
version: v1
health_checks:
- timeout: 5s
interval: 10s
unhealthy_threshold: 3
healthy_threshold: 2
http_health_check:
path: /health
load_assignment:
cluster_name: backend_service
endpoints:
- lb_endpoints:
- endpoint:
address:
socket_address:
address: backend1.example.com
port_value: 8080
- endpoint:
address:
socket_address:
address: backend2.example.com
port_value: 8080
# 连接池配置
circuit_breakers:
thresholds:
- priority: DEFAULT
max_connections: 10000 # 最大连接数
max_pending_requests: 5000 # 最大等待请求数
max_requests: 20000 # 最大请求数
max_retries: 3 # 最大重试次数
# 管理端口
admin:
access_log_path: /tmp/admin_access.log
address:
socket_address:
address: 0.0.0.0
port_value: 9901
# 性能调优
overload_manager:
refresh_interval: 0.25s
resource_monitors:
- name: envoy.resource_monitors.fixed_heap
typed_config:
"@type": type.googleapis.com/envoy.extensions.resource_monitors.fixed_heap.v3.FixedHeapConfig
max_heap_size_bytes: 2147483648 # 2GB
actions:
- name: envoy.overload_actions.stop_accepting_requests
triggers:
- name: envoy.resource_monitors.fixed_heap
threshold:
value: 0.95
- name: envoy.overload_actions.reject_incoming_requests
triggers:
- name: envoy.resource_monitors.fixed_heap
threshold:
value: 0.98
性能优化要点:
- 调整线程数:通过
--concurrency参数设置工作线程数(建议等于CPU核心数)。 - 优化连接池:调整
circuit_breakers参数,避免连接耗尽。 - 启用HTTP/2:Envoy原生支持HTTP/2,性能更优。
启动命令:
# Envoy启动命令(性能优化)
envoy \
--config-path /etc/envoy/envoy.yaml \
--concurrency 48 \ # 工作线程数(等于CPU核心数)
--max-obj-name-len 256 \
--log-level warn \
--drain-time-s 60 \ # 优雅关闭时间
--enable-core-dump \ # 启用core dump(调试用)
--restart-epoch 0
2.3 Traefik:现代化云原生网关
架构特点:
- 自动服务发现:与Kubernetes、Docker、Consul等集成,自动配置路由。
- 动态配置:支持热更新,无需重启。
- 简洁配置:使用Label或CRD配置,易于管理。
核心配置示例(Kubernetes CRD):
# traefik-config.yaml - Traefik配置(Kubernetes)
apiVersion: v1
kind: ConfigMap
metadata:
name: traefik-config
namespace: kube-system
data:
traefik.yaml: |
serversTransport:
insecureSkipVerify: true # 跳过TLS验证(仅测试环境)
# 入口点配置
entryPoints:
web:
address: ":80"
http:
redirections:
entryPoint:
to: websecure
scheme: https
websecure:
address: ":443"
http:
tls:
certResolver: letsencrypt
# 提供商配置(Kubernetes)
providers:
kubernetesCRD:
namespaces:
- production
- staging
kubernetesIngress:
namespaces:
- production
- staging
# 服务发现配置
service:
loadBalancer:
servers:
- url: "http://10.0.0.1:8080" # Traefik Service IP
# 健康检查
healthcheck:
path: /ping
interval: 10s
timeout: 5s
# 观测性
metrics:
prometheus:
entryPoint: metrics
tracing:
jaeger:
samplingServerURL: "http://jaeger:14268/api/sampling"
# 日志配置
log:
level: WARN
format: json
accessLog:
format: json
fields:
defaultMode: keep
names:
ClientUsername: drop
---
# IngressRoute示例(Traefik CRD)
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:
name: backend-route
namespace: production
spec:
entryPoints:
- websecure
routes:
- match: Host(`api.example.com`) && PathPrefix(`/v1/`)
kind: Rule
services:
- name: backend-service
port: 8080
weight: 100
# 负载均衡策略
stickiness:
cookieName: traefik_sticky
secure: true
# TLS配置
tls:
secretName: example-com-tls
options:
name: tls-options
namespace: production
---
# 中间件配置(限流)
apiVersion: traefik.containo.us/v1alpha1
kind: Middleware
metadata:
name: rate-limit
namespace: production
spec:
rateLimit:
average: 100 # 平均100请求/秒
burst: 200 # 突发200请求/秒
性能优化要点:
- 调整并发数:通过环境变量
TRAEFIK_GLOBAL_SERVERSTRANSORT_MAXIDLECONNSPERHOST调整。 - 启用缓存:使用Redis缓存认证Token等。
- 优化Kubernetes集成:限制监听的命名空间,减少事件处理开销。
三、性能基准测试与数据分析
3.1 测试环境配置
为了公平对比三种网关,我们搭建了如下测试环境:
硬件配置:
-
网关节点:3台服务器
- CPU:Intel Xeon Gold 6248R @ 3.0GHz(48核)
- 内存:128GB DDR4
- 网卡:Mellanox ConnectX-5 100Gbps
- 操作系统:Ubuntu 22.04 LTS,内核 5.15.0-91-generic
-
上游服务节点:10台服务器(配置同上)
-
客户端压测节点:5台服务器(配置同上)
软件版本:
- Nginx:1.25.3(编译选项:
--with-http_ssl_module --with-http_v2_module --with-stream) - Envoy:1.28.0
- Traefik:2.10.4
- 上游服务:基于Go的HTTP服务(返回"Hello World")
测试工具:
- wrk:HTTP性能测试工具
- hey:HTTP压力测试工具
- vegeta:HTTP负载测试工具
3.2 吞吐量测试(RPS)
测试方法:
使用wrk进行压测,逐步增加并发连接数,测量每秒请求数(RPS)。
# wrk压测命令
# 测试1:HTTP/1.1,Keep-Alive
wrk -t48 -c1000 -d60s --latency http://gateway.example.com/
# 测试2:HTTP/2
wrk -t48 -c1000 -d60s --latency -H "Connection: keep-alive" https://gateway.example.com/
# 参数说明:
# -t48:48个线程(等于CPU核心数)
# -c1000:1000个并发连接
# -d60s:测试60秒
# --latency:报告延迟统计
测试结果(单位:RPS,越高越好):
| 网关 | HTTP/1.1(1KB响应) | HTTP/1.1(10KB响应) | HTTP/2(1KB响应) | HTTP/2(10KB响应) |
|---|---|---|---|---|
| Nginx | 245,000 | 180,000 | N/A | N/A |
| Envoy | 198,000 | 145,000 | 235,000 | 170,000 |
| Traefik | 165,000 | 120,000 | 185,000 | 135,000 |
关键发现:
- Nginx在HTTP/1.1下性能最优:RPS达245,000,比Envoy高23.7%。
- Envoy在HTTP/2下性能优异:充分利用HTTP/2的多路复用,性能接近Nginx的HTTP/1.1。
- Traefik性能相对较低:但配置简单,适合中小规模场景。
3.3 延迟测试
测试方法:
使用wrk测量P50、P99延迟。
# 解析wrk输出,提取延迟数据
wrk -t48 -c1000 -d60s --latency http://gateway.example.com/ 2>&1 | grep -A 20 "Latency"
# 输出示例:
# Latency Distribution
# 50% 3.25ms
# 75% 4.82ms
# 90% 7.15ms
# 99% 15.30ms
测试结果(单位:毫秒,越低越好):
| 网关 | P50延迟 | P99延迟 | P99.9延迟 |
|---|---|---|---|
| Nginx | 3.2 | 12.5 | 28.3 |
| Envoy | 3.8 | 15.2 | 35.7 |
| Traefik | 4.5 | 18.6 | 42.1 |
关键发现:
- Nginx延迟最低:P50仅3.2ms,P99 12.5ms。
- Envoy延迟略高:由于功能更丰富,处理开销稍大。
- Traefik延迟最高:但差距在可接受范围内(<2ms)。
3.4 并发连接测试
测试方法:
逐步增加并发连接数,测量网关的最大并发处理能力。
# 使用hey进行高并发测试
hey -n 10000000 -c 10000 -q 10000 -t 60 http://gateway.example.com/
# 参数说明:
# -n 10000000:总请求数1000万
# -c 10000:10000个并发连接
# -q 10000:每秒10000请求
# -t 60:超时60秒
测试结果:
| 网关 | 最大并发连接数 | 连接建立速率(连接/秒) | 失败率(%) |
|---|---|---|---|
| Nginx | 100,000 | 85,000 | 0.02 |
| Envoy | 80,000 | 65,000 | 0.05 |
| Traefik | 50,000 | 40,000 | 0.12 |
关键发现:
- Nginx并发能力最强:支持10万并发连接,失败率仅0.02%。
- Envoy次之:并发8万,适合大规模微服务场景。
- Traefik适合中小规模:并发5万,满足大多数场景。
3.5 资源消耗测试
测试方法:
在压测过程中,监控网关的CPU和内存占用。
# 监控Nginx资源消耗
# 使用pidstat监控CPU
pidstat -u -p $(pgrep nginx) 1 60 > nginx_cpu.log
# 使用ps监控内存
ps aux | grep nginx | awk '{print $6}' > nginx_mem.log
# 计算平均值
avg_cpu=$(cat nginx_cpu.log | awk '{sum+=$8} END {print sum/NR}')
avg_mem=$(cat nginx_mem.log | awk '{sum+=$1} END {print sum/NR/1024 " MB"}')
echo "Nginx平均CPU: $avg_cpu%"
echo "Nginx平均内存: $avg_mem"
测试结果(压测期间平均值):
| 网关 | CPU占用率(%) | 内存占用(MB) | 内存增长(MB/小时) |
|---|---|---|---|
| Nginx | 35 | 120 | 0 |
| Envoy | 45 | 350 | 5 |
| Traefik | 40 | 280 | 3 |
关键发现:
- Nginx资源消耗最低:CPU 35%,内存120MB,且内存稳定。
- Envoy资源消耗较高:CPU 45%,内存350MB,但功能更丰富。
- Traefik资源消耗中等:Go语言实现,GC可能导致内存波动。
3.6 TLS性能测试
测试方法:
测试HTTPS场景下的性能,测量TLS握手开销。
# 使用openssl s_time测量TLS握手时间
openssl s_time -connect gateway.example.com:443 -www / -tls1_2
# 使用wrk测试HTTPS吞吐量
wrk -t48 -c1000 -d60s --latency https://gateway.example.com/
测试结果:
| 网关 | TLS握手时间(ms) | HTTPS RPS(1KB响应) | TLS开销(vs HTTP) |
|---|---|---|---|
| Nginx | 2.5 | 180,000 | 26.5% |
| Envoy | 3.2 | 165,000 | 16.7% |
| Traefik | 4.1 | 130,000 | 21.2% |
关键发现:
- Nginx TLS性能最优:TLS握手仅2.5ms,HTTPS RPS 18万。
- Envoy TLS开销最小:相比HTTP/1.1,性能仅下降16.7%。
- Traefik TLS性能较差:TLS握手4.1ms,适合低并发HTTPS场景。
四、架构取舍与选型建议
4.1 场景化选型框架
基于上述测试数据,我们提出以下选型框架:
graph TD
A[开始网关选型] --> B{并发规模?}
B -->|<10,000并发| C{需要自动服务发现?}
B -->|10,000-100,000并发| D{需要L7高级功能?}
B -->|>100,000并发| E{团队技术栈?}
C -->|是| F[Traefik]
C -->|否| G[Nginx]
D -->|是| H[Envoy]
D -->|否| I[Nginx]
E -->|熟悉Nginx| I
E -->|熟悉Envoy/Istio| H
E -->|Kubernetes原生| F
F --> Z[最终选型]
G --> Z
H --> Z
I --> Z
style F fill:#e8f5e9
style H fill:#fff3e0
style I fill:#e1f5fe
4.2 场景化推荐
场景1:小规模集群(<50节点,<10,000并发)
- 推荐:Traefik
- 理由:配置简单,自动服务发现,功能足够。
- 配置示例:
# docker-compose.yml with Traefik
version: '3.7'
services:
traefik:
image: traefik:v2.10
command:
- "--providers.docker=true"
- "--providers.docker.exposedbydefault=false"
- "--entrypoints.web.address=:80"
ports:
- "80:80"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
whoami:
image: traefik/whoami
labels:
- "traefik.enable=true"
- "traefik.http.routers.whoami.rule=Host(`whoami.localhost`)"
场景2:中等规模集群(50-500节点,10,000-100,000并发)
- 推荐:Nginx 或 Envoy
- 理由:性能优异,功能完整。
- Nginx适用:传统架构,团队熟悉Nginx。
- Envoy适用:云原生架构,已使用Istio。
场景3:大规模集群(>500节点,>100,000并发)
- 推荐:Nginx(入口网关)+ Envoy(服务网格)
- 理由:Nginx作为边缘网关性能极致,Envoy作为服务网格数据平面功能丰富。
- 架构示例:
客户端 → Nginx(边缘网关) → Envoy(服务网格) → 微服务
4.3 性能优化最佳实践
Nginx优化:
# 1. 启用reuseport(Linux 3.9+)
listen 80 reuseport;
# 2. 调整Worker进程数
worker_processes auto;
worker_cpu_affinity auto;
# 3. 优化TCP参数(系统级)
# /etc/sysctl.conf
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1
Envoy优化:
# 1. 调整线程数
--concurrency 48 # 等于CPU核心数
# 2. 优化连接池
circuit_breakers:
thresholds:
- max_connections: 20000
max_requests: 50000
# 3. 启用HTTP/2
http2_protocol_options:
allow_connect: true
max_concurrent_streams: 100
Traefik优化:
# traefik.yaml
# 1. 调整并发参数
serversTransport:
maxIdleConnsPerHost: 200
idleConnTimeout: 90s
# 2. 启用响应压缩
compress:
excludedContentTypes:
- text/event-stream
# 3. 调整Kubernetes客户端参数
providers:
kubernetesCRD:
throttleDuration: 5s # 减少事件处理频率
五、总结
本文通过系统的性能基准测试,深度对比了Nginx、Envoy和Traefik三种云原生网关在吞吐量、延迟、并发能力和资源消耗方面的表现。测试结果表明,三种网关各有优势,应根据具体场景选择。
核心结论:
- Nginx性能最优:吞吐量、延迟、并发能力均领先,适合高性能场景。
- Envoy功能最丰富:内置服务发现、负载均衡、追踪等,适合云原生架构。
- Traefik最易用:自动服务发现,配置简单,适合快速迭代场景。
选型建议:
- 边缘网关:优先选择Nginx(性能极致)或Envoy(功能丰富)。
- 服务网格:选择Envoy(Istio默认数据平面)。
- Kubernetes Ingress Controller:选择Traefik(Kubernetes原生集成)或Nginx Ingress Controller。
未来展望:
随着云原生技术的发展,网关将朝着以下方向演进:
- eBPF加速:使用eBPF绕过内核网络栈,进一步降低延迟(如Cilium)。
- WebAssembly扩展:使用WASM扩展网关功能(如Envoy WASM)。
- AI驱动的自适应优化:基于机器学习自动调整网关参数。
通过深入理解各网关的性能和特性,架构师可以做出更明智的技术选型,构建高性能、高可用的云原生架构。
更多推荐


所有评论(0)