自有服务器与AWS容器间双向自动故障切换是否可实现

这个需求完全可以实现，整套方案没有技术卡点，核心是把健康探测、流量调度、备节点资源调度三个环节串起来，不用买昂贵的商业监控服务，自行搭建就能稳定运行。

本质是跨自有服务器和AWS环境的主备自动故障切换，你可以根据成本和需求设置主节点优先级：默认优先让自有服务器承接流量（毕竟自有服务器没有额外云资源开销），自有节点故障时自动拉起AWS容器承接服务，AWS侧出问题再切回运行中的自有节点，整个过程不需要人工介入。

• 健康探测模块
  不要用单节点做探测，很容易因为探测点本身的网络波动造成误判。你可以搭建3个独立探测点：一个部署在自有服务器内网、一个部署在AWS同区域的轻量实例上、再配置一个和前两个网络链路完全独立的第三方云主机做中立探测点，三个点同时对当前承接流量的服务做周期检查：每5秒请求一次专门的健康检查接口/healthz，连续3次出现超时、HTTP状态码非200、端口不通的情况，才判定对应节点故障。
  注意不要用ICMP ping作为探测依据，一定要检查应用层状态——很多时候服务器没死机，但Web进程崩了、数据库连不上，这时候ping是通的但服务已经完全不可用。
• 流量调度模块
  不要靠修改DNS切流，DNS缓存生效慢，不同运营商的递归DNS缓存时间不可控，很容易出现切流半小时还有用户访问故障节点的情况。直接在入口层高可用网关做上游切换即可：你可以用两台跨机房的机器部署Nginx+Keepalived做网关，或者用云厂商的标准负载均衡实例（本身SLA基本都在99.95%以上，足够稳定），网关层配置两条上游规则：优先级1是自有服务器，优先级2是AWS上的容器实例，网关自带的健康检查也可以作为辅助探测依据，一旦收到故障信号就自动把流量切到可用节点。
  如果你的应用有用户登录态、购物车这类会话数据，记得把会话存在共享的缓存服务里，不要存在单节点本地，不然切流之后用户会被强制下线。
• 备节点自动管控模块
  为了节省成本，AWS侧的容器不用一直运行，你可以在中立探测节点上跑个简单的调度脚本，逻辑固定即可：
  1. 当三个探测点都判定自有服务器故障时，先调用AWS的API启动对应的容器实例，等容器实例的/healthz接口连续返回正常后，再通知网关把流量切到AWS侧，不要一判定故障就切流，不然容器还没启动完，用户访问会直接报错。
  2. 当探测到自有服务器恢复正常后，不要立刻切回，先持续观察5-10分钟，确认服务稳定、没有持续报错，再慢慢把流量按比例切回自有服务器（比如先切20%，观察10分钟没问题再全量），全量切完稳定运行半小时，再调用AWS API关停容器实例，避免空跑产生不必要的费用。
  3. AWS侧故障的切换逻辑更简单：因为自有服务器平时一直保持运行状态，一旦探测到AWS侧容器故障，网关直接把流量切回自有服务器就行，不需要额外的拉起操作，切换延迟基本在秒级。

• 所有切换规则一定要加冷却时间，避免网络瞬时波动导致两个节点来回切（也就是脑裂问题），故障判定要连续多次失败才触发，切回主节点也要等主节点稳定运行一段时间再操作。
• 每次切换动作都要记录日志，同时配置告警通知，不管是发短信、邮件还是办公软件推送，你得第一时间知道发生了故障切换，及时排查根因，不能切完流就不管了。
• 可以定期做故障演练，比如手动停掉自有服务器的Web服务，验证整个流程能不能正常触发切换、有没有报错，别等真出故障了才发现脚本跑不通、规则配置错误。

内容的提问来源于stack exchange，提问作者Max