负载均衡如何更新代码_多服务器同步部署技巧【操作】

负载均衡器不更新代码，仅转发请求；所谓“更新”实为在后端服务器同步部署新代码，并通过配置确保流量导向新版本节点；rsync+ssh是中小规模常用同步方案。

负载均衡器本身不更新代码，它只转发请求

负载均衡器（如 nginx、HAProxy、AWS ALB）不是代码运行环境，它不存应用代码，也不参与部署逻辑。所谓“负载均衡更新代码”，本质是：在后端所有应用服务器上同步更新代码，再确保负载均衡能正确把流量打到新版本节点上。

常见误解是改了负载均衡配置就等于升级了服务——其实只是切了流量路径，真实业务逻辑还在后端机器里跑着旧代码。

rsync + SSH 是最轻量、可控的多机同步方案

适合中小规模（

• rsync -avz --delete /path/to/app/ user@server1:/path/to/app/ —— 注意末尾斜杠，决定是否同步目录内容
• 用 ssh-agent 或免密密钥批量登录，避免交互式输密码中断流程
• 加 --exclude='node_modules' --exclude='.git' 跳过非必要文件，提速并减少磁盘占用
• 建议先同步到临时目录（如 /tmp/app-new），校验无误后再 mv 替换，降低出错风险

滚动重启时必须检查健康检查路径是否真实反映新代码状态

很多团队配置了 /health 健康检查，但该接口没读取最新代码里的版本号或配置，导致负载均衡认为节点“健康”，实际仍运行旧逻辑。

• 健康检查响应应包含可验证的新特征，比如返回 {"version": "v2.3.1", "build_time": "2024-05-20T14:22"}
• Nginx 的 health_check 或 ALB 的 Target Group Health Check 默认只看 HTTP 状态码，200 就放行——务必确保新代码启动后该接口真返回了新数据
• 若用进程管理器（如 PM2、systemd），确保 restart 后新进程已加载全部模块，而非复用旧内存中的缓存

蓝绿部署比简单同步更安全，但需要额外资源和路由控制能力

真正规避“同步中请求失败”的办法，是让新旧版本并存，用负载均衡器原子切换流量。这要求你有两套等效环境（或容器编排支持标签路由）。

• 在 Kubernetes 中，用 service selector 切换 label，或 Istio 的 VirtualService 权重分流
• 在传统 Nginx 中，需预置两组 upstream，通过 include 加载不同配置文件，用 ln -sf 原子切换符号链接
• 关键点：蓝绿切换前，必须对新集群做端到端冒烟测试（如调用一次下单接口），不能只依赖健康检查

同步脚本写得再稳，也扛不住代码里有个 require('./config.js') 却忘了更新 config 文件——这种细节，只有真实请求流经新代码才能暴露。