弹性与高可用架构场景
应对多 AZ 数据库故障转移、突发流量下的自动扩展以及 Route 53 运行状况检查故障转移场景,巩固可靠性概念
弹性与高可用架构场景 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cloud & IT Cert Prep 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。
场景 1:多可用区 Web 应用程序
场景:一家公司运行一个两层 Web 应用程序(ALB → EC2 → RDS),希望消除 AWS Region 内的任何单点故障。解决方案:在至少跨越 2 个可用区的自动扩缩组中部署 EC2 实例,并置于 ALB 后方(ALB 本身即具备多可用区特性)。启用 RDS Multi-AZ 以进行同步备用复制。在 ALB 上配置运行状况检查,自动将流量转离运行状况不佳的实例。采用此架构后,任意单个 AZ 的丢失都会在每一层触发自动故障转移。
# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
--db-instance-identifier prod-mysql \
--db-instance-class db.t3.large \
--engine mysql \
--multi-az \
--master-username admin \
--master-user-password Pass123! \
--allocated-storage 100
# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
--auto-scaling-group-name web-asg \
--min-size 2 --max-size 10 --desired-capacity 3 \
--availability-zones us-east-1a us-east-1b us-east-1c \
--target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc场景 2:负载下的 RDS 读扩展
场景:由于商业智能团队发起了大量读取型分析查询,某电子商务应用程序的 RDS 实例在高峰时段达到 CPU 上限。解决方案:创建 RDS Read Replica,并将 BI 查询指向副本端点。Read Replica 使用异步复制——对于分析场景来说,存在轻微延迟是可以接受的。这样可以将读取流量从主 RDS 实例分流出去,使其专用于写入操作和应用程序读取。对于读取极其密集的工作负载,可以在 RDS 前增加 ElastiCache 层,以缓存经常访问的数据。
# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
--db-instance-identifier prod-mysql-replica \
--source-db-instance-identifier prod-mysql \
--db-instance-class db.t3.large \
--availability-zone us-east-1b
# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)场景 3:CPU 峰值时的自动扩缩
场景:一个无状态 API 运行在 ALB 后方的 EC2 上。工作时间内 CPU 使用率会升至 90%,夜间则降至接近零。该公司希望实例集能够自动扩缩。解决方案:配置一个自动扩缩组,并设置目标跟踪扩缩策略,将平均 CPU 利用率目标设为 60%。当 CPU 超过 60% 时,ASG 会自动添加实例;当 CPU 降至目标值以下时,则移除实例。添加计划扩缩操作,在工作时间开始前预热最小容量,从而避免应对早间流量突增时出现延迟。
# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
--auto-scaling-group-name api-asg \
--policy-name cpu-tracking \
--policy-type TargetTrackingScaling \
--target-tracking-configuration '{
"PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
"TargetValue": 60.0,
"DisableScaleIn": false
}'
# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
--auto-scaling-group-name api-asg \
--scheduled-action-name morning-scale-out \
--recurrence '0 8 * * MON-FRI' \
--min-size 5场景 4:Route 53 故障转移到灾难恢复站点
场景:一家公司在 us-east-1 运行主 Web 应用程序;如果主应用程序运行状况不佳,该公司希望将流量故障转移到 us-west-2 中由 S3 托管的静态维护页面。解决方案:创建一个 Route 53 运行状况检查,监控主 ALB 端点。创建两条带有故障转移路由策略的 Route 53 记录:主记录指向 ALB(与运行状况检查关联),次记录指向 S3 静态站点。如果运行状况检查失败,Route 53 会自动提供次记录的 DNS 响应。
# Create Route 53 health check for primary ALB
aws route53 create-health-check \
--caller-reference $(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "app.example.com",
"Port": 443,
"RequestInterval": 30,
"FailureThreshold": 3
}'
# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails场景 5:使用 SQS 实现解耦和弹性
场景:订单处理后端会向数据库写入数据,但数据库有时会在维护时段不可用,导致订单丢失。解决方案:在前端(负责接收订单)和后端(负责处理订单)之间放置一个 SQS 队列。订单会立即放入队列,让客户即时收到确认。后台工作线程从队列中提取订单,并在数据库可用时进行处理。维护期间,订单会在队列中积累,而不会被丢弃——通过异步解耦提供弹性。
# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
--message-body '{"orderId": "ORD-123", "items": [...]}'
# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
--max-number-of-messages 10
# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)场景 6:Pilot Light 灾难恢复
场景:一家公司需要一种中等预算的灾难恢复解决方案,RPO 为 1 小时,RTO 为 4 小时。解决方案:实施 Pilot Light 灾难恢复策略。使用 RDS Cross-Region Read Replica 将核心数据库复制到灾难恢复 Region。正常运行期间,应用程序服务器不在灾难恢复 Region 中运行——只有最小的“核心”(数据库)保持热状态。发生灾难时,将 Read Replica 提升为独立实例,并使用 CloudFormation 从预先创建的 AMIs 启动应用程序服务器。由于必须启动服务器,RTO 以小时计,而不是以分钟计。
# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
--db-instance-identifier prod-mysql-dr \
--source-db-instance-identifier prod-mysql \
--db-instance-class db.t3.large \
--source-region us-east-1 \
--destination-region us-west-2
# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
--db-instance-identifier prod-mysql-dr \
--region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2场景 7:使用 SQS Dead-Letter Queue 处理失败消息
场景:由于使用者 Lambda 中存在错误,SQS 队列中的消息反复处理失败。这些消息不断重新出现并阻塞队列。解决方案:在主队列上配置一个 Dead-Letter Queue (DLQ)。消息在可配置的次数(maxReceiveCount)内处理失败后,SQS 会自动将其移至 DLQ,而不是无限期重新投递。这样可以解除主队列的阻塞,让运行正常的消息继续处理。在 DLQ 的 ApproximateNumberOfMessagesVisible 指标上设置 CloudWatch 警报,以便在 DLQ 中积累消息时提醒工程团队。
# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
--attributes '{
"RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
}'
# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
--alarm-name orders-dlq-depth \
--metric-name ApproximateNumberOfMessagesVisible \
--namespace AWS/SQS \
--dimensions Name=QueueName,Value=orders-dlq \
--threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
--evaluation-periods 1 --period 60 --statistic Sum场景 8:Aurora Global Database
场景:一家公司在 US 和欧洲开展业务。由于 RDS 位于 us-east-1,欧洲用户读取数据库时延迟较高。解决方案:使用 Amazon Aurora Global Database。主集群位于 us-east-1,在 eu-west-1 增加一个只读的次集群。Aurora 使用存储层复制,将数据复制到次 Region,典型延迟低于 1 秒。欧洲用户从 eu-west-1 的次集群读取数据。在区域性灾难中,可以在 1 分钟内将次集群提升为主集群(这是所有 AWS 多区域数据库选项中最佳的 RTO)。
# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
--global-cluster-identifier prod-global \
--source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora
# Add secondary Region cluster
aws rds create-db-cluster \
--db-cluster-identifier prod-aurora-eu \
--engine aurora-postgresql \
--global-cluster-identifier prod-global \
--region eu-west-1场景 9:带 ALB 和自动扩缩的 ECS 服务
场景:在 ECS Fargate 上运行的容器化 API 服务需要根据 CPU 利用率进行扩缩,并能够承受 AZ 故障。解决方案:将 ECS 服务注册到一个 Application Load Balancer 目标组,使流量分配到正在运行的任务。通过在服务配置中指定多个子网,将任务分布到多个 AZ。配置带有 ECS 服务 CPU 利用率目标跟踪策略的 ECS 服务自动扩缩,自动增加或减少任务数量。如果某个 AZ 发生故障,ECS 会在运行正常的 AZ 中重新启动失败的任务。
# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
--cluster prod-cluster \
--service-name api-service \
--task-definition api-task:5 \
--desired-count 3 \
--launch-type FARGATE \
--network-configuration '{
"awsvpcConfiguration": {
"subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
"securityGroups": ["sg-app"],
"assignPublicIp": "DISABLED"
}
}' \
--load-balancers '[{
"targetGroupArn": "arn:...:targetgroup/api-tg/abc",
"containerName": "api",
"containerPort": 8080
}]'场景 10:使用 Route 53 运行状况检查进行故障转移
场景:一家公司在不同 AZ 中运行两个 EC2 实例,为同一个域名提供服务。该公司希望 Route 53 自动停止向运行状况不佳的实例发送流量。解决方案:使用 Route 53 加权路由,设置相等的权重(50/50),并将一个端点运行状况检查与每条记录关联。当 Route 53 检测到端点运行状况不佳时,会从 DNS 响应中移除该记录,并将 100% 的流量发送到运行正常的端点。当实例恢复且运行状况检查再次通过时,Route 53 会自动重新平衡流量——无需手动修改 DNS。
# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
--hosted-zone-id Z1234567890 \
--change-batch '{
"Changes": [{
"Action": "UPSERT",
"ResourceRecordSet": {
"Name": "app.example.com",
"Type": "A",
"SetIdentifier": "instance-1a",
"Weight": 50,
"HealthCheckId": "hc-abc123",
"TTL": 30,
"ResourceRecords": [{"Value": "10.0.1.10"}]
}
}]
}'场景 11:使用 DynamoDB Global Tables 实现多区域 HA
场景:一个移动游戏应用程序需要让用户能够以低延迟从 us-east-1 和 ap-southeast-1 读取和写入玩家数据。单区域 DynamoDB 表会导致亚洲用户的延迟较高。解决方案:启用 DynamoDB Global Tables。Global Tables 使用多主复制,自动跨指定 Region 复制数据——任何 Region 都可以接受写入。亚洲用户以本地延迟(约 5ms)向 ap-southeast-1 副本写入和读取数据。Global Tables 根据时间戳,使用“最后写入者获胜”策略处理冲突。对于完整的区域性故障,RTO 接近零——流量只需路由到仍在运行的区域。
# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
--global-table-name PlayerData \
--replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'
# Add another Region to an existing Global Table
aws dynamodb update-global-table \
--global-table-name PlayerData \
--replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'快速检查
测试您对本课 AWS Solutions Architect (SAA-C03) 概念的理解。
课程回顾
本课通过以下场景进行了练习:使用多可用区 ASG 和 RDS 实现区域内 HA、使用 Route 53 故障转移路由实现跨区域 DR、使用 SQS DLQ 隔离失败消息而不阻塞队列,以及使用 Aurora Global Database 实现跨区域读扩展和亚分钟级 RTO 故障转移。接下来我们将学习高性能和成本优化的架构场景。
常见问题解答
「弹性与高可用架构场景」课时是免费的吗?
是的 — 「弹性与高可用架构场景」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Cloud & IT Cert Prep 课程的其余内容,请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。
「弹性与高可用架构场景」这节课中我会学到什么?
应对多 AZ 数据库故障转移、突发流量下的自动扩展以及 Route 53 运行状况检查故障转移场景,巩固可靠性概念 你通过在浏览器中直接运行的动手代码来练习 Cloud & IT Cert Prep,全天候 AI 导师会在你学习这节课的过程中回答你的问题。
学习 Cloud & IT Cert Prep 需要有经验吗?
无需任何先前经验。CoddyKit 上的 Cloud & IT Cert Prep 课程适合初学者到高级学习者,你可以从这里开始或从头开始,按照自己的节奏学习。 这是第 2 节课,共 4 节。
「弹性与高可用架构场景」课时需要多长时间?
大多数 CoddyKit 课程大约需要 5–10 分钟。每节课都很精短且互动,所以你能稳步进步,并在网页和应用中从离开的地方继续。
我能在这节 Cloud & IT Cert Prep 课中编写并运行代码吗?
能。每节 Cloud & IT Cert Prep 课都包含内置代码编辑器,你可以在浏览器中直接编写并运行真实代码,并获得即时 AI 反馈 — 无需本地设置。
此课程中的所有课时
- 安全架构场景
- 弹性与高可用架构场景
- 高性能与成本优化场景
- 混合领域全长模拟考试