Nginx API 网关中间件运维性能优化实践

场景

假设您负责一个基于微服务架构的生产环境，Nginx 作为所有 API 请求的统一入口。白天业务高峰期间，您开始收到用户投诉，部分接口响应时间从 200ms 飙升至 5s 以上，甚至出现超时错误。团队内部初步排查发现 Nginx 所在节点的 CPU 使用率始终保持在 90% 以上，且连接队列持续堆积。

症状

• 高延迟：API 平均响应时间显著上升，p99 延迟超出业务容忍阈值。
• 错误率增加：出现大量 504 Gateway Timeout 和 502 Bad Gateway 错误。
• 连接异常：Nginx 的 active connections 接近 max_connections 限制，大量连接处于 waiting 状态。
• 资源紧张：Nginx worker 进程 CPU 占用率高，系统 load average 超过核数。
• 后端压力不均衡：某些 upstream 服务响应时间极长，甚至超时。

诊断

1. 确认症状来源

首先查看 Nginx 错误日志和访问日志，定位错误返回的具体请求路径和 upstream 响应状态。

# 错误日志（通常位于 /var/log/nginx/error.log）
tail -n 100 /var/log/nginx/error.log

# 访问日志，过滤 5xx 错误
grep ' 5[0-9][0-9] ' /var/log/nginx/access.log | tail -n 100

如果日志中出现 upstream timed out (110: Connection timed out)，则说明 Nginx 与后端服务之间的网络连接超时。

2. 查看实时连接状态

Nginx 提供了 stub_status 模块，可以获取当前连接状态。确保在配置中启用：

location /nginx_status {
    stub_status;
    allow 127.0.0.1;  # 限制访问，避免内部信息暴露
    deny all;
}

执行：

curl http://127.0.0.1/nginx_status
# 输出示例：
# Active connections: 1234
# server accepts handled requests
#  567890 567890 567890
# Reading: 5 Writing: 30 Waiting: 1199

如果 Waiting 数量持续高涨，表示大量连接处于空闲等待状态，可能是 keepalive 配置不当。

3. 检查后端 upstream 健康状态

使用工具测试各 upstream 的响应时间：

for url in http://service1:8080/health http://service2:8080/health; do
  echo "$url: $(curl -o /dev/null -s -w '%{http_code} %{time_total}\n' $url)"
done

同时检查后端服务的日志，确认是否存在慢 SQL 或资源瓶颈。

4. 分析系统性能

# CPU 和内存使用情况
top -bn1 | head -n 20

# 网络连接状态
ss -s

# 观察 worker 进程状态
ps aux | grep nginx

若发现 nginx: worker process 占用大量 CPU，且每个 worker 的 CPU 消耗接近 100%，则可能是 CPU 密集型的 TLS 加密或路由匹配逻辑导致。

5. 检查内核和 Nginx 配置

# 查看文件描述符限制
ulimit -n

# 查看 TCP 连接队列长度
cat /proc/sys/net/core/somaxconn

# Nginx 当前配置项
ginx -T | grep -E 'worker_processes|worker_connections|keepalive|proxy_read_timeout'

命令与操作

1. 安全调整 Nginx 配置

在修改前，备份现有配置：

cp -r /etc/nginx /etc/nginx.bak.$(date +%Y%m%d%H%M%S)

修改关键参数，例如：

events {
    worker_connections 10240;
    use epoll;
}

http {
    keepalive_timeout 65;
    keepalive_requests 1000;
    proxy_connect_timeout 5s;
    proxy_read_timeout 30s;
    proxy_send_timeout 30s;
    upstream backend {
        server service1:8080 max_fails=3 fail_timeout=30s;
        server service2:8080 max_fails=3 fail_timeout=30s;
        keepalive 32;  # 保存连接到 upstream 的 keepalive 连接数
    }
}

重点关注： - worker_processes 通常设置为 CPU 核数，避免过高的上下文切换。 - worker_connections 需根据系统文件描述符限制和实际并发量调整。 - 使用 epoll 事件模型提高性能。 - 为 upstream 启用 keepalive 连接池，减少 TCP 握手开销。

修改后测试配置：

nginx -t

如果测试通过，进行平滑重载：

nginx -s reload

安全提示：nginx -s reload 不会中断现有连接，是安全的操作。但若配置语法错误，请勿强制重载，应先修正。

2. 实施限流与缓冲

如果 API 网关面临流量突发，可临时启用限流模块：

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;

location /api/ {
    limit_req zone=api_limit burst=20 nodelay;
    proxy_pass http://backend;
}

设置合理的代理缓冲，避免内存溢出：

proxy_buffering on;
proxy_buffer_size 4k;
proxy_buffers 8 4k;
proxy_busy_buffers_size 8k;

风险控制

• 灰度发布：在部分节点或测试环境先行验证配置变更，确认无异常后再全量生效。
• 回滚准备：保留上一版配置，当重载后发现错误率上升，可立即执行 nginx -s reload 恢复旧配置（需先备份旧配置内容）。
• 监控告警：操作期间应密切监控 Nginx 的 active connections、错误率、后端响应时间等关键指标。建议设置阈值告警，如错误率超过 1% 或 p99 延迟超过 500ms 立即触发告警。
• 避免过度调优：每次只修改一个参数，并以可度量的数据作为依据，防止引入不可预估的行为。

回滚

如果重载后问题加剧，或出现新的错误（如连接拒绝），使用备份配置回滚：

# 恢复备份
cp /etc/nginx.bak/nginx.conf /etc/nginx/nginx.conf
# 测试并重载
nginx -t && nginx -s reload

如果配置本身并没有问题，但 Nginx 进程出现崩溃，可以执行：

ginx -s quit   # 优雅退出，等待所有请求处理完
systemctl restart nginx

安全提示：不要使用 nginx -s stop 强制终止，否则可能丢失正在处理的请求。

验证

• 功能验证：使用 curl 测试几个关键 API 端点，确认响应正常，无 5xx 错误。
• 性能验证：再次运行 curl -w 命令测量响应时间，或使用 Apache Bench（ab）进行简单压测： bash ab -n 1000 -c 100 https://your-gateway/api/health
• 日志验证：检查错误日志是否仍有新条目，观察访问日志中的响应时间分布。
• 监控指标：确认 active connections 有所下降，CPU 使用率回落到正常水平。

何时提交 OpsGlobal 工单

如果您在按照上述步骤操作后，性能问题仍未解决，或出现以下情况，建议立即提交 OpsGlobal 工单：

• 内核参数调优：需要修改 net.ipv4.tcp_tw_reuse、net.core.somaxconn 等系统级参数，但不确定对上层业务的影响。
• 架构层面问题：例如 upstream 服务出现连接池耗尽，需要压测评估容量，或需要设计更复杂的负载均衡策略。
• 安全与合规要求：需要在不影响性能的前提下增强 WAF 规则，或配置 mTLS 双向认证。
• 持续性能瓶颈：经过多次配置调整仍无法满足 SLA 要求，需要专业的性能分析与调优建议。

OpsGlobal 的 SRE 专家团队提供 7×24 小时远程支持，可协助您进行深度性能剖析、配置优化及故障恢复，确保 API 网关稳定高效运行。

---

本文由 OpsGlobal 技术团队撰写，我们专注于商业级 DevOps/SRE 运维支持服务，助您应对各种基础设施挑战。