独立站负载均衡：多实例部署、健康检查、会话保持与故障转移

独立站负载均衡：多实例部署、健康检查、会话保持与故障转移

一、什么时候需要负载均衡，什么时候是过度设计

负载均衡不是起步就该上的东西。日访问量5000以内，单台2核4G VPS跑Nginx+PHP+MySQL完全够，花几百块买LB只会增加复杂度。真正需要多实例的信号有三个：单台机器CPU长期超过60%、发布时必须停机、你已经因为单机故障丢过询盘。满足其中两个，再上LB。

独立站的典型升级路径是：单VPS跑compose（日访1万以内）→ 拆MySQL到独立机器（日访3万）→ 应用跑2台+云LB（日访5万）→ 应用3到5台+自动扩缩容（日访20万以上）。不要跳步。CDN在LB之前先扛住静态流量，源站压力能降一半，见CDN全球加速。

二、L4还是L7：独立站选哪一层

负载均衡分四层（L4，按TCP/IP转发）和七层（L7，按HTTP路径转发）。L4性能高、配置简单，但只能按端口转发；L7能根据域名、路径、Header做路由，还能做灰度和HTTPS卸载。独立站选L7，因为你需要按路径分流：静态文件走CDN，API走应用，后台走另一组实例。

云厂商的LB选择：AWS用ALB（应用负载均衡器），阿里云用SLB或ALB，腾讯云用CLB。三者功能重叠，价格每月100至200元起。一个判断标准：如果你的需求只是”两台机器轮询”，用最便宜的四层LB；如果需要按路径路由、做灰度、按域名分流，选七层LB。

三、健康检查：怎么配才不会误杀

健康检查是LB的核心。配太松，挂掉的机器还在接流量；配太紧，应用刚启动慢一点就被误摘，导致雪崩。独立站的标准配置是：检查路径/health（只返回200，不查数据库，避免把DB慢传染到LB）、间隔10秒、连续3次失败才摘除、连续2次成功恢复。

/health接口必须轻量。常见错误是让它查一次MySQL连接，结果数据库抖动时所有应用实例都被LB摘光，全站503。正确做法是/health只返回进程存活状态，数据库健康度走独立的/health/db接口，只监控不参与摘除决策。监控告警的阈值见站点监控与告警。

四、会话保持：能不开就不开

很多人第一次上多实例时第一反应是”用户在A机登录，下一个请求打到B机不就掉线了”，于是开了会话保持。这是个短期省事、长期还债的做法。会话保持的问题在于：一旦A机挂了，所有粘在A机上的用户全部掉线，故障转移的意义被抵消一半。

正确做法是把会话从应用内存里拿出来。PHP用Redis存session，Node用JWT无状态token，登录态全部集中到一个共享存储里。这样任何一个应用实例都能处理任何用户的请求，挂掉任意一台不影响在线用户。只有两种情况才开会话保持：老系统改不动、或者第三方插件强依赖本地session。

五、故障转移：怎么验证你的LB真的会切

配完LB不等于故障转移生效。很多团队上线后从没主动杀过一台机器，直到真挂了才发现LB根本没配健康检查，或者安全组没放行。上线前必须做一次主动故障演练：在生产环境（或预发）手动杀掉应用A，观察LB是否在30秒内把流量切到B，用户请求是否无感。

另一个常见坑是两台应用实例在同一台物理机或同一个电源机架上，整机架断电等于两台一起挂。至少跨两个可用区（AZ）部署，或者至少跨两台不同宿主机。备份与恢复演练的完整方法论见网站备份与恢复演练。

场景示例：某B2B站原来单台VPS跑WordPress，一次凌晨宿主机维护断电，站点宕机4小时，期间错过3封欧洲客户询盘。事后加了第二台应用实例挂到云LB，session改存Redis，跨可用区部署。再一次维护窗口，实例B自动接走全部流量，客户和销售都没察觉。多花的每月300元实例费，远低于一次宕机丢的询盘价值。

FAQ 常见问题

写在最后

负载均衡对独立站的价值，一半是扛流量，另一半是扛故障。前者很多人能算清，后者常被忽略——多一台应用实例的成本，换来的是”一台机器挂了用户无感”，这在B2B询盘场景里就是钱。

落地三步：第一步把应用无状态化，session进Redis；第二步起第二台实例，挂到云LB后面，健康检查配好；第三步做一次杀进程演练，确认30秒内流量切走。三步走完，多实例架构才算真正可用。配套的监控告警见站点监控与告警，自动扩缩容的进阶见自动扩缩容。

一句可以记住的话：负载均衡的意义不是分流，是让任何一台机器挂掉时，用户和询盘都察觉不到。