负载均衡器不更新代码，仅转发请求；所谓“更新”实为在后端服务器同步部署新代码，并通过配置确保流量导向新版本节点；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 文件——这种细节，只有真实请求流经新代码才能暴露。
