负载均衡器最佳实践
简洁的操作建议。这些建议总结了适用于大多数服务的最优选择；指南的其余部分详细解释了各项配置参数。
实例设计
以服务为单位创建实例，而非以端口为单位。 单个实例可以承载多个监听器。将服务所有对外暴露的内容——Web、API、管理、监控指标——集中到一个实例，共享 VIP、白名单和安全组成员资格。只有在生命周期确实不同（不同团队、不同合规范围、不同发布节奏）时才进行拆分。
将 IPv4 和 IPv6 作为并行实例维护。 每个实例为单栈。如果您需要双栈，请为每个协议族各创建一个实例，配置相同的监听器和后端，并在 DNS 中同时发布两个地址。
监听器配置
默认调度器：mh（一致性哈希）。 5 元组稳定性通常是您所需要的。来自同一客户端的连接在没有显式持久化超时的情况下也会粘性到同一后端。
后端不相同时切换至 wIc。 混合实例规格、向更新虚拟机系列进行滚动升级，或有意不均等的池——wIc 让权重发挥作用。
仅在必要时启用会话持久化。 持久化增加了需要额外推理的状态。如果您的服务是无状态的，请跳过它。如果它持有每会话的高迁移成本状态，请将持久化与 mh 或 wIc 配合使用——而非 wrr。
将空闲超时设置为与协议静默期相匹配。 HTTP API：数十秒。长连接的 WebSocket 或数据库连接池：数百秒至数分钟。如果客户端在静默期间收到意外断线的报错，空闲超时通常是原因所在。
后端配置
优先使用 后端端口 = 0（与监听器端口相同）。 这是最简单的思维模型，也是大多数服务所期望的。仅在必须时才使用不同的后端端口——例如，服务内部监听 8443 而客户端访问 443。
移除前先排空。 先将权重设为 0，等待活跃连接排空，然后再移除。带有活跃连接的后端被直接移除会导致中途的应用报错。
将池大小控制在上限以内。 大型池会放大健康检查流量，并在成员变更时增加重新分配的规模。
每个地区一台负载均衡器。 后端必须与负载均衡器位于同一地区。对于多地区服务，请为每个地区创建一台负载均衡器，并在 DNS 层面引导客户端。
健康检查
对 HTTP 服务使用 HTTP_GET 指向专用的 /healthz 端点。 TCP_CHECK 仅验证端口能接受连接。正确的 /healthz 验证服务能否真正处理请求——数据库可达、缓存已预热、依赖项正常。
不要将健康检查指向面向用户的路由。 用户路由会拉取数据、查询数据库，且可能有可变的延迟。专用的健康端点应该是轻量、确定性的，并且只在服务确实无法处理请求时才失败。
将 ConnectionTimeout 设置为与真实响应时间相匹配，并留有余量。 对于快速端点，3 秒的超时没问题；但对于偶尔会达到 2 秒尾延迟的服务，则会触发误报。测量您的 p99 健康检查响应时间并添加余量。
在不稳定的环境中提高 RetryCount。 在网络嘈杂或偶有 GC 暂停的环境中，RetryCount = 1 会产生过多的误报剔除。两到三次重试可以平滑瞬时抖动，而不会实质性地延迟真实故障的检测。
默认保持 HealthTreatFailure = 0（强制失败）。 仅为全服务中断比提供可能有问题的响应更糟糕的服务切换为"视所有为健康"——并确保您有告警在该条件触发时通知您，因为从服务的角度来看，症状不会很明显。
运维模式
滚动替换后端服务器。
将新后端添加到池中。等待其变为健康。
将旧后端的权重设为 0（排空）。等待活跃连接排空。
移除旧后端。
每台后端重复上述步骤。无连接中断，无客户端重试。
对单台后端进行维护。
将权重降至 0。确认活跃连接降为零。
下线虚拟机，应用变更，重新上线。
恢复权重。健康检查在一次成功后会重新纳入该后端。
更改调度器。 在算法之间切换会重新洗牌流到后端的映射（mh → mh-with-port 除外，它是精确操作）。如果您的服务对中途连接重置敏感，请在低峰期安排调度器变更。
会话持久化 + 调度器。 如果您在 wrr 或 lc 监听器上启用持久化，在持久化窗口内来自客户端的新流量会发往同一后端。当窗口过期后，新的调度决策可能将下一个流发往不同的后端。请选择一个覆盖您服务预期"会话"生命周期的超时时间，而非任意整数值。
故障排查
将症状与最常见的原因对应起来。颜色显示应首先检查路径的哪个阶段。
最后更新于