一、引言从单点到集群流量分发的艺术当你的应用用户量从几百飙升到几万单台服务器很快就会成为性能瓶颈甚至面临宕机风险。此时最直接有效的解决方案就是横向扩展——部署多台服务器组成集群。但新问题随之而来客户端如何知道该访问哪一台服务器如果其中一台挂了怎么办答案就是“反向代理 负载均衡”。Nginx 完美地将这两个功能融为一体反向代理作为统一入口对外隐藏后端服务器集群。负载均衡作为智能调度员将流量合理、高效地分发给集群中的每一台服务器。本文将手把手教你配置 Nginx打造一个高性能、高可用的服务集群。核心价值掌握此技能你就能轻松应对流量洪峰告别单点故障为业务稳定保驾护航二、核心基石upstream模块在 Nginx 中负载均衡的能力由upstream上游服务器模块提供。它允许你定义一组后端服务器并指定流量分发的策略。基本语法# 在 http 块内定义 upstream backend { server backend1.example.com weight5; server backend2.example.com; server 192.0.0.1 backup; }upstream backend:backend是这个服务器组的名字后续在proxy_pass中会用到。server: 定义一个后端服务器可以是域名或IP端口。weight: 权重默认为1。权重越高接收的请求越多。backup: 标记为备份服务器。只有当所有非备份服务器都不可用时才会启用它。三、四大主流负载均衡策略详解Nginx 提供了多种算法来满足不同场景的需求。策略一轮询Round Robin - 默认策略这是最简单也最常用的策略。Nginx 会按顺序将请求依次分发给服务器列表中的每一台。upstream myapp { server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; }效果请求1 - Server1, 请求2 - Server2, 请求3 - Server3, 请求4 - Server1...策略二加权轮询Weighted Round Robin当你的服务器硬件配置不同时如一台16核两台8核可以通过权重让更强的机器承担更多流量。upstream myapp { server 192.168.1.10:8080 weight3; # 配置最强承担3份流量 server 192.168.1.11:8080 weight1; # 承担1份流量 server 192.168.1.12:8080 weight1; # 承担1份流量 }效果每5个请求中3个去Server11个去Server21个去Server3。策略三IP哈希IP Hash此策略能保证同一个客户端IP的请求始终被转发到同一台后端服务器。这在需要会话保持Session Sticky但又不想使用共享Session存储的场景下非常有用。upstream myapp { ip_hash; # 启用IP哈希 server 192.168.1.10:8080; server 192.168.1.11:8080; }注意如果后端服务器数量发生变化原有的IP映射关系会被打乱。策略四最少连接Least ConnectionsNginx 会将新请求分配给当前活跃连接数最少的服务器。这在处理长连接或请求处理时间差异较大的场景下更为公平。upstream myapp { least_conn; # 启用最少连接 server 192.168.1.10:8080; server 192.168.1.11:8080; }四、生产级完整配置示例一个健壮的负载均衡配置除了upstream还需要包含健康检查、超时设置和必要的请求头。http { # 定义上游服务器组 upstream backend_servers { # 使用加权轮询 server 192.168.1.10:8080 weight3 max_fails2 fail_timeout30s; server 192.168.1.11:8080 weight1 max_fails2 fail_timeout30s; # 备份服务器 server 192.168.1.12:8080 backup; } server { listen 80; server_name app.example.com; location / { # 反向代理到 upstream proxy_pass http://backend_servers; # 必须设置的请求头 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 10s; # 发送请求给后端的超时 proxy_read_timeout 10s; # 读取后端响应的超时 } } }关键参数解释max_fails2: 在fail_timeout时间内如果尝试失败达到2次则认为此服务器不可用。fail_timeout30s: 服务器被判定为不可用后的暂停服务时间30秒后会再次尝试。backup: 仅在其他所有服务器都失效时才启用用于兜底。五、高级特性被动健康检查与主动健康检查上面的max_fails和fail_timeout属于被动健康检查——只有当有真实请求过来并失败时Nginx 才会标记服务器为宕机。对于更高要求的场景Nginx Plus商业版或开源版本结合第三方模块如nginx_upstream_check_module可以实现主动健康检查即 Nginx 主动定期向后端服务器发送探测请求如/health无需等待真实用户请求。# (此为概念性配置开源版需打补丁) upstream backend { server 192.168.1.10:8080; server 192.168.1.11:8080; check interval3000 rise2 fall3 timeout1000 typehttp; check_http_send GET /health HTTP/1.0\r\n\r\n; check_http_expect_alive http_2xx http_3xx; }六、结语感谢您的阅读如果你有任何疑问或想要分享的经验请在评论区留言交流
