设计高性能和弹性计算解决方案
发布: (2026年2月7日 GMT+8 19:19)
8 分钟阅读
原文: Dev.to
Source: Dev.to
⚡ 域 3：设计高性能架构
📘 任务说明 3.2
设计高性能且弹性的计算解决方案 是指选择能够：
- 表现良好
- 自动扩展
- 通过解耦组件避免瓶颈
方法
- 首先选择计算运行时 – EC2 与容器或无服务器。
- 选择扩展模型 – 自动伸缩（Auto Scaling）或基于事件的扩展。
- 调优性能 – 实例系列 / 内存 / 并发 / 批处理。
知识
1️⃣ AWS 计算服务及适用场景
| 服务 | 最适合的场景 |
|---|---|
| Amazon EC2 | • 完全控制操作系统/运行时 • 传统应用、自定义网络/代理、特殊驱动 • 可预测的长期运行服务 |
| AWS Lambda | • 事件驱动任务（API、SQS 处理、EventBridge、文件处理） • 流量波动大或不可预测 • 运维工作最小化 |
| Amazon ECS / Amazon EKS（容器） | • 微服务和长期运行的容器工作负载 • 标准化打包与可预测的弹性伸缩 • 当 Lambda 的限制（超时、运行时、依赖）不适用时 |
| AWS Fargate（无服务器容器） | • 无需管理 EC2 实例的容器 • 常见的“高性能 + 弹性”容器化应用方案 |
| AWS Batch | • 批处理作业、大规模作业队列、计算密集型处理 • 自动为作业提供计算资源（通常是 EC2 / Spot） |
| Amazon EMR | • 大数据处理框架（Spark、Hadoop） • 分布式 ETL / 分析工作负载 Spark/Hadoop → EMR “运行 10,000 个批处理作业” → Batch |
2️⃣ 通过全球基础设施与边缘服务支持的分布式计算概念
- 多可用区（Multi‑AZ）架构 可降低单个可用区故障的影响，并实现横向扩展。
- 边缘服务 可降低终端用户的延迟。
常见的边缘与全球服务
- CloudFront – 缓存与边缘交付。
- Global Accelerator – 为 TCP/UDP 应用提供 Anycast 路由。
3️⃣ 队列与消息（Pub/Sub）概念
| 服务 | 角色 |
|---|---|
| SQS | 解耦生产者 / 消费者；根据队列深度扩展工作者。 |
| SNS | Pub/Sub 扇出。 |
| EventBridge | 事件路由。 |
4️⃣ 可伸缩性能力
- EC2 Auto Scaling – 在 Auto Scaling 组（ASG）中自动扩展 EC2 实例。
- AWS Auto Scaling – 为多种服务提供伸缩（ECS、DynamoDB、Aurora 副本等）。
5️⃣ 无服务器技术与模式
| 服务 | 伸缩机制 |
|---|---|
| Lambda | 按并发数伸缩；可事件驱动且具突发能力。 |
| Fargate | 在无需管理服务器的情况下伸缩容器；伸缩由 ECS/EKS 配置驱动。 |
6️⃣ 容器编排
Amazon ECS（AWS 原生）概念：
- Cluster → Service → Tasks
- Task definition 为蓝图。
Amazon EKS（Kubernetes）概念：
- Cluster → Deployments → Pods
如果不需要 Kubernetes，ECS 通常更简洁。
技能
A️⃣ 将工作负载解耦，使组件能够独立扩展
解耦模式
- SQS 用于 Web 层与工作者之间——缓冲突发、重试、死信队列（DLQ）。
- SNS 向多个消费者进行扇出。
- EventBridge 用于事件驱动的集成。
- Step Functions 在需要协调时用于编排。
前端 随流量扩展；工作者 随队列深度扩展。
B️⃣ 确定用于执行扩展操作的指标和条件
常见扩展信号
- CPU / 内存（EC2/ECS）。
- 请求数 / 目标响应时间（ALB 目标指标）。
- 队列深度 / 最旧消息的年龄（基于 SQS 的工作者扩展）。
- Lambda 并发 / 持续时间 / 限流。
- 自定义 CloudWatch 指标（业务驱动的扩展，例如 “等待的作业”）。
C️⃣ 选择合适的计算选项和特性以满足业务需求
EC2 实例类型
| 系列 | 典型用途 |
|---|---|
| t, m | 通用型 |
| c | 计算密集型 |
| r, x | 内存密集型 |
| i | 存储 / IOPS 密集型 |
| p, g | GPU / 机器学习 / 图形 |
其他 EC2 选项
- Spot 实例——容错工作负载（批处理、无状态、灵活）。
- Graviton（Arm）——性价比优势。
D️⃣ 选择合适的资源类型和规模以满足业务需求
Lambda 内存
- 内存还决定 CPU 分配。
- 当执行时间过慢时提升内存（通常能提升性能）。
- 关注限流和并发限制。
容器内存
- 为任务/Pod 合理配置 CPU 和内存。
- 在可能的情况下，通过增加任务数量而不是单个任务的过度配置来扩展。
Cheat Sheet
| 需求 | 计算 |
|---|---|
| 事件驱动，流量波动大，运维最少 | Lambda |
| 运行容器而无需管理服务器 | ECS on Fargate |
| 必须使用 Kubernetes | EKS |
| 需要操作系统控制 / 传统应用 | EC2 (+ Auto Scaling) |
| 运行大量批处理作业 / 作业队列 | AWS Batch |
| Spark/Hadoop 大数据处理 | EMR |
| 根据积压自动扩展工作节点 | SQS + autoscaled consumers |
| 需要全球性能提升 | CloudFront / Global Accelerator |
回顾检查清单 ✅
- 工作负载已解耦，使组件能够独立扩展（队列/事件）。
- 计算选择符合运行时需求（EC2 与容器 与无服务器）。
- 扩展策略明确（自动伸缩、基于队列、基于事件）。
- 扩展指标选择得当（CPU、请求数、队列深度、并发数）。
- EC2 实例根据工作负载特性选择（计算/内存/存储/GPU）。
- Lambda/容器资源尺寸合适（内存、CPU、任务数）。
AWS 白皮书和官方文档
这些是 Task Statement 3.2 背后的主要 AWS 文档。
您 不需要 记住它们；请使用它们来了解 如何 设计高性能且弹性的计算解决方案。
关键领域
- 计算服务
- 伸缩
- 解耦与消息传递
- 边缘和全球性能
🚀