负载均衡关键在“接得稳、分得准、切得快、扩得顺”，80%问题源于配置逻辑错位、健康检查失灵、会话保持遗漏或协议层级误选；需先明确接入目标——如扛突发流量看qps与弹性伸缩，微服务路由须选七层alb，低延迟场景优先四层nlb，老旧系统需评估兼容性；选型应匹配架构阶段：中小业务用alb开箱即用，中间件层选nlb，混合云或强合规场景宜用haproxy+keepalived，成熟nginx集群可升级nginx plus；配置每步均有因果链，如alb后端无流量常因安全组未放行健康检查ip段，https报502多因监听协议与后端协议不匹配，登录态丢失需合理启用会话保持；上线后必须验证单点故障切换时效、各节点连接数均衡性及ssl链路完整性。

负载均衡不是加一台设备或配一个IP就完事，关键在“接得稳、分得准、切得快、扩得顺”。真正落地时，80%的问题出在配置逻辑错位、健康检查失灵、会话保持遗漏或协议层级误选——而不是不会敲命令。

明确接入目标：先想清楚你要解决什么问题

别一上来就部署ALB或Nginx。先确认核心诉求：

• 要扛住突发流量（比如秒杀、直播）？重点看QPS承载能力与弹性伸缩联动
• 后端是多个微服务实例，需要按路径或域名路由？必须用七层（L7）负载均衡
• 业务对延迟极度敏感（如实时音视频、高频交易）？优先四层（L4）NLB或LVS
• 已有老旧系统不支持HTTP重定向或Header透传？需评估兼容性，可能绕过ALB改用CLB或自建HAProxy

选型不是比参数，而是匹配架构阶段

初创团队和金融核心系统，选型逻辑完全不同：

• 中小业务/API服务：阿里云应用型负载均衡（ALB）开箱即用，支持HTTPS卸载、WAF联动、自动灰度发布，控制台5分钟可完成基础配置
• 高吞吐中间件层（如Redis代理、Kafka网关）：网络型负载均衡（NLB）更合适，百万级并发+微秒级延迟，但不解析HTTP内容
• 混合云或强合规场景（如等保三级）：自建HAProxy + Keepalived组合，可控性强，审计日志完整，适合对接内部CMDB和监控体系
• 已有Nginx集群且运维成熟：无需替换，升级至Nginx Plus可获得商业级健康检查、动态上游、实时指标，成本低于云SLB长期使用

配置不是填空，每一步都有因果链

以ALB为例，常见配置陷阱及应对：

• 服务器组加了机器却没流量：检查后端ECS安全组是否放行ALB健康检查源IP段（非客户端IP），默认是100.64.0.0/10
• HTTPS证书上传成功但访问报502：确认监听协议选的是“HTTPS”而非“HTTP”，且后端协议匹配（如ALB解密后转发HTTP到后端，后端不能只监听HTTPS）
• 用户登录态丢失：开启“会话保持”，ALB支持基于Cookie或源IP两种模式；若用JWT或Token鉴权，建议关闭会话保持，靠后端统一Redis存储session
• 某台ECS频繁被踢出：不是服务器真宕机，而是健康检查路径（如/health）返回非2xx状态码，或超时时间设太短（默认5秒），建议设为10秒+3次失败才剔除

上线后必须验证的三件事

配置完成不等于可用。上线后立即做这三步验证：

• 手动模拟单点故障：停掉一台后端ECS，观察ALB控制台是否30秒内标记为“异常”，新请求是否100%落到其余节点（用curl -I反复请求验证）
• 检查真实流量路径：在后端服务器上执行netstat -an | grep :8080 | wc -l，对比各节点连接数是否接近（轮询模式下偏差应
• 验证SSL链路完整性：用openssl s_client -connect yourdomain.com:443 -servername yourdomain.com确认证书由ALB签发，且SNI正常，避免客户端降级到HTTP