HA 与容错：定义与权衡

高可用性（HA）和容错（FT）是两种不同的可靠性目标，架构师经常会将它们混淆。高可用性意味着系统停机时间极少——它可以承受故障，但恢复期间可能会出现短暂中断。容错意味着即使组件发生故障，系统也能通过完全冗余的路径立即接管而持续运行，不发生任何中断。

可用性是按照一年中的正常运行时间百分比来衡量的。99.9% 的可用性99.99%（四个 9）只允许 52.6 分钟的停机时间；99.999%（五个 9）则只允许 5.26 分钟。每增加一个 9，通常都需要更多冗余、自动化和成本。SAA-C03 考试经常要求您判断哪种架构能够满足给定的可用性目标。

高可用架构能够承受一个组件发生故障，并在数秒或数分钟内自动检测故障、切换到健康的替代组件。例如：RDS Multi-AZ 会自动故障转移到另一个 AZ 中的备用实例；Auto Scaling Groups 会替换已终止的实例；Elastic Load Balancers 会将流量转离不健康的目标。系统会出现短暂中断，但无需人工干预即可恢复。

容错架构具有主动冗余：多个相同组件同时处理请求，因此一个组件发生故障时，其他组件可以立即承担其负载，实现零停机。示例包括：由多个 EC2 实例组成的主动-主动 ELB、同时在多个区域提供读写服务的DynamoDB Global Tables，以及具有多个只读副本的Aurora。容错要求始终运行更多资源。

容错比高可用性昂贵得多，因为它要求始终配置完整的冗余容量。一个高可用的 RDS Multi-AZ 实例会使数据库成本翻倍，因为您需要为只在故障时激活的备用实例付费。一个容错的多区域主动-主动 Aurora 部署成本可能高达四倍，但可以消除区域故障期间的所有停机时间。架构师必须在冗余成本与停机造成的业务成本之间进行权衡。

恢复时间目标（RTO）是系统可以接受的最大不可用时间。高可用架构通过自动故障转移，将 RTO 目标设定为较短时间，通常是几分钟。容错架构则将 RTO 目标设定为接近零。在设计 HA 时，您必须选择能够保证在 RTO 预算内完成恢复的服务和配置。例如，RDS Multi-AZ 提供大约 60–120 秒的 RTO，适合许多 HA 要求。

单点故障（SPOF）是指任何一个发生故障就会导致整个系统失效的组件。常见的 SPOF 包括：没有 ASG 的单个 EC2 实例、单 AZ 的 RDS 数据库、单个 NAT 网关或单个可用区。消除 SPOF 是实现 HA 和 FT 的第一步。SAA-C03 考试经常考查您从给定架构图中识别并消除 SPOF 的能力。

对于无状态服务（例如 Web 服务器或 Lambda 函数），实现 HA 或 FT 要简单得多，因为任何实例都可以处理任何请求。有状态服务（数据库、缓存、文件系统）则更加困难：您必须在副本之间同步状态，处理复制延迟，并确保故障转移期间的一致性。AWS 的 EFS（共享文件系统）、ElastiCache with replication groups 和 Aurora（共享存储）等服务，旨在简化有状态服务的 HA 实现。

AWS 上常见的 HA 模式包括：1）多 AZ 负载均衡——将 EC2 实例分布在多个 AZ 中，并置于 ALB 后方。2）只读副本——分担读取流量，并在 DR 中提升为主实例。3）使用 S3 存储无状态资源——S3 天生具备 HA，并拥有 11 个 9 的持久性。4）Global Accelerator——使用静态 Anycast IP，将流量路由到各区域中的健康端点。每种模式都以成本换取特定级别的可用性。

容错模式要求各处都具备主动冗余。关键 FT 模式包括：DynamoDB 天生具备容错能力，会将数据复制到三个 AZ，无需进行故障转移。S3 内置 FT。Aurora Multi-Master（现为 Aurora Serverless v2 多写入器）允许同时向多个 AZ 写入。Kinesis 默认会跨多个 AZ 存储数据。选择内置 FT 的托管服务，是实现零停机架构最具成本效益的途径。

HA 或 FT 的设计效果取决于测试质量。AWS 建议使用AWS Fault Injection Simulator（FIS）运行受控实验，例如终止实例、限制 API 速率或注入网络故障。您应验证故障转移是否确实能在 RTO 内完成、数据丢失是否不超过 RPO，以及告警是否能够正确触发。定期开展故障演练日和混沌工程演练，可以在生产事故发生前发现韧性假设中的缺口。

请测试您对本课 AWS Solutions Architect（SAA-C03）相关概念的理解。

本课您学到了：高可用性通过自动恢复将停机时间降至最低（RTO 为几分钟）；容错通过主动冗余消除停机时间（RTO 为零）；并且每提升一个韧性级别，成本都会显著增加。消除单点故障是这两种方法的基础。接下来我们将探索有状态服务的多 AZ 模式。