节点故障自动切换不是简单地设置一个超时时间，而是要先回答三个问题：谁负责发现故障，什么状态算故障，发现后流量切到哪里。无论使用云负载均衡、硬件设备还是自建代理，配置前都应先梳理节点、入口和依赖关系。

一、先确认切换范围和业务架构

先画出实际请求路径，例如“客户端—域名或入口—流量调度层—业务节点—后端依赖”。确认故障发生在单个节点、整个可用区，还是入口本身。若只有某台节点异常，通常适合做节点级切换；若一组节点共用同一网络、存储或出口，单纯增加节点数量并不能消除共同故障。

还要确认业务是否允许请求在节点之间重新分配。无状态接口通常较容易切换；依赖本地文件、内存会话、临时上传内容或长连接的服务，则需要额外处理。对于登录状态，应优先采用共享会话存储、令牌机制或明确的会话迁移方案，不能假设切换后原节点内存中的状态仍然存在。

二、配置前必须核对的五项信息

1. 节点清单：记录节点地址、端口、版本、所属区域、权重及维护状态，确认备用节点确实已部署并能独立处理请求。
2. 健康检查接口：准备专用检查路径，检查程序是否能接收请求、读取必要配置并访问关键依赖。检查接口不宜执行写入、发短信或创建订单等副作用操作。
3. 故障判定条件：明确连接失败、返回错误状态、响应超时和连续失败次数分别如何处理。一次短暂超时通常不足以触发切换，应结合连续失败和观察窗口判断。
4. 流量调度方式：确认入口采用轮询、权重、最少连接或其他策略。不同策略会影响故障节点被发现的速度，也会影响恢复后的流量回归。
5. 连接与状态：核对长连接、上传任务、队列任务和事务请求的处理方式。已经建立的连接未必会随节点切换自动迁移，必要时应设置连接排空时间。

三、节点故障自动切换的可执行配置步骤

1. 建立基线

在正式启用前，先记录正常状态下的响应时间、错误比例、并发连接数和节点分布。基线应覆盖业务高峰与低峰，否则阈值可能只适合某一时段。不要只看机器是否存活，进程仍在运行并不等于业务可用。

2. 设置分层健康检查

建议至少分为两层：基础检查确认端口和进程可响应，业务检查确认关键功能与必要依赖可用。对依赖较多的服务，可将检查分为“可接流量”和“完全健康”两种状态，避免某个非核心依赖短时异常导致全部流量立即转移。

3. 设定失败、恢复和排空参数

常见做法是使用检查间隔、单次超时、连续失败次数和连续成功次数共同决定状态。参数应结合业务响应时间设置：检查间隔可从数秒开始评估，超时通常略高于正常响应的合理上界，连续失败可设为数次，避免网络瞬时抖动引发误切换。恢复也应要求连续成功，不能只凭一次成功响应立即导入全部流量。

4. 配置备用节点与流量转移

将故障节点标记为不可接收新请求，再把流量分配给健康节点。若采用备用池，需提前确认备用容量；如果故障后剩余容量不足，切换可能只是把错误集中到其他节点。长连接服务应保留排空时间，让已建立的请求自然结束或由客户端重连。

5. 设计回切和人工接管

节点恢复后，建议先以较低比例接收流量，观察错误率和资源使用，再逐步恢复正常权重。对于反复上下线的节点，应设置抑制窗口或维护状态，并保留人工暂停自动回切的开关。这样可以避免修复未完成时反复切换。

四、验证节点故障自动切换是否真的有效

验证不能只关闭一个进程。应分别测试端口不可达、健康接口返回失败、网络延迟升高、依赖服务不可用和节点恢复等场景。每次测试都记录故障发现耗时、流量转移耗时、失败请求数量及恢复后的连接情况。

还要检查监控和告警是否与切换动作一致。例如节点被摘除后，入口日志中的目标分布应发生变化；恢复后，流量不应在短时间内异常集中。测试应安排在可控时段，并提前确认回滚方式，避免演练本身影响真实业务。

五、常见误区

• 只检查进程：进程存在但端口阻塞、证书失效或关键依赖不可用时，仍可能持续接收请求。
• 阈值过于敏感：单次超时就切换，容易造成频繁摘除和恢复。
• 没有备用容量：备用节点数量足够，不代表其计算、连接或存储能力足够。
• 忽略会话和长连接：流量切换成功，不等于正在进行的任务一定能够继续。

常见问题

健康检查多久执行一次合适？

通常从数秒级间隔开始，根据正常响应时间、业务重要性和入口负载调整。间隔越短，发现更快，但检查请求和误判风险也会增加。

备用节点是否必须保持同样配置？

应至少保持兼容的版本、接口、权限、依赖连接和数据结构。若配置或版本不同，切换前必须经过独立验证。

自动切换后要不要自动回切？

不一定。高风险业务可先人工确认；对可自动回切的服务，应采用逐步放量和连续成功检查。

如何判断配置已经生效？

通过受控故障测试，确认故障能被发现、流量能转移、连接能处理、告警能触发，并且节点恢复后可按预期回切或保持隔离。这样，节点故障自动切换才算真正可用。