SAA-C03 · LESSON 2
设计弹性架构26% · 2 个主题
学习如何设计可扩展、松耦合的架构，以及高可用、容错的架构。
2.1设计可扩展、松耦合的架构
2.1 Design scalable and loosely coupled architectures.
概念
松耦合是在组件之间放置 SQS（队列）、SNS（通知）或 EventBridge（事件），使一方的延迟或故障不会波及另一方。让处理无状态，把会话放在 ElastiCache 或 DynamoDB 中，用 Auto Scaling 水平扩展。无服务器（Lambda、API Gateway、Step Functions）和容器（ECS、EKS、Fargate）也是可选方案。
原理、步骤
- 必要时把同步调用改为经过 SQS 的异步处理
- 把一个事件分发给多个处理时，从 SNS 发往多个 SQS（扇出）
- 让应用无状态，把会话放在外部
- 以 SQS 队列长度等为指标进行 Auto Scaling
- 用 Step Functions 控制多个步骤，并定义失败时的重试
工作中的示例
订单发布到 SNS，扇出到库存、计费、通知各自的 SQS，各处理独立扩展。即使计费处理停止，订单也会留在队列中。
易混淆点、考试注意事项
- SQS 标准队列是至少一次传递（可能重复），FIFO 队列保证顺序且只处理一次
- 可见性超时要长于处理时间
- 持续处理失败的消息转入死信队列
小测验
Q1. 希望用 Auto Scaling 水平扩展 EC2 上的 Web 应用。登录状态保存在服务器内存中，服务器数量变化时用户会被登出。最合适的对策是哪一项？
- 把会话信息保存在 ElastiCache 或 DynamoDB 中，使服务器无状态
- 请用户修改浏览器设置，不保存登录状态
- 禁用 ALB 运行状况检查，固定服务器使 Auto Scaling 不替换它们
- 停用 Auto Scaling，用一台最大的实例运行
查看答案和解析
正确答案：A 把会话信息保存在 ElastiCache 或 DynamoDB 中，使服务器无状态
把会话放在外部数据存储中，任何服务器都能处理同一会话，从而可以自由增减服务器。粘性会话只是临时的变通办法。
Q2. 希望根据 SQS 队列中积压的消息数，增减 ECS 上容器化订单应用的任务数。最合适的方法是哪一项？
- 以 CPU 利用率为目标做目标跟踪来增减 ECS 任务
- 用 ECS 容量提供程序只增减 EC2 实例数
- 基于队列消息数配置 ECS 服务 Auto Scaling
- 用 EventBridge 计划仅在工作日白天增加任务
查看答案和解析
正确答案：C 基于队列消息数配置 ECS 服务 Auto Scaling
ECS 服务 Auto Scaling 可以根据 CloudWatch 指标（如队列深度）增减任务数。【其他选项】CPU 不一定反映队列积压。计划无法跟随实际流量。容量提供程序调整底层实例，不增加任务数。
参考链接
2.2设计高可用、容错的架构
2.2 Design highly available and/or fault-tolerant architectures.
概念
高可用的基础是分散到多个可用区（ALB＋Auto Scaling 组、RDS 多可用区）。针对区域级灾难（灾难恢复），按成本和 RTO、RPO 有四种策略：备份与还原 → 指示灯 → 温备用 → 多站点（双活）。用 Route 53 运行状况检查和故障转移路由进行切换。
原理、步骤
- 确定 RTO（恢复所需时间）和 RPO（可丢失数据的时间范围）
- Web 和应用层由跨多个可用区的 Auto Scaling 组和 ALB 构成
- 数据库使用 RDS 多可用区（同步复制、自动故障转移）
- 根据 RTO、RPO 和成本选择灾难恢复策略，复制到其他区域
- 用 Route 53 故障转移切换到灾难恢复区域，并定期演练
工作中的示例
针对 RTO 1 小时、RPO 15 分钟的要求，采用在其他区域始终运行缩小版环境的温备用和 Aurora 全局数据库。
易混淆点、考试注意事项
- RDS 只读副本主要用于扩展读取（可用性靠多可用区）
- RTO、RPO 越短，灾难恢复成本越高（备份与还原最便宜）
- 指示灯只持续复制核心数据库，服务器在灾难时启动
小测验
Q1. 为提高 Web 应用的可用性，希望消除单点故障。最合适的架构是哪一项？
- 把所有处理集中到一台高性能实例上
- 把 ALB 和 Auto Scaling 组部署在多个可用区，数据库采用多可用区
- 把两台 EC2 放在同一可用区，其中一台保持停止
- 把数据库放在一台 EC2 的实例存储中，每天下班后手动复制到另一台服务器
查看答案和解析
正确答案：B 把 ALB 和 Auto Scaling 组部署在多个可用区，数据库采用多可用区
分散到多个可用区，并使用负载均衡器、自动扩展和多可用区数据库，任何一处故障时服务都能继续。
Q2. 关于 RPO 和 RTO，正确的说明是哪一项？
- RPO 是可接受的数据丢失时间范围，RTO 是从停机到恢复可接受的时间
- RPO 是恢复所需时间，RTO 是可保存的数据量
- RPO 是使用的区域数量，RTO 是使用的可用区数量
- RPO 和 RTO 意思相同，都表示费用上限
查看答案和解析
正确答案：A RPO 是可接受的数据丢失时间范围，RTO 是从停机到恢复可接受的时间
RPO（恢复点目标）是最多可以丢失多久之前的数据，RTO（恢复时间目标）是必须在多长时间内恢复。据此选择灾难恢复方式。
参考链接
课程由本站根据公开信息独立编写，不保证与考试内容一致。产品规格可能变化，请在参考链接中确认最新信息。
使用须知（非官方、原创题目、不保证合格）
- 本站题目是根据官方公开的技能大纲和考试指南独立编写的原创练习题，并非真实考试题目。
- Amazon Web Services、AWS 及相关标志是 Amazon.com, Inc. 或其关联公司的商标。本站与 AWS 无合作关系，也未获得 AWS 的认可或推荐。
- 本内容仅为学习辅助，不保证考试合格。考试内容、形式和前提条件可能随时变更，参加考试前请务必在官方页面确认最新信息。
- 模拟考试的正确率无法换算为官方（换算）分数，也不能预测是否合格。
- 进度仅保存在本浏览器（localStorage）中；使用 Google 登录后才会同步到账号。可在“Cookie 与存储设置”页面（日语）中删除。