云服务器负载均衡：Nginx/HAProxy 配置与健康检查

先说结论：两台以上应用服务器才需要负载均衡。七层用 Nginx 最省事，四层和高性能用 HAProxy 或 LVS，云厂商的负载均衡产品最省运维但要多花钱。不管用哪种，健康检查和会话处理没做好，扩容反而会放大故障。

什么时候需要负载均衡

单机 QPS 到拐点，加机器能线性提升
要做滚动发布、灰度、蓝绿部署
需要故障自动摘除，避免一台挂全站挂
要统一入口做 TLS、限流、日志

如果只有一台机器、流量也不大，先优化缓存和慢查询，别急着上负载均衡。

三种方案怎么选

方案	层级	适合	注意
Nginx	七层 HTTP	Web、API、静态资源	改配置 reload，健康检查较弱
HAProxy	四层/七层	TCP、HTTP、长连接	配置稍复杂，性能好
LVS	四层	超高并发、入口层	运维门槛高
云负载均衡	四层/七层	不想自己维护	按量计费，规则受产品限制

负载均衡节点连接三台上游服务器的架构图 — 七层用 Nginx，四层和高性能用 HAProxy 或 LVS。

Nginx 怎么做

upstream app {
    least_conn;
    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
    keepalive 32;
}

server {
    location / {
        proxy_pass http://app;
        proxy_http_version 1.1;
        proxy_set_header Connection "";
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_connect_timeout 3s;
        proxy_read_timeout 60s;
    }
}

max_fails 和 fail_timeout 是最基础的被动健康检查：连续失败几次就先摘掉，过一段时间再试。它不如主动探测准，但够用。

HAProxy 怎么做

backend app
    balance leastconn
    option httpchk GET /health
    server app1 10.0.0.11:8080 check inter 3s fall 3 rise 2
    server app2 10.0.0.12:8080 check inter 3s fall 3 rise 2

HAProxy 的主动健康检查更完整，适合对故障切换要求高的场景。长连接、WebSocket、TCP 转发也比 Nginx 更直接。

健康检查探测，一台服务器被标记故障并切走流量 — 健康检查要查依赖，不要只查端口。

健康检查怎么做

健康检查接口不要只返回 200，要检查依赖：数据库能不能连、Redis 能不能 ping、磁盘是否可写。否则应用已经半死，负载均衡还在给它分流量。

接口路径固定，例如 /health
超时要短，避免拖垮探测
失败阈值和恢复阈值分开设置
别把健康检查做成重查询

会话和高可用

应用要无状态，session 放 Redis 或数据库；必须粘性会话时，用 cookie 或源 IP，但要接受节点故障时会话丢失。负载均衡器本身也不能是单点：两台 Nginx + Keepalived VIP，或者直接用云负载均衡。

浮动 IP 从故障服务器切换到备用服务器 — 负载均衡器本身也不能是单点，主备或云 LB 二选一。

常见坑

拿不到真实 IP：没配 X-Forwarded-For 和 real_ip 模块，日志全是 LB 的 IP
超时不对齐：LB 60 秒、应用 30 秒、数据库 5 秒，内层先失败才对
WebSocket 断连：没设 Upgrade 头和长连接超时
健康检查误杀：依赖抖动导致全部节点被摘
会话丢失：登录态存在本地文件，切节点就掉线

灰度和发布

负载均衡也是发布工具。把新版本挂到一个 upstream，按权重 5%、20%、50% 逐步放量，观察错误率和延迟，再全量。出问题把权重切回 0，比回滚代码快得多。

TLS、限流和日志

统一在 LB 层做 TLS 终止，证书只维护一份；限流也放在这一层，按 IP、路径、用户维度设阈值。访问日志记下真实 IP、上游耗时和状态码，后面排查 502/504 会省很多事。

监控看什么

看三个数：上游健康节点数、5xx 比例、upstream 响应时间 p95。健康节点突然减少，先查应用和依赖；5xx 升高但节点都健康，查应用日志；p95 升高，查慢查询和外部调用。

云 LB 和自建怎么选

云负载均衡省运维、自带健康检查和弹性，但按量计费、规则受产品限制；自建 Nginx/HAProxy 灵活、便宜，但要自己处理高可用、证书和升级。流量稳定、团队有运维能力，自建更划算；流量波动大、不想半夜起来修 LB，云产品更稳。

最后，负载均衡的配置要纳入版本管理。改 upstream、健康检查、超时都走发布流程，别在凌晨手工改完忘了记录。

健康检查的超时要短于业务超时，否则故障节点会被反复放回来。

上线前用压测确认单节点故障时，剩余节点不会被打满。

配置变更要留记录。

别忘记做故障演练。

常见问题 FAQ

Q1：两台机器一定要负载均衡吗？

不一定。可以用 DNS 轮询或 Keepalived VIP，但健康检查和会话处理仍要自己做。流量上来后还是建议上七层 LB。

Q2：Nginx 和 HAProxy 哪个好？

Web/API 用 Nginx 够；TCP、长连接、高并发用 HAProxy；入口层超高并发再考虑 LVS。

Q3：健康检查查什么？

至少查应用进程和关键依赖（数据库、Redis）。只查端口会漏掉“进程在但服务不可用”的情况。

Q4：会话怎么处理？

优先无状态，session 放 Redis；必须粘性时用 cookie，做好节点故障的降级。

Q5：LB 本身挂了怎么办？

做主备（Keepalived VIP）或用云负载均衡。单台 LB 就是新的单点。

总结

负载均衡不是加一台机器那么简单：选对层级、配好健康检查、处理会话、避免 LB 单点、对齐超时，才算真正可用。先小规模灰度，再逐步放量。