当你的应用在云上运行时，故障转移是云架构设计中必须直面的问题。你可能遇到过：某台实例突然宕机，或者整个可用区网络异常，服务立刻不可用。本文不绕弯子，直接按故障影响范围从单实例、可用区到区域逐层排查，给出对应的架构设计、操作步骤和取舍。
单实例故障：如何快速恢复服务
最基础的故障是单个虚拟机（如 AWS EC2 实例）崩溃。根据 AWS 官方文档，EC2 实例只是虚拟服务器，硬件故障可能导致实例停止。此时，如果只有一台实例，恢复只能靠重新启动或重建，期间服务中断。
要缩短中断时间，至少做到两点：
- 使用弹性 IP 或托管负载均衡，让流量不直接绑定实例 IP，这样实例替换后无需修改 DNS。
- 配置自动恢复：在 AWS 中，可以设置 CloudWatch 告警，当实例因底层硬件故障停止时自动重启实例。
但单实例方案天然有单点，即使自动重启，也存在分钟级中断。要真正实现故障转移，必须引入多实例和负载均衡。
多实例与负载均衡：消除单点
将应用部署到至少两个实例，前端使用负载均衡器（如 ALB）分发流量。负载均衡器需要配置健康检查，定期探测实例的 HTTP 或 TCP 端口。当实例无响应时，负载均衡器自动停止向其转发流量，并将请求路由到健康实例。
关键步骤：
- 创建启动模板或镜像，确保新实例能自动加入负载均衡目标组。
- 设置健康检查的路径和阈值，例如每 5 秒检查一次，连续 3 次失败则标记不健康。
- 结合自动扩缩组（Auto Scaling Group），设置最小实例数为 2，当实例被终止或标记不健康时，自动创建新实例。
这种设计能应对实例级故障，但负载均衡器本身也有单点吗？在 AWS 中，ALB 本身是区域级服务，内部多可用区冗余，通常不是单点。但你的架构如果跨可用区，就能进一步应对机房级故障。
可用区故障：跨可用区部署
AWS 可用区（AZ）是独立的物理数据中心，彼此有独立电源和网络。将实例分布在不同可用区，当某个可用区故障时，流量自动转移到其他可用区。这是云架构设计中实现故障转移的关键层级。
操作要点：
- 在自动扩缩组中指定多个可用区，例如 us-east-1a、us-east-1b。
- 负载均衡器跨可用区启用，确保流量均匀分发。
- 数据层也要跨可用区：例如使用 Amazon RDS 多可用区部署，或使用 EFS 等跨可用区存储。
注意：跨可用区部署会增加数据同步成本，但可用性显著提升。AWS 官方文档强调，使用 EC2 可以灵活配置网络和存储，但跨可用区需要更细致的网络设计，例如子网划分和安全组规则。
区域级故障：多区域容灾
当整个区域（如 us-east-1）发生故障，跨可用区也无济于事。此时需要多区域部署，但成本高、复杂度大。通常用于关键业务或满足监管要求。
实现方式：
- 使用 Route 53 进行 DNS 故障转移，通过健康检查自动切换流量到备用区域。
- 数据层使用跨区域复制，例如 S3 跨区域复制、RDS 跨区域只读副本。
- 定期演练切换流程，确保备用区域能承载全部流量。
多区域架构成本高，需要权衡。成本优化支柱指出，成本优化不是一味省钱，而是让资源充分利用，满足功能需求。因此，多区域应根据业务重要性决定，不是所有系统都需要区域级容灾。
故障转移中的健康检查与自动化
健康检查是故障转移的触发机制。配置不当会导致误判或漏判。常见误区：
- 只检查端口连通性，不检查应用深度。例如数据库连接池耗尽时，TCP 端口仍通，但请求会失败。应检查应用的关键接口，返回 200 才视为健康。
- 健康检查阈值过短，导致瞬时抖动触发频繁切换。
- 忽略启动延迟：新实例启动后需要时间初始化，如果健康检查过早开始，可能误杀实例。应设置较长的预热时间。
自动化也是关键。AWS 的自动扩缩组和负载均衡器能自动替换不健康实例，但前提是正确配置。建议使用基础设施即代码（如 Terraform）管理这些资源，可参考站内文章 多云不迷路：用Terraform/OpenTofu模块化编排。
成本与安全的权衡
故障转移不是免费的。跨可用区、多实例、多区域都会增加成本。成本优化支柱强调，要持续评估资源利用率，避免过度预置。例如，非关键应用可以采用单可用区 + 自动恢复，节省成本。
安全方面，故障转移不能牺牲安全性。安全性支柱指出，要确保在故障转移过程中，安全控制不变。例如：
- 新实例必须应用相同的安全组和 IAM 角色，限制最小权限。
- 数据复制过程中要加密，避免明文传输。
- 健康检查接口不应暴露敏感信息。
此外，跨区域容灾时，需要确保备用区域的安全配置与主区域一致，否则可能出现漏洞。
常见误区与排查思路
误区一：认为故障转移只需负载均衡。实际还需考虑数据一致性、会话保持、缓存失效等问题。
误区二：忽略存储的故障转移。只关注计算实例，但数据库或文件存储仍是单点。例如，使用 EFS 时，要确保挂载参数正确，可参考 云上分布式文件系统NAS/EFS高并发调优。
误区三：从不演练。故障转移流程必须定期演练，否则真正故障时可能发现脚本错误或权限缺失。
排查时，先明确故障影响范围：是单实例、可用区还是区域？然后检查对应的故障转移机制是否触发，日志和监控是关键证据。
参考资料
延伸阅读