促销开始后，商品详情、购物车和结算服务可能同时承受明显高于平日的访问量。负载均衡能把进入的请求分配到多个后端实例，但它不会自动修复应用故障，也不能替代容量规划。做好云平台负载均衡部署实操，应先明确流量路径，再配置转发、探测和切换方案。
第一步：画清请求路径，估算容量
先确认用户请求经过哪些组件：例如域名解析到负载均衡器，再转发至商品服务或结算服务。记录当前后端实例数量、实例可承载的并发范围，以及活动期间预计的访问变化。容量估算应参考历史监控和压测结果；如果没有可靠基线，先对关键接口做压测，不要仅凭页面访问量推断服务器数量。
同时区分静态图片与动态请求。图片可由对象存储或内容分发网络提供，动态请求再进入应用负载均衡器，避免把所有流量都压到应用实例。
第二步：选定负载均衡类型
按协议和转发需求选择
- 四层负载均衡：主要依据 TCP 或 UDP 连接分发，转发路径相对直接，适合需要承载大量连接或非 HTTP 协议的服务；但不适合按 URL 路径、主机名等应用内容做精细路由。
- 七层负载均衡：可识别 HTTP、HTTPS 请求，支持按域名或路径转发，适合将 /products 与 /checkout 等请求分配给不同服务；配置能力更丰富，也需要关注证书、请求头和超时设置。
按实际协议和架构选择一种或组合使用。先核对云平台支持的监听协议、后端类型及可用区域，再确定方案，避免只按产品名称判断功能。
第三步：准备后端与网络规则
创建目标组或后端池，把通过验收的应用实例加入其中，并确认端口、网络和访问规则一致。防火墙或安全组应允许负载均衡器向后端健康检查端口及业务端口发起连接；后端通常不必直接对公网开放。若应用依赖客户端真实地址，检查平台提供的来源地址传递方式，并让应用按对应协议解析，不能默认连接来源就是用户地址。
第四步：配置监听器、证书和转发规则
- 建立 HTTP 或 HTTPS 监听器，填写对外端口及目标组。
- 网站使用 HTTPS 时，绑定有效证书，并核对证书覆盖的域名和有效期；是否在负载均衡器终止 TLS，取决于安全要求和后端架构。
- 按域名、路径或默认规则配置转发。规则应避免重叠造成匹配结果不清，例如把较具体的结算路径规则放在宽泛规则之前。
- 根据应用响应时间设置空闲超时和连接相关参数。数值需结合接口耗时、平台限制与客户端行为验证，不能直接照搬其他环境配置。
第五步：设置健康检查并验证分流
为后端配置健康检查协议、端口和路径。检查路径应返回稳定结果，并能反映服务是否具备接单能力；只检查进程存在，可能让已无法访问数据库的实例仍被视为健康。检查间隔、超时和连续失败次数会影响故障摘除速度与误判概率，可先采用平台支持的常见默认范围，再在预发布环境观察调整。
完成配置后，用测试域名或内部请求检查正常响应、错误响应及后端切换。分别确认一个后端停止服务时，其他健康实例仍能承接请求；同时检查会话粘性需求。若登录或购物车状态保存在单台实例内，优先评估改为共享会话存储；粘性会话可作为兼容手段，但可能导致分配不均。
第六步：小流量切换，监控并保留回滚
正式活动前先让少量流量经过新链路，观察请求成功率、响应时间、后端健康状态、连接数及应用错误日志。达到预先设定的验收条件后，再逐步扩大流量；若错误率上升、健康实例反复摘除或结算请求异常，立即切回原入口或旧转发规则。DNS 切换可能受缓存影响，回滚计划应考虑解析生效时间，不能假设修改后所有用户立即切换。
把这六步落实到变更记录中：保存监听器、转发规则和健康检查配置，明确负责人、观察窗口与回退方式。这样的云平台负载均衡部署实操既适用于促销前上线，也适用于后续扩容和架构调整；关键是用真实请求验证链路，而不是只确认控制台显示“已创建”。
常见问题
负载均衡器能自动扩容后端吗？
不一定。负载均衡器负责分发流量，后端实例数量通常由独立的伸缩配置或人工操作管理，需确认两者是否已联动。
所有后端实例都要放在同一可用区吗？
不必。若业务和平台支持跨可用区部署，可提高单一区域故障时的承载能力；同时要核对跨区流量费用、网络连通性和后端健康检查行为。
什么时候需要会话粘性？
当应用状态暂时保存在单个后端时可能需要，但长期方案通常应让会话状态可被多个实例共享，减少单机故障或流量倾斜的影响。