Nginx 负载均衡配置实战

在真实的企业级项目中，只部署一个后端服务几乎是不可接受的：

• 并发一高就扛不住
• 服务宕机就全站不可用
• 无法平滑扩容

解决这些问题的核心技术之一，就是 负载均衡。

而在 Web 架构中，Nginx + 负载均衡 = 最经典、最稳定、最成熟的方案。

本文将从 原理、配置方式、调度策略、实战案例、生产注意事项 五个方面，完整讲清楚：

❝

如何使用 Nginx 实现负载均衡，并真正用在企业项目中

一、什么是负载均衡

1. 负载均衡解决什么问题

负载均衡的本质是：

❝

将大量请求，合理分发到多台后端服务器上处理

它主要解决四个核心问题：

1. 提高系统并发能力
2. 避免单点故障
3. 提升系统整体可用性
4. 支持水平扩展

2. 没有负载均衡的架构

问题非常明显：

• 并发瓶颈
• 服务宕机直接不可用
• 无法扩容

3. 引入 Nginx 负载均衡后的架构

Nginx 成为统一入口：

• 客户端永远只访问 Nginx
• 后端服务器数量可动态增减
• Nginx 自动分发请求

二、Nginx 负载均衡的核心概念

1. upstream 模块

在 Nginx 中，负载均衡的核心是 upstream。

upstream backend_server {
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

upstream 的作用是：

• 定义一组后端服务器
• 提供统一的访问标识

2. proxy_pass 与 upstream 的配合

location /api/ {
    proxy_pass http://backend_server;
}

这里要注意：

• proxy_pass 指向的是 upstream 名称
• Nginx 会在 upstream 中选择一台服务器

三、最基础的负载均衡实战配置

1. 后端服务准备

假设你有三个后端服务：

• 127.0.0.1:8081
• 127.0.0.1:8082
• 127.0.0.1:8083

2. 最简单的负载均衡配置

http {

    upstream api_backend {
        server 127.0.0.1:8081;
        server 127.0.0.1:8082;
        server 127.0.0.1:8083;
    }

    server {
        listen 80;
        server_name localhost;

        location /api/ {
            proxy_pass http://api_backend;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

此时：

• 所有 /api/* 请求
• 会被自动分发到三台服务器

3. 默认负载均衡策略

如果你什么都不配置，Nginx 默认使用轮询（Round Robin）：

请求 1 -> 8081
请求 2 -> 8082
请求 3 -> 8083
请求 4 -> 8081

这是最常见、最稳定的策略。

四、Nginx 常见负载均衡策略详解

1. 轮询（默认）

upstream api_backend {
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

特点：

• 请求平均分配
• 适合性能相近的服务器

2. 权重（weight）

upstream api_backend {
    server 127.0.0.1:8081 weight=3;
    server 127.0.0.1:8082 weight=1;
}

分配规则：

4 次请求中：
3 次 -> 8081
1 次 -> 8082

适合场景：

• 服务器性能不一致
• 新旧机器混用

3. IP 哈希（ip_hash）

upstream api_backend {
    ip_hash;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

特点：

• 同一客户端 IP 总是访问同一台服务器
• 可解决简单的会话保持问题

缺点：

• 某台服务器压力可能过大
• 不适合高并发场景

4. 最少连接（least_conn）

upstream api_backend {
    least_conn;
    server 127.0.0.1:8081;
    server 127.0.0.1:8082;
}

特点：

• 请求分配给当前连接数最少的服务器
• 适合处理时间不均衡的请求

五、负载均衡 + 前后端分离实战

1. 实际项目架构

flowchart LR
    Browser[浏览器] --> Nginx[Nginx]
    Nginx --> Frontend[前端静态资源]
    Nginx --> API1[后端 API 1]
    Nginx --> API2[后端 API 2]

2. 完整配置示例

http {

    upstream api_backend {
        least_conn;
        server 192.168.1.101:8080;
        server 192.168.1.102:8080;
    }

    server {
        listen 80;
        server_name example.com;

        location / {
            root /usr/share/nginx/html;
            index index.html;
            try_files $uri $uri/ /index.html;
        }

        location /api/ {
            proxy_pass http://api_backend;

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        }
    }
}

前端代码中只需请求：

axios.get('/api/user/list')

六、后端宕机与健康检查

1. Nginx 的被动健康检查

upstream api_backend {
    server 127.0.0.1:8081 max_fails=3 fail_timeout=30s;
    server 127.0.0.1:8082 max_fails=3 fail_timeout=30s;
}

含义：

• 30 秒内失败 3 次
• 该服务器暂时不再被使用

2. 生产环境建议

• 至少 2 台后端服务器
• 配置 max_fails
• 配合日志监控

七、负载均衡常见问题

1. Session 丢失问题

原因：

• 请求被分发到不同服务器

解决方案：

1. ip_hash（不推荐高并发）
2. Session 存 Redis（推荐）
3. 使用 JWT 无状态方案（最佳）

2. 请求分配不均

排查方向：

• 是否启用了权重
• 是否使用 ip_hash
• 后端性能是否一致

八、企业级负载均衡实践建议

1. Nginx 只做流量入口
2. 后端尽量无状态
3. Session 外置（Redis）
4. 配合日志与监控
5. 负载均衡策略根据业务选择

九、总结

负载均衡不是“高并发才需要”，而是：

❝

任何一个认真做架构的项目，从一开始就应该考虑的问题

Nginx 负载均衡的优势在于：

• 配置简单
• 性能极高
• 稳定成熟
• 企业实践丰富

只要你做的是 Web 项目，Nginx 负载均衡几乎是绕不开的一环。