7.8 KiB
7.8 KiB
第38天：知识体系总复习——串联所有知识点
今天你将学到什么
今天用结构化的方式回顾过去 37 天学到的所有内容，帮你建立完整的 AWS 知识地图。这不是简单的重复，而是从更高的视角看各个服务之间的关系。
AWS 服务全景图
按功能分类
计算
├── EC2（虚拟服务器）
├── Lambda（无服务器函数）
├── ECS / EKS（容器）
└── Fargate（无服务器容器）
存储
├── S3（对象存储）
├── EBS（块存储，EC2 硬盘）
├── EFS（文件存储，共享）
└── S3 Glacier（归档）
数据库
├── RDS / Aurora（关系型）
├── DynamoDB（NoSQL）
└── ElastiCache（缓存）
网络
├── VPC（虚拟网络）
├── ALB / NLB（负载均衡）
├── Route 53（DNS）
├── CloudFront（CDN）
└── VPC Endpoint / PrivateLink
安全
├── IAM（身份与访问）
├── KMS（加密密钥）
├── Secrets Manager（密码管理）
├── WAF / Shield（Web 防护）
├── GuardDuty（威胁检测）
└── CloudTrail（审计日志）
应用集成
├── SQS（消息队列）
├── SNS（通知服务）
├── EventBridge（事件总线）
├── Step Functions（工作流）
└── API Gateway（API 管理）
开发工具
├── CodePipeline（CI/CD 流水线）
├── CodeBuild（构建）
├── CodeDeploy（部署）
└── CloudFormation（基础设施即代码）
监控与管理
├── CloudWatch（监控、日志、告警）
├── AWS Config（配置合规）
├── Trusted Advisor（优化建议）
└── Cost Explorer / Budgets（成本管理）
核心架构模式
模式一：经典 Web 应用
Route 53 → CloudFront → ALB → Auto Scaling (EC2) → RDS Multi-AZ
适合：传统 Web 应用、需要完全控制的场景
模式二：无服务器应用
Route 53 → CloudFront → API Gateway → Lambda → DynamoDB
适合：API 后端、事件驱动、流量不稳定的应用
模式三：容器化微服务
Route 53 → ALB → ECS Fargate (多个服务) → Aurora + DynamoDB + Redis
→ SQS/SNS (异步通信)
适合：中大型应用、需要独立部署和扩展的微服务
模式四：事件驱动架构
事件源 → EventBridge → Lambda / Step Functions → 各种目标服务
适合：松耦合系统、异步处理、复杂业务流程
服务选择决策树
计算服务怎么选
需要运行代码？
├── 运行时间 < 15 分钟？
│ ├── 是 → Lambda
│ └── 否 ↓
├── 需要容器？
│ ├── 是 → 想管服务器吗？
│ │ ├── 不想 → Fargate
│ │ └── 想要控制 → ECS on EC2
│ └── 否 ↓
└── 需要虚拟机 → EC2
数据库怎么选
需要存储数据？
├── 需要复杂查询（JOIN、事务）？
│ ├── 是 → RDS / Aurora
│ └── 否 ↓
├── 键值查询、高频读写？
│ ├── 是 → DynamoDB
│ └── 否 ↓
├── 需要缓存加速？
│ ├── 是 → ElastiCache (Redis)
│ └── 否 ↓
└── 全文搜索？ → OpenSearch
存储怎么选
需要存储文件？
├── 文件需要被多台服务器共享？
│ ├── 是 → EFS
│ └── 否 ↓
├── 通过 HTTP 访问（图片、视频、备份）？
│ ├── 是 → S3
│ └── 否 ↓
├── EC2 的硬盘？
│ └── 是 → EBS
└── 归档（很少访问）？ → S3 Glacier
消息服务怎么选
需要服务间通信？
├── 一条消息只需要一个消费者处理？
│ ├── 是 → SQS
│ └── 否 ↓
├── 一条消息需要多个消费者同时收到？
│ ├── 是 → SNS（配合 SQS 做扇出）
│ └── 否 ↓
└── 需要基于事件内容路由到不同目标？
└── 是 → EventBridge
关键概念速查
高可用相关
| 概念 | 含义 | 实现 |
|---|---|---|
| Multi-AZ | 跨可用区部署 | RDS Multi-AZ、ALB 跨 AZ |
| Auto Scaling | 自动增减实例 | EC2 Auto Scaling Group |
| 负载均衡 | 流量分发 | ALB / NLB |
| 健康检查 | 自动发现故障 | ALB / Route 53 健康检查 |
| 故障转移 | 自动切换到备用 | RDS 故障转移、Route 53 故障转移路由 |
安全相关
| 概念 | 含义 | 实现 |
|---|---|---|
| 最小权限 | 只给必要的权限 | IAM 策略精确控制 |
| 纵深防御 | 多层防护 | WAF + 安全组 + 网络 ACL |
| 加密一切 | 数据加密存储和传输 | KMS + HTTPS |
| 审计追踪 | 记录所有操作 | CloudTrail |
| 密码管理 | 不硬编码密码 | Secrets Manager |
成本相关
| 概念 | 含义 | 实现 |
|---|---|---|
| 按需付费 | 用多少付多少 | 默认定价模式 |
| 预留折扣 | 承诺使用换折扣 | Savings Plans / Reserved Instances |
| Spot 实例 | 用闲置资源省钱 | 可中断的工作负载 |
| 自动扩缩 | 不过度预置 | Auto Scaling |
| 存储分层 | 不同访问频率用不同存储 | S3 生命周期策略 |
常见场景与解决方案
| 场景 | 解决方案 |
|---|---|
| 网站需要全球快速访问 | CloudFront + S3（静态）/ ALB（动态） |
| 应用需要处理突发流量 | Auto Scaling + SQS 削峰 |
| 数据库读取压力大 | ElastiCache 缓存 + Aurora 只读副本 |
| 需要定时执行任务 | EventBridge 定时规则 + Lambda |
| 文件上传后需要处理 | S3 事件通知 → Lambda |
| 多个服务需要协调 | Step Functions 编排 |
| 需要实时通知用户 | SNS + 移动推送 / WebSocket |
| 需要搜索功能 | OpenSearch |
| 需要用户认证 | Cognito |
| 需要 API 管理 | API Gateway |
架构设计原则总结
十大原则
- 为故障设计：假设一切都会坏，设计自动恢复机制
- 解耦组件：用消息队列和事件让服务松耦合
- 弹性伸缩：根据负载自动调整资源
- 安全优先：加密一切、最小权限、纵深防御
- 自动化一切：基础设施即代码、CI/CD、自动化运维
- 使用托管服务：能用托管的就不自建
- 缓存加速：在各层添加缓存减少延迟
- 异步处理：不需要立即结果的操作异步执行
- 监控一切：没有监控就是盲人开车
- 持续优化：定期审查架构和成本
学习路径回顾
第一阶段（第 1-7 天）：基础概念
云计算 → AWS 账户 → IAM → CLI
第二阶段（第 8-19 天）：核心服务
EC2 → Lambda → S3 → 数据库 → VPC → DNS/CDN → 消息服务
第三阶段（第 20-25 天）：安全
IAM 策略 → 加密 → WAF/Shield → CloudTrail → VPC 安全
第四阶段（第 26-32 天）：应用架构
容器 → ECS → CI/CD → Step Functions → API Gateway → 微服务
第五阶段（第 33-36 天）：监控与运维
CloudWatch → 成本管理 → Well-Architected → 故障排查
第六阶段（第 37-40 天）：进阶与认证
认证体系 → 知识总复习 → 实战项目 → 持续学习
今天的小测验
- 如果要设计一个高可用的 Web 应用，至少需要哪些 AWS 服务？
- Lambda 和 EC2 各自适合什么场景？
- SQS、SNS、EventBridge 三者的区别是什么？
- 说出 Well-Architected Framework 的五大支柱。
延伸阅读
明天预告
明天是实战项目日——从零开始设计并规划一个完整的云原生应用，综合运用所有学到的知识。