主机故障切换依赖健康检查，负载均衡切换侧重流量调度

业务高可用架构中主机与负载均衡的故障切换设计，关键不是“发现故障后切到哪里”，而是先判断故障发生在哪一层。主机或虚拟机不可用，通常要通过健康检查、故障隔离和资源接管处理；单个应用实例异常，则由负载均衡停止向它分配新请求。把两种机制分开设计，才能避免小故障触发整机迁移，也避免故障节点继续接收流量。

先分清节点故障与服务故障

主机故障切换处理的是计算节点、操作系统或关键网络路径失效。集群管理组件发现节点失联后，可以将工作负载迁移或在另一台主机上重新启动。使用 Keepalived 与 VRRP 时，常见做法是由备用节点接管虚拟 IP；但这不会自动修复应用本身，也不等于数据已经同步。

负载均衡切换则针对后端服务的可用状态。例如 Nginx 或 HAProxy 可以对后端执行 TCP 连接检查或 HTTP 检查，并在检查失败时暂时摘除该后端。其余健康实例继续承接请求，恢复后再按配置重新加入。它调度的是流量，不负责重启故障主机。

健康检查要检查“能否服务”

只检查主机能否 ping 通，可能把应用已卡死的节点误判为健康；只检查进程存在，也无法确认依赖服务是否正常。建议至少区分存活检查与就绪检查：存活检查判断进程是否需要重启，就绪检查判断实例能否接收业务请求。检查接口应轻量、稳定，避免因短暂依赖抖动导致所有实例同时被摘除。

阈值需要结合业务响应时间和网络状况配置。比如每隔约 2 秒检查一次、连续失败 3 次后摘除，故障判定通常会落在数秒量级，具体还受超时设置、调度间隔和实现方式影响。间隔太短会增加误报，太长则延迟切流。上线前应在测试环境模拟进程退出、端口不可达和节点断网，核对告警、摘除与恢复过程。

把切换设计成可验证的步骤

1. 列出故障边界：分别记录主机宕机、应用进程退出、接口超时、负载均衡器故障及共享存储异常时的预期动作。
2. 设定检查信号：为主机选择节点心跳或集群健康状态，为服务配置 TCP 或 HTTP 就绪检查；不要用一个信号代表所有故障类型。
3. 明确接管责任：指定谁执行实例重启、虚拟 IP 漂移或后端摘除，并确认备用资源有足够容量。
4. 处理双活风险：主机恢复或网络分区时，采用仲裁、隔离或 fencing 等机制，防止两个节点同时认为自己拥有同一资源。
5. 验证回切与告警：检查故障恢复后是否自动重新加入、是否造成连接抖动，并记录切换时间和失败原因。

别让状态与依赖成为切换盲区

切换实例不代表用户会话和业务数据自动迁移。无状态服务可由负载均衡重新分配请求；有会话状态的服务则需评估会话保持、共享会话存储或重新登录的影响。数据库、文件存储等依赖也应单独设计高可用，避免应用节点都正常，却因共同依赖不可用而整体失效。

如果正在规划主机、网络和运维支持，可以把德讯电讯列为沟通与比较的候选对象；采购前应核实其实际可提供的资源、故障支持边界、服务条款及适用地域，不应仅凭品牌名称推定能力。

常见问题

主机切换后，负载均衡还需要健康检查吗？

需要。主机接管只能处理节点层故障，应用启动失败或服务尚未就绪时，健康检查仍应阻止流量进入。

负载均衡摘除后端，已有连接会立即断开吗？

不一定。新请求通常不再分配给已摘除后端，但已有连接如何处理取决于产品配置、协议和超时策略，应通过测试确认。

两种切换能否只部署一种？

若只需在多个应用实例间分流，负载均衡可能足够；若节点本身也需接管或迁移，就还要设计主机层机制。业务高可用架构中主机与负载均衡的故障切换设计，应按故障层级组合两者，并验证切换、隔离和恢复路径。