可靠性与性能效率支柱
围绕自动恢复、横向扩展和容量管理进行设计;选择合适的资源类型并持续监控,以维持长期性能
可靠性与性能效率支柱 是 CoddyKit 上的免费 Cloud & IT Cert Prep 课时。 这是第 2 节课,共 4 节。 你可以在下方免费阅读本课时的完整内容 — 然后在浏览器中使用内置代码编辑器和全天候 AI 导师进行实践。 这是 Cloud & IT Cert Prep 学习路径的一部分,你的进度在网页和 CoddyKit 应用中同步。 Cloud & IT Cert Prep 课程共包含 4 节课。
Reliability 支柱概述
架构完善框架的 Reliability 支柱确保工作负载能够在预期时间正确且持续地执行其既定功能。Reliability 包含三个方面:基础(服务配额、网络拓扑)、工作负载架构(分布式系统、避免单点故障)以及变更管理和故障管理(监控、扩展和故障恢复)。目标是构建能够从基础设施或服务中断中自动恢复的系统。
# Reliability design principles:
# 1. Automatically recover from failure
# 2. Test recovery procedures
# 3. Scale horizontally to increase availability
# 4. Stop guessing capacity (use auto scaling)
# 5. Manage change in automation (IaC + CI/CD)
# Key AWS services for reliability:
# - Auto Scaling Groups
# - Elastic Load Balancing
# - Route 53 health checks
# - AWS Backup服务限制与配额
AWS 会对资源实施服务配额(以前称为限制),以保护所有客户。例如,每个区域的默认 EC2 实例限制、VPC 限制以及 Lambda 并发执行数。如果您的工作负载意外达到某项配额,请求将被限流或拒绝,从而导致 Reliability 故障。使用服务配额控制台或 CLI 查看当前限制,并在需要之前申请提高配额。监控使用量指标,在接近限制且影响可用性之前及时发现问题。
# List service quotas for EC2
aws service-quotas list-service-quotas \
--service-code ec2 \
--query 'Quotas[?QuotaName==`Running On-Demand Standard (A, C, D, H, I, M, R, T, Z) instances`]'
# Request quota increase
aws service-quotas request-service-quota-increase \
--service-code ec2 \
--quota-code L-1216C47A \
--desired-value 500故障自动恢复
Reliability 支柱强调无需人工干预的自动恢复。AWS 提供多种自动修复机制:当 EC2 实例未通过底层检查时,EC2 Auto Recovery 会自动在同一硬件上恢复该实例,或将其迁移到运行正常的硬件上。ASG 运行状况检查会终止运行状况不佳的实例并启动替代实例。RDS Multi-AZ 会自动故障转移到备用实例。设计架构时,应确保大多数故障场景都能触发 CloudWatch 告警中定义的自动恢复操作。
# CloudWatch alarm to auto-recover a specific EC2 instance
aws cloudwatch put-metric-alarm \
--alarm-name EC2-auto-recover \
--metrics '[{"Id":"m1","MetricStat":{"Metric":{"Namespace":"AWS/EC2","MetricName":"StatusCheckFailed_System","Dimensions":[{"Name":"InstanceId","Value":"i-12345"}]},"Period":60,"Stat":"Maximum"}}]' \
--comparison-operator GreaterThanThreshold \
--threshold 0 \
--evaluation-periods 2 \
--alarm-actions 'arn:aws:automate:us-east-1:ec2:recover'通过横向扩展提升 Reliability
Reliability 支柱建议通过横向扩展(添加更多较小的实例)而不是纵向扩展(扩展到更大的实例)来提高可靠性。单个大型实例本身就是单点故障。让多个较小的实例位于负载均衡器后方,可以将任何单个实例故障的影响降至最低。AWS Auto Scaling 会自动调整实例集群规模以满足需求,既确保容量充足,又避免在业务清闲时为闲置资源付费。
# Horizontal scaling: 10 t3.medium vs 1 r5.4xlarge
# 10 t3.medium:
# - Failure of 1 = loss of 10% capacity
# - ASG launches replacement automatically
# - 9 instances absorb load during replacement
# 1 r5.4xlarge:
# - Failure = 100% downtime until instance recovered
# - Much higher RTO (new instance launch: 1-3 min)
# Prefer horizontal scaling for stateless tiers通过测试提升 Reliability
Reliability 支柱要求测试恢复流程,而不是想当然地认为流程有效。使用 AWS Fault Injection Simulator (FIS),以受控方式向系统注入故障:终止随机 EC2 实例、限制 API 调用速率以及注入网络延迟。在设置防护措施的前提下于生产环境运行这些实验,以验证监控能够检测故障、自动扩展能够作出响应,并且恢复能在您的 RTO 内完成。未经测试的恢复流程往往无法承受真实事件的压力。
# AWS FIS experiment: terminate random instance
aws fis create-experiment-template \
--description 'Chaos: terminate 1 of 5 instances' \
--targets '{"instanceTargets":{"resourceType":"aws:ec2:instance","selectionMode":"COUNT(1)","resourceTags":{"Env":"production"}}}' \
--actions '{"terminateInstance":{"actionId":"aws:ec2:terminate-instances","targets":{"Instances":"instanceTargets"}}}' \
--stop-conditions '[{"source":"aws:cloudwatch:alarm","value":"arn:aws:cloudwatch::123:alarm:high-error-rate"}]'Performance Efficiency 支柱概述
Performance Efficiency 支柱侧重于高效使用计算资源来满足系统要求,并在需求变化和技术演进时保持这种效率。关键设计原则包括:普及先进技术——使用托管服务(RDS、SageMaker),而不是从头构建。在几分钟内实现全球部署——使用 CloudFormation 部署到多个区域。使用无服务器架构——消除基础设施管理工作。更频繁地进行实验——测试不同的实例类型和配置。
# Performance Efficiency areas:
# Selection: Right compute, storage, database, network
# Review: Continuously evaluate new services
# Monitoring: CloudWatch metrics guide decisions
# Trade-offs: Consistency vs performance, latency vs cost
# Example: choosing between services
# RDS vs DynamoDB vs Aurora vs ElastiCache
# → depends on access patterns, consistency needs, scale选择合适的计算资源
Performance Efficiency 始于为工作负载选择合适的计算类型。EC2 有数十种针对不同使用场景优化的实例系列:c 系列适用于计算密集型工作负载(视频编码、批处理),r 系列适用于内存密集型工作负载(内存数据库、缓存),i 系列适用于存储密集型工作负载(NoSQL、数据仓库),p/g 系列适用于 GPU 工作负载(机器学习训练)。使用错误的实例类型,意味着您可能为无法使用的容量付费,或导致性能下降。
# AWS Compute Optimizer: get right-size recommendations
aws compute-optimizer get-ec2-instance-recommendations \
--instance-arns arn:aws:ec2:us-east-1:123:instance/i-12345
# Output shows:
# - Current instance utilisation (CPU, memory, network)
# - Recommended instance type
# - Estimated monthly savings
# - Performance risk of changing
# Lambda: match memory to actual usage
# Use Lambda Power Tuning tool for memory optimisation通过缓存提升 Performance Efficiency
缓存是一种基础的 Performance Efficiency 技术,可以降低延迟和数据库负载。ElastiCache(Redis/Memcached)将数据库查询结果缓存到内存中,实现毫秒级访问。CloudFront 会在靠近用户的边缘站点缓存 HTTP 响应。API Gateway 缓存通过缓存 API 响应来减少 Lambda 调用。DAX (DynamoDB Accelerator) 在 DynamoDB 前方增加微秒级的内存缓存。请根据瓶颈所在位置——数据库、API 或边缘交付——选择合适的缓存层。
# DAX cluster for DynamoDB microsecond latency
aws dax create-cluster \
--cluster-name my-dax \
--node-type dax.r6g.large \
--replication-factor 3 \
--iam-role-arn arn:aws:iam::123:role/DAXRole \
--subnet-group my-dax-subnet-group
# Application connects to DAX endpoint
# Cache hits: microseconds
# Cache misses: fetches from DynamoDB and caches result选择合适的存储以提升性能
存储选择会显著影响性能。io2 Block Express EBS 可为高性能数据库提供高达 256,000 IOPS。gp3 成本较低,是大多数工作负载的默认选择。实例存储可为临时数据提供最高的 IOPS(NVMe)。S3 可将对象存储扩展到每秒数千个请求。EFS 提供共享的 POSIX 文件访问。请根据 I/O 模式匹配存储:顺序读取适合 st1(Throughput Optimised HDD),而随机 I/O 则需要 SSD 卷。
# EBS volume performance characteristics:
# gp3: 3,000-16,000 IOPS, 125-1,000 MB/s
# io2: 100-64,000 IOPS (up to 256k with Block Express)
# st1: 40-500 MB/s sequential throughput (HDD)
# sc1: 12-250 MB/s (cheapest, cold workloads)
# Create high-performance io2 volume
aws ec2 create-volume \
--availability-zone us-east-1a \
--volume-type io2 \
--size 500 \
--iops 50000性能监控与持续改进
Performance Efficiency 不是一次性决策——随着 AWS 发布新服务,您必须持续监控性能指标并重新评估选择。使用 CloudWatch 控制面板跟踪 p50、p90 和 p99 延迟百分位数,而不只是平均值,因为平均值会掩盖尾部延迟。使用 X-Ray 跟踪记录识别请求链中最慢的部分。设置 CloudWatch 异常检测,自动建立基准并针对异常性能偏差发出告警。定期查看 AWS 公告——较新的实例类型通常能以更低成本提供更好的性能。
# CloudWatch: track API response latency percentiles
aws cloudwatch put-metric-alarm \
--alarm-name 'API-P99-Latency' \
--metric-name TargetResponseTime \
--namespace AWS/ApplicationELB \
--extended-statistic p99 \
--dimensions Name=LoadBalancer,Value=app/my-alb/xxx \
--period 60 \
--evaluation-periods 5 \
--threshold 2.0 \
--comparison-operator GreaterThanThresholdPerformance Efficiency 中的权衡
Performance Efficiency 有时需要与其他支柱进行权衡。添加缓存(ElastiCache)可以提高性能,但会增加运维复杂性(与 Operational Excellence 的权衡)和成本(与 Cost Optimisation 的权衡)。使用 DynamoDB 替代 RDS 可以提高大规模场景下的性能,但需要重新设计数据模型(需要投入 Operational Excellence 工作)。架构完善框架承认这些权衡,并要求您有意识地作出选择并记录原因。在考试题中,请寻找能够以最少运维开销实现性能目标的选项。
# Common performance vs cost trade-offs:
# Cache: +Performance, +Cost, +Complexity
# Read Replicas: +Read performance, +Cost
# SSD vs HDD: +IOPS, +Cost
# Multi-region: -Latency for users, +Cost, +Complexity
# Common performance vs consistency trade-offs:
# DynamoDB eventually consistent reads: +Throughput, -Consistency
# Aurora Reader endpoint: +Read scale, potential replication lag快速检查
测试您对本课程中 AWS Solutions Architect(SAA-C03)概念的理解。
课程回顾
在本课程中,您学习了:Reliability 要求自动恢复、横向扩展和定期故障测试;Performance Efficiency 要求针对每个工作负载选择合适的计算、存储和数据库类型;以及在多个层进行缓存可以降低延迟和数据库负载。这两个支柱都要求持续监控,并愿意重新审视架构决策。接下来我们将探讨 Cost Optimisation 和 Sustainability 支柱。
常见问题解答
「可靠性与性能效率支柱」课时是免费的吗?
是的 — 「可靠性与性能效率支柱」的完整文本可在网页上免费阅读。要进行交互式练习(内置代码编辑器和全天候 AI 导师)并解锁 Cloud & IT Cert Prep 课程的其余内容,请升级到 CoddyKit PRO。 Cloud & IT Cert Prep 课程共包含 4 节课。
「可靠性与性能效率支柱」这节课中我会学到什么?
围绕自动恢复、横向扩展和容量管理进行设计;选择合适的资源类型并持续监控,以维持长期性能 你通过在浏览器中直接运行的动手代码来练习 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 反馈 — 无需本地设置。