Nginx高可用配置实战:负载均衡 + 健康检查 + 动态扩展

🚀 Nginx高可用配置实战:负载均衡 + 健康检查 + 动态扩展

一篇从零搭建到实测上线的高可用 Nginx 负载均衡案例教程。


🧭 一、背景与目标

在现代业务中,单台应用服务器往往无法承载高并发请求。

Nginx 作为轻量级高性能的反向代理服务器,能同时实现:

  • 负载均衡(分担后端压力)
  • 健康检查(自动移除异常节点)
  • 动态扩展(不重启即更新配置)

本文通过一个电商商品服务集群 的实战项目,带你从零实现高可用 Nginx 架构。


🏗️ 二、项目架构设计

我们模拟一个商品服务集群(product service):

节点名称 IP 说明
app1 192.168.10.101 主节点
app2 192.168.10.102 副节点
app3 192.168.10.103 扩容节点
nginx-lb 192.168.10.10 负载均衡代理服务器

请求流程如下:

复制代码
Client → Nginx (负载均衡+健康检查)
          ↓
   ┌───────────────┬───────────────┬───────────────┐
   │ App1          │ App2          │ App3          │
   │ 商品服务节点1 │ 商品服务节点2 │ 商品服务节点3 │
   └───────────────┴───────────────┴───────────────┘

⚙️ 三、负载均衡基础配置

1️⃣ 安装 Nginx

bash 复制代码
sudo apt update
sudo apt install nginx -y

查看版本:

bash 复制代码
nginx -v

2️⃣ 配置 upstream 实现负载均衡

编辑 /etc/nginx/conf.d/loadbalance.conf

nginx 复制代码
upstream product_cluster {
    # 轮询策略(默认)
    server 192.168.10.101:8080 max_fails=3 fail_timeout=10s;
    server 192.168.10.102:8080 max_fails=3 fail_timeout=10s;
    server 192.168.10.103:8080 max_fails=3 fail_timeout=10s backup;
}

server {
    listen 80;
    server_name product.demo.local;

    location / {
        proxy_pass http://product_cluster;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

🔹 轮询模式默认自动分配请求

🔹 max_fails:健康检查失败次数阈值

🔹 backup:备用节点,仅主节点失效时启用

保存后测试:

bash 复制代码
nginx -t
systemctl reload nginx

🩺 四、加入健康检查模块

Nginx 开源版不自带健康检查模块,我们可通过 ngx_http_upstream_check_modulenginx-plus 实现。

实战方案(使用 openresty)

如果使用 OpenResty (推荐)

bash 复制代码
sudo apt install openresty -y

配置文件 /usr/local/openresty/nginx/conf/nginx.conf

nginx 复制代码
http {
    upstream product_cluster {
        server 192.168.10.101:8080;
        server 192.168.10.102:8080;
        check interval=5000 rise=2 fall=5 timeout=3000 type=http;
        check_http_send "HEAD /health HTTP/1.0\r\n\r\n";
        check_http_expect_alive http_2xx http_3xx;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://product_cluster;
        }

        location /status {
            check_status;
            access_log off;
            allow 192.168.10.0/24;
            deny all;
        }
    }
}

访问 http://nginx-lb/status 可以实时看到健康状态:

IP 状态 延迟
192.168.10.101 up 12ms
192.168.10.102 down -
192.168.10.103 up 8ms

♻️ 五、实现动态扩展与热更新

当新增一台应用服务器时,只需修改 upstream 段:

bash 复制代码
upstream product_cluster {
    include /etc/nginx/upstreams/*.conf;
}

然后在 /etc/nginx/upstreams/ 目录中增加或删除节点配置文件:

bash 复制代码
echo "server 192.168.10.104:8080;" > /etc/nginx/upstreams/node4.conf

无需重启,仅需平滑加载:

bash 复制代码
nginx -s reload

👉 这样 Nginx 就能动态感知新节点加入!


📊 六、日志分析与请求分布监控

打开访问日志:

复制代码
/var/log/nginx/access.log

内容示例:

复制代码
192.168.10.201 - - [05/Nov/2025:14:32:01 +0800] "GET /api/product/1001 HTTP/1.1" 200 524 "-" "Mozilla" upstream_addr=192.168.10.101:8080
192.168.10.201 - - [05/Nov/2025:14:32:02 +0800] "GET /api/product/1002 HTTP/1.1" 200 530 "-" "Mozilla" upstream_addr=192.168.10.102:8080

我们可以统计各节点命中率:

bash 复制代码
awk '{print $NF}' /var/log/nginx/access.log | sort | uniq -c | sort -nr

输出:

复制代码
240 192.168.10.101:8080
235 192.168.10.102:8080
225 192.168.10.103:8080

通过 Grafana + Loki,还能将这些日志实时可视化。


🔍 七、实战验证

模拟异常场景:

bash 复制代码
sudo systemctl stop product-service@192.168.10.102

访问 /status 页面:

节点 状态
app1 up
app2 ❌ down
app3 up

Nginx 自动将 app2 从负载池中移除,保持服务不中断。

恢复服务后再次上线:

bash 复制代码
sudo systemctl start product-service@192.168.10.102

状态自动恢复为 "up"。


🧩 八、性能与高可用总结

功能 技术点 说明
负载均衡 upstream 轮询 均衡分配请求
健康检查 openresty check 模块 自动移除异常节点
动态扩展 include + reload 实现节点热更新
监控分析 日志统计 + Grafana 实时监控请求分布

🔖 九、项目实战结构目录

复制代码
/etc/nginx/
 ├── conf.d/
 │    └── loadbalance.conf
 ├── upstreams/
 │    ├── node1.conf
 │    ├── node2.conf
 │    └── node3.conf
 ├── logs/
 │    └── access.log
 └── nginx.conf

🧠 十、总结与思考

通过本次实战,我们实现了:

  • ✅ 从零搭建 Nginx 负载均衡集群
  • ✅ 健康检测与节点自动剔除
  • ✅ 动态扩展不影响业务
  • ✅ 日志实时分析请求命中率

这套方案非常适合中小企业、内部微服务架构、测试环境或生产高可用场景。


💬 互动

💡 你在生产环境中遇到过 Nginx 负载不均或节点故障的问题吗?

留言告诉我你最想了解的高可用方案,下篇文章我写"Keepalived + Nginx 双主高可用集群"实战。

相关推荐
用户03284722207018 小时前
如何搭建本地yum源(上)
运维
ping某2 天前
为什么 Nginx 明明监听了 80,转发后端时却用了 4xxxx 端口?
后端·nginx
大树884 天前
金刚石散热越强,管路越先见顶
大数据·运维·服务器·人工智能·ai
摇滚侠4 天前
Linux CentOS7 rpm 安装 MySQL 5.7
linux·运维·mysql
霸道流氓气质4 天前
领域驱动设计(DDD)在 Spring Boot 微服务中的实践指南
运维·spring boot·微服务
Inhand陈工4 天前
基于台达PLC与映翰通IG502的智慧水产养殖精准投喂与远程运维解决方案
运维·人工智能·物联网·阿里云·信息与通信
酣大智4 天前
ARP代理--工作原理
运维·网络·arp·arp代理
shushangyun_4 天前
2026年快消品B2B系统推荐:支持终端门店订货、促销政策自动化的工具?
java·运维·网络·数据库·人工智能·spring·自动化
施努卡机器视觉4 天前
SNK施努卡侧滑门锁上滑轮总成自动化装配线,从零件到组件,全流程精密制造方案
运维·自动化·制造
lunzi_08264 天前
【开源治理】05-把流程翻译成门禁:开源治理嵌入 DevOps 流水线实战
供应链管理·devops·开源治理