设计弹性架构
您将学到什么
在本领域中，您将学习易于扩展的松耦合架构设计 (Amazon SQS、Amazon SNS、AWS Step Functions、Amazon EC2 Auto Scaling、Elastic Load Balancing)，以及高可用性和容错性的架构设计 (多 AZ、多区域、备份与灾难恢复策略)。题目以根据需求中的 RTO、RPO 和费用，选出任何部分停止都不会导致整体停止的架构为主。
要点
- 松耦合 - 在处理之间放置 SQS 队列后，即使一方停止或延迟，另一方也不会停止
- 扇出 - 要将 1 个事件送达多个系统时，从 SNS 主题发送到多个 SQS 队列
- 高可用性 - 将 Auto Scaling 组和 ALB 扩展到 2 个以上的 AZ，通过运行状况检查替换异常实例
- 数据库 - RDS 的多 AZ 部署用于自动切换，只读副本用于分散读取 (切换需要提升操作)
- 多区域 - Aurora Global Database、DynamoDB 全局表、S3 跨区域复制
- 灾难恢复的 4 种策略 - 按备份和还原、指示灯、温备用、多站点的顺序，RTO 和 RPO 越来越短，费用越来越高
术语与概念
Amazon SQS 与 Amazon SNS
SQS 是保管消息的队列，处理端按自己的速度取出消息。1 条消息由 1 个处理端接收。SNS 是将收到的消息立即分发给所有已订阅目标的机制。两者结合使用，多个系统就能通过各自的队列接收同 1 个事件。
Auto Scaling 与 Elastic Load Balancing
Amazon EC2 Auto Scaling 会保持设定的实例数量，并根据负载增减实例数量。指定多个 AZ 的子网后，即使 AZ 发生故障，也会在其他 AZ 中继续运行实例。Elastic Load Balancing 只将通信分配给正常的实例，其运行状况检查的结果可用于 Auto Scaling 的实例替换。
→ Auto Scaling 术语表 / → Elastic Load Balancing 术语表 / → Auto Scaling 的策略
RDS 的多 AZ 与只读副本
多 AZ 部署以同步方式将数据复制到其他 AZ 的备用实例，故障时自动切换。只读副本是通过异步复制分担读取负载的机制，也可以创建在其他区域，但切换需要提升操作。根据目的是可用性还是读取性能来选择。
多区域复制
要应对整个区域的故障，需要将数据复制到其他区域。标准的方法是 Aurora 使用 Aurora Global Database，DynamoDB 使用全局表，S3 使用跨区域复制。这些方法的运维负担低于自建的复制机制，因此在考试中也往往是正确答案。
灾难恢复的 4 种策略与 RTO、RPO
恢复时间目标 (RTO) 是从停止到恢复运行的时间，恢复点目标 (RPO) 是可以接受丢失的数据的时间范围。备份和还原费用低但恢复耗时，指示灯只复制数据、服务器在灾难时才启动，温备用始终运行缩小规模的环境，多站点则两边始终都承接处理。
Route 53 的路由策略
故障转移根据运行状况检查的结果在主记录和辅助记录之间切换，加权按设定的比例分配，延迟返回离用户较近的区域，地理位置根据用户所在的位置决定目标。故障时的切换使用故障转移。