负载均衡器健康检查

健康检查器持续探测监听器池中的每台后端服务器，并更新各后端的健康状态。不健康的后端从调度中移除；已恢复的后端重新纳入。这正是将静态虚拟机列表转化为自愈池的机制。

健康检查按监听器独立运行。出现在两个监听器中的同一台虚拟机会被探测两次——每次使用各自监听器的配置——如果两个监听器探测不同的端口，该虚拟机可能在一个监听器中健康，在另一个中不健康。

健康检查状态机

探测类型

每个监听器可配置四种探测类型：

类型	功能
TCP_CHECK	向后端的检查端口建立 TCP 连接。成功 = 完成握手。探测在握手后立即关闭连接。
HTTP_GET	向配置的路径发送 HTTP GET 请求，并将响应状态码与预期值（如 200）进行比较。成功 = 状态码匹配。http_protocol 可配置，支持 HTTP 和 HTTPS。
MISC_CHECK	运行平台提供的自定义探测。用于 TCP 和 HTTP 探测无法满足需求的服务。请联系支持团队进行配置。
PING_CHECK	向后端发送 ICMP echo 请求。作为服务健康检查几乎没有用处——虚拟机能响应 ping 并不代表其服务正常。尽可能优先使用 TCP_CHECK 或 HTTP_GET。

如何选择探测类型

• TCP_CHECK 是任意 TCP 服务的默认选择。它验证后端能够接受连接，但不验证服务是否真正在处理请求——卡死的后端可能仍能接受连接而不处理它们。

• HTTP_GET 是 HTTP 或 HTTPS 服务的正确选择。指向一个专用的 /healthz 端点，仅在服务能够处理真实流量时返回 200。这能捕获 TCP_CHECK 遗漏的卡死服务情况。

• MISC_CHECK 是自定义逻辑的逃生通道——脚本可以执行任何操作，从特定协议握手到查询下游依赖。

• PING_CHECK 仅在没有其他选择时使用。它检查主机可达性，而非服务可达性。

探测参数

每个监听器的健康检查通过以下参数配置：

参数	默认值	说明
EnableHealthCheck	开启	是否为此监听器运行健康检查器。
CheckPort	0	要探测的端口。0 表示"与后端端口相同"。如需在与服务端口不同的端口上探测健康端点，可设置为非零值。
DelayLoop	10 秒	探测间隔。
ConnectionTimeout	3 秒	等待探测成功的最长时间，超时则计为失败。
RetryCount	1	将健康的后端标记为不健康所需的连续失败次数。
DelayRetry	3 秒	初次失败后重试尝试之间的间隔。
HttpCheckUrl	—	HTTP_GET 使用：请求的路径（如 /healthz）。
HttpStatusCode	200	HTTP_GET 使用：预期的响应状态码。

参数选择建议

• DelayLoop — 更频繁的探测可以更快检测到故障，但会产生更多流量。对于启动时间较长的服务，较短的间隔能让新添加的后端更快开始接收流量（只有成功探测后才符合条件）。对大多数服务而言，10 秒 是合理的选择。

• ConnectionTimeout — 应明显高于后端的正常响应时间。过紧的超时会在负载高峰期产生误报。

• RetryCount — 更高的重试次数使检查器对瞬时故障更宽容，但会延迟真实故障的检测。在嘈杂环境中，两到三次是常见的折中值；对于稳定的后端，一次即可。

• HttpCheckUrl — 指向专用的健康端点，而非面向用户的路由。该端点应检查服务中真正重要的部分（数据库可达、依赖项正常），并仅在能够处理真实流量时返回 200。

---

状态转换

后端经历四种有效状态：

状态	是否接收新流量？	进入条件
健康	是	当前探测成功，且之前的探测也成功。
探测中 / 重试中	是（仍视为健康）	探测失败，但 RetryCount 次重试尚未耗尽。
不健康	否	失败探测 + 重试耗尽——后端从调度中移除。
恢复中	否（仍被排除）	不健康后端，下一次探测待执行。第一次成功即重新纳入。

进入不健康状态。 健康的后端在第一次失败时进入探测中状态。在重试运行期间（由 DelayRetry 分隔）保持此状态。一旦 RetryCount 次连续失败累积，后端被标记为不健康并从调度中移除。进行中的连接继续运行，但不会调度新流量。

恢复中。 不健康的后端继续按正常的 DelayLoop 间隔被探测。一次成功的探测即重新纳入——恢复侧没有"需要多次成功"的阈值。如果您希望更严格的恢复条件，可以提高 DelayLoop，使单次成功代表更长的稳定窗口。

全部失败时的回退

当监听器中的所有后端同时未通过健康检查时，可能出现两种情况：要么所有后端确实都已宕机（不太可能但可能发生），要么健康检查本身出了问题（探测目标错误、中间防火墙规则变更等）。监听器有一个可配置的响应方式：

HealthTreatFailure 值	行为
0（默认——强制失败）	后端保持标记为不健康。不调度新流量；服务向客户端返回错误。
1（视为健康）	即使探测失败，所有后端也被视为健康并参与调度。流量按正常方式分发，同时您进行排查。

如何选择：

• 强制失败对大多数服务更安全——如果所有后端确实都已宕机，向它们发送流量也毫无用处。

• 视为健康适用于全服务中断比提供可能有问题的响应更糟糕的场景——并确保您有告警在该条件触发时通知您，因为从服务的角度来看，症状不会很明显。

此设置仅在所有后端都不健康时生效。如果有任何一台后端健康，流量就会发往健康的后端，与回退值无关。

隔离与恢复行为

• 不健康的后端仍保持其现有连接。 当后端未通过探测时，LB 不会中断活跃流量——它只停止调度新流量。现有连接继续运行，直到正常关闭或空闲超时清理。如果后端确实已宕机，这些连接将在应用层失败。

• 已恢复的后端在下一次调度决策时开始接收新流量。 调度器在每个新流上重新评估；一旦后端健康，它就开始被选中。

• 权重和持久化与健康状态存在交互。 在会话持久化开启时，已恢复的后端可以接收新的可粘性流量，但现有指向其他后端的粘性条目不会移动。使用 wIc 时，以权重 3 恢复的后端将从零活跃流量开始，可能短暂吸引不成比例的份额，直到计数重新平衡。

禁用健康检查

您可以完全禁用监听器的健康检查（EnableHealthCheck = 0）。禁用后，无论可达性如何，每台后端始终被视为符合调度条件。

仅在有其他机制管理后端成员资格时才禁用——例如，根据自身存活信号添加和移除后端的控制系统。否则，宕机的后端将持续接收流量，直到您察觉为止。