设计高可用和/或容错架构
发布: (2026年2月5日 GMT+8 16:04)
8 分钟阅读
原文: Dev.to
Source: Dev.to
（请提供您希望翻译的正文内容，我将为您翻译成简体中文并保留原有的格式。）
考试指南 – 解决方案架构师 – 助理
领域 2：设计安全架构
任务说明 2.2 – 设计高可用和容错架构
高可用性 (HA) – 系统在组件故障时仍保持运行。
容错性 (FT) – 系统在无中断的情况下继续运行。
典型的 HA 模式 – 多可用区 + 负载均衡 + 托管服务 + 无单点故障。
1️⃣ AWS 全球基础设施
| 组件 | 描述 |
|---|---|
| 可用区 (AZs) | 区域内部的隔离故障域 within a Region。 |
| 区域 | 不同的地理区域 – 用于灾难恢复 (DR)。 |
| Amazon Route 53 | 基于 DNS 的路由和健康检查；常用于区域故障转移。 |
- “必须能够在 AZ 故障时仍然可用” → 多可用区设计。
- “必须能够在区域中断时仍然可用” → 多区域灾难恢复 + Route 53 故障转移。
2️⃣ AWS 托管服务 – 合适的使用场景
- 托管服务通常内置 HA、弹性伸缩，并降低运营风险。
- 即使某项服务（例如 Comprehend、Polly）本身不是 HA 主题，考试仍期望在需要更高可靠性且减少自定义工作时优先使用托管服务。
3️⃣ 基础网络概念
| 元素 | HA/FT 考虑因素 |
|---|---|
| 路由表 | 正确的路由至关重要。 |
| 公共子网 | 路由到互联网网关 (IGW)。 |
| 私有子网 | 出站流量通过 NAT 网关。 |
| 多可用区设计 | 每个 AZ 需要独立的子网和路由。 |
4️⃣ 灾难恢复 (DR) 策略
| 灾难恢复策略 | 定义 | 典型 RTO / RPO | 成本 | |
Source: …
dby Region/account 必须拥有足够的配额才能扩展。
- 操作：
- 检查并调整 Service Quotas。
- 设计时加入限流、重试、退避和缓冲机制。
1️⃣1️⃣ 存储选项与特性 – 持久性与复制
| 服务 | 持久性 / 复制 |
|---|---|
| Amazon S3 | 高持久性，区域级；支持版本控制和复制。 |
| Amazon EBS | 在同一可用区内复制；快照可存储在 S3 中以提升持久性。 |
| Amazon EFS | 区域级，多可用区跨 Region 内部复制。 |
1️⃣2️⃣ 工作负载可视化 – AWS X‑Ray
- CloudWatch – 用于健康和扩展的指标与告警。
- AWS X‑Ray – 跟踪分布式请求，定位瓶颈。
可视化对于高可用性至关重要：它帮助你 快速检测 并 诊断 故障。
A️⃣ 确定自动化策略以确保基础设施完整性
查找：
- 基础设施即代码 – CloudFormation、CDK、Terraform。
- 自动化部署 – 蓝绿、滚动。
- 自动伸缩 + 健康检查。
- 自动恢复操作 – 替换不健康的实例/任务。
常见架构选择
- 多可用区（Multi‑AZ）：ALB + Auto Scaling + 多可用区数据库（RDS Multi‑AZ）。
- 多区域（Multi‑Region）：Route 53 + 复制的数据 + 备用/活动环境。
“可用区故障不得导致停机” → 所有资源均采用多可用区。
关键运营指标
- 可用性 / 错误率（5xx）。
- 延迟 p95 / p99。
- 队列深度 / 时长（SQS）。
- CPU / 内存 / 连接数（计算与数据库）。
- RPO / RTO 合规信号（备份成功、复制延迟）。
D️⃣ 实施设计以缓解单点故障
- 多可用区部署。
- 冗余 NAT 网关 – 每个可用区一个（最佳实践）。
- 多可用区数据库。
- 避免单实例“宠物”服务器。
E️⃣ 确保数据的持久性和可用性 – 备份
- 自动备份（RDS）。
- 快照（EBS、RDS）。
- S3 版本控制 + 复制（根据需要）。
- AWS Backup 策略，用于集中备份。
根据 RTO/RPO 选择备份策略：
| 策略 | 成本 | RTO / RPO |
|---|---|---|
| 备份/恢复 | 低 | 慢 / 较高 |
| 预备灯塔 (Pilot Light) | 低‑中 | 中等 |
| 温备 (Warm Standby) | 中‑高 | 更快 / 低 |
| 主动‑主动 (Active‑Active) | 最高 | 最快 / 最低 |
G️⃣ 提升传统应用的可靠性
当无法更改应用代码时，使用基础设施模式：
- 将应用放在 ALB 后面。
- 使用 Auto Scaling groups 自动替换故障实例。
- 部署 RDS Proxy 以稳定数据库连接。
- 添加 caching（例如 ElastiCache）来减轻后端负载。
- 配置 DNS failover（Route 53）实现区域弹性。
灾难恢复 (DR) – 管理服务以降低故障模式
- 应用层：ALB、Auto Scaling、Route 53
- 数据层：RDS Multi‑AZ、DynamoDB（托管 HA）
- 消息：SQS / SNS 用于解耦峰值和故障
- 边缘：CloudFront 用于边缘缓存和源站保护
要求与指南
| 场景 | 推荐的 AWS 服务 |
|---|---|
| 应对实例故障 | Auto Scaling + health checks + ALB |
| 应对可用区故障 | Multi‑AZ for each tier (ALB targets across AZs, Multi‑AZ DB) |
| 应对区域故障 | DR strategy + Route 53 failover + replicated data |
| 严格的 RTO / RPO | Warm standby or active‑active |
| Lambda 对 RDS 连接数造成压力 | RDS Proxy |
| 需要查看微服务间的瓶颈 | X‑Ray (plus CloudWatch) |
| 故障切换期间备用必须扩展 | Plan Service Quotas + scaling policies |
检查清单
- 每个关键层级在多个可用区（AZ）部署
- 通过 ALB/NLB 分发流量，自动替换不健康的目标
- 数据库使用 HA 功能（例如 RDS Multi‑AZ 或托管的 HA 服务）
- 灾难恢复策略符合业务 RTO/RPO（备份/恢复 vs pilot‑light vs warm standby vs active‑active）
- 区域故障转移使用 Route 53 健康检查/路由（如有需要）
- 处理数据持久性（备份、快照、复制）
- 在故障转移/备用扩展时考虑配额和限流
- 具备监控和追踪（CloudWatch + X‑Ray）
主要 AWS 文档（供参考）
- Route 53 – DNS 路由与健康检查
- Disaster Recovery on AWS – 设计模式与最佳实践
- VPC Route Tables – 网络流量路径
- Application Load Balancer – 第七层负载均衡
- Auto Scaling (EC2) – 动态实例伸缩
- RDS Multi‑AZ – 高可用性数据库部署
- RDS Proxy – 为无服务器工作负载提供连接池
- Service Quotas – 限额与伸缩考虑
- S3 Replication – 跨区域对象持久性
- EBS Snapshots – 时间点卷备份
- EFS Overview – 跨可用区共享文件存储
- AWS X‑Ray – 分布式追踪
- CloudWatch – 指标、日志、警报
- Amazon Comprehend – 自然语言处理（可选）
- Amazon Polly – 文本转语音（可选）