负载均衡与反向代理单机到多机的平滑演进一、单机到多机的必然拐点独立产品在最初几个月,一台服务器就够了。Node.js 或 Python 应用,加上数据库(Nginx 反向代理),全跑在一台 2 核 4G 的 VPS 上,月成本几十块钱,用户量不超一万,一切正常。然后某个时刻到来——用户量增长、某个功能变流行、或外部推广带来了流量高峰——服务器的 CPU 跑到 90% 以上,请求开始排队,响应变慢,甚至服务不可用。这个时刻,你会面临一个选择:升级配置(垂直扩展)还是加机器(水平扩展)垂直扩展(升级到 4 核 8G 或更高)是简单的:付更多钱,重启,搞定。但垂直扩展有天花板——单台 VPS 的配置上限有限,且所有应用跑在一台机器上,单点故障风险高。水平扩展(加机器)是更长远的解法:把应用部署到多台服务器上,在前面放一个负载均衡器,把请求分发给多台服务器处理。这样做不仅提高了处理能力,还增加了可用性——一台服务器挂了,其他服务器继续服务。二、Nginx 作为反向代理和负载均衡Nginx 是独立开发者部署中最常用的反向代理服务器。它既可以作为静态文件服务器、SSL 终端,也可以作为负载均衡器。Nginx 负载均衡的基础配置非常简单。在nginx.conf中定义一个 upstream 块,列出所有后端服务器的地址,然后在 server 块的 location 中把请求代理到这个 upstream:upstream app_servers { server 10.0.0.1:3000 weight3; server 10.0.0.2:3000 weight1; server 10.0.0.3:3000 backup; }Nginx 支持多种负载均衡算法:默认是轮询(Round Robin),weight参数按权重分配流量,ip_hash按客户端 IP 粘性分配(同一个用户始终打到同一台服务器,适用于需要 Session 保持的场景),least_conn按当前连接数最少分配。对于独立产品,轮询(默认)就足够了。不需要复杂的算法——你的几台服务器配置一样,负载均衡器能「平均分配」就完成任务了。三、会话保持与共享存储引入多服务器后,第一个需要解决的问题是「会话(Session)」管理。在单机时代,Session 存储在应用内存中,天然可用。在多服务器时代,如果用户的第一个请求打到服务器 A,Session 存在 A 中,第二个请求打到服务器 B,Session 就不见了。解决方式有两种:方式一:粘性会话(Sticky Session)。用 Nginx 的ip_hash或sticky模块,确保同一个用户的所有请求在会话期间始终打到同一台服务器。优点是简单,不需要改应用代码。缺点是一台服务器挂了,刚好粘在这台服务器上的所有用户 Session 都丢失。方式二:共享 Session 存储。将 Session 存储从应用内存搬到 Redis 这类共享存储中。所有服务器读同一个 Redis,Session 不再依赖单台服务器。优点是无状态,任何服务器挂了都不会丢失 Session。缺点是需要引入 Redis 依赖。建议从粘性会话开始。等你的产品确实因为「服务器挂了 Session 丢失」遭受用户体验损失时,再迁移到共享 Session。大多数独立产品,服务器挂了的概率很低,粘性会话已经足够。四、健康检查与故障转移负载均衡器需要知道后端服务器是否健康——如果一台服务器挂了,它应该停止向这台服务器发送流量。Nginx 的健康检查配置为:upstream app_servers { server 10.0.0.1:3000 max_fails3 fail_timeout30s; server 10.0.0.2:3000 max_fails3 fail_timeout30s; }max_fails指定在fail_timeout时间窗口内,允许的最大失败次数。超过这个次数后,Nginx 认为该服务器不可用,在fail_timeout期间不再分配流量给它。健康检查有两种模式:被动检查(passive check)和主动检查(active check)。被动检查:Nginx 在转发真实用户请求时,如果后端返回错误,记录失败。主动检查:Nginx 定期(如每 10 秒)向后端发送一个健康检查请求,根据响应判断服务器是否健康。Nginx 开源版默认只支持被动检查,主动检查需要 Nginx Plus 或第三方模块。对于独立产品,被动检查已经足够。设置max_fails3 fail_timeout30s,这样一台服务器在 30 秒内出现 3 次错误便会被暂时下线,30 秒后自动恢复。五、总结从单机到多机,负载均衡与反向代理的引入,是产品从「能用」到「可靠」的重要一步。对于独立开发者,不需要追求「分布式架构的极致优雅」,而是在架构复杂度可以接受的情况下,获得性能与可用性的提升。起步:用 Nginx 做反向代理,即使是单机,也把 Nginx 放在应用前面——它承担 SSL 终结、静态文件服务、请求限流的工作。增长:当单机扛不住时,加一台服务器,在 Nginx 中配置 upstream 和轮询,水平扩展完成。两个关键决策:会话管理用粘性会话(简单)开始;健康检查用 Nginx 的被动检查。当这两个决策带来的局限性成为实际问题时,再升级到更复杂的方案。架构演进不是一次到位的,而是在每次遇到新瓶颈时,做刚好够用的升级。