199 lines
7.1 KiB
Markdown
199 lines
7.1 KiB
Markdown
|
# 第35天：Well-Architected Framework——架构设计的五大支柱
|
|||
|
|
|
|||
|
|
## 今天你将学到什么
|
|||
|
|
|
|||
|
|
今天学习 AWS Well-Architected Framework——这是 AWS 总结的架构设计最佳实践框架。它从五个维度帮你评估和改进你的架构，是 AWS 认证考试的重点内容。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 什么是 Well-Architected Framework
|
|||
|
|
|
|||
|
|
AWS 的解决方案架构师们在帮助成千上万客户设计架构的过程中，总结出了一套通用的最佳实践。这就是 Well-Architected Framework。
|
|||
|
|
|
|||
|
|
**类比**：就像建筑行业有建筑规范一样，云架构也有自己的"规范"。按照这个规范设计的架构，更安全、更可靠、更高效、更省钱。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 六大支柱
|
|||
|
|
|
|||
|
|
### 支柱一：卓越运营（Operational Excellence）
|
|||
|
|
|
|||
|
|
**核心问题**：你的团队能不能高效地运行和改进系统？
|
|||
|
|
|
|||
|
|
**关键实践**：
|
|||
|
|
|
|||
|
|
| 实践 | 说明 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 基础设施即代码 | 用代码管理基础设施，可重复、可审查 | CloudFormation / CDK |
|
|||
|
|
| 小批量变更 | 频繁小改动比偶尔大改动风险低 | CodePipeline / CodeDeploy |
|
|||
|
|
| 预演故障 | 定期模拟故障，验证恢复流程 | Fault Injection Simulator |
|
|||
|
|
| 自动化运维 | 减少手动操作，降低人为错误 | Systems Manager |
|
|||
|
|
| 从失败中学习 | 每次故障后做复盘，改进流程 | - |
|
|||
|
|
|
|||
|
|
**一句话总结**：让运维工作自动化、可重复、持续改进。
|
|||
|
|
|
|||
|
|
### 支柱二：安全性（Security）
|
|||
|
|
|
|||
|
|
**核心问题**：你的数据和系统是否得到了充分保护？
|
|||
|
|
|
|||
|
|
**关键实践**：
|
|||
|
|
|
|||
|
|
| 实践 | 说明 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 身份与访问管理 | 最小权限原则 | IAM |
|
|||
|
|
| 检测控制 | 持续监控异常行为 | GuardDuty / CloudTrail |
|
|||
|
|
| 基础设施保护 | 网络隔离、边界防护 | VPC / WAF / Shield |
|
|||
|
|
| 数据保护 | 加密一切 | KMS / Secrets Manager |
|
|||
|
|
| 事件响应 | 有预案，能快速响应 | Security Hub |
|
|||
|
|
|
|||
|
|
**一句话总结**：假设会被攻击，层层防护，快速响应。
|
|||
|
|
|
|||
|
|
### 支柱三：可靠性（Reliability）
|
|||
|
|
|
|||
|
|
**核心问题**：系统能不能在故障发生时继续正常工作？
|
|||
|
|
|
|||
|
|
**关键实践**：
|
|||
|
|
|
|||
|
|
| 实践 | 说明 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 自动恢复 | 故障自动检测和恢复 | Auto Scaling / ELB |
|
|||
|
|
| 多可用区部署 | 一个机房挂了另一个接管 | Multi-AZ RDS / ALB |
|
|||
|
|
| 水平扩展 | 加机器而不是换更大的机器 | Auto Scaling |
|
|||
|
|
| 备份与恢复 | 定期备份，验证恢复流程 | AWS Backup |
|
|||
|
|
| 限制爆炸半径 | 一个组件故障不影响全局 | 微服务 / 隔离 |
|
|||
|
|
|
|||
|
|
**一句话总结**：假设一切都会坏，设计系统能自动恢复。
|
|||
|
|
|
|||
|
|
### 支柱四：性能效率（Performance Efficiency）
|
|||
|
|
|
|||
|
|
**核心问题**：你是否高效地使用了计算资源？
|
|||
|
|
|
|||
|
|
**关键实践**：
|
|||
|
|
|
|||
|
|
| 实践 | 说明 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 选择合适的资源 | 不同负载用不同类型的资源 | EC2 实例类型选择 |
|
|||
|
|
| 全球化部署 | 让用户就近访问 | CloudFront / Global Accelerator |
|
|||
|
|
| 使用无服务器 | 不需要管理服务器 | Lambda / Fargate |
|
|||
|
|
| 持续实验 | 尝试新技术和新架构 | - |
|
|||
|
|
| 缓存 | 减少重复计算和查询 | ElastiCache / CloudFront |
|
|||
|
|
|
|||
|
|
**一句话总结**：用对的工具做对的事，持续优化性能。
|
|||
|
|
|
|||
|
|
### 支柱五：成本优化（Cost Optimization）
|
|||
|
|
|
|||
|
|
**核心问题**：你是否在用最少的钱达到业务目标？
|
|||
|
|
|
|||
|
|
**关键实践**：
|
|||
|
|
|
|||
|
|
| 实践 | 说明 | AWS 服务 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 了解花费 | 知道钱花在哪里 | Cost Explorer / Budgets |
|
|||
|
|
| 消除浪费 | 关闭闲置资源 | Trusted Advisor |
|
|||
|
|
| 合适的定价模型 | 预留、Spot、按需合理搭配 | Savings Plans |
|
|||
|
|
| 按需扩展 | 不过度预置资源 | Auto Scaling |
|
|||
|
|
| 托管服务 | 用托管服务替代自建 | RDS vs 自建数据库 |
|
|||
|
|
|
|||
|
|
**一句话总结**：花该花的钱，不花冤枉钱。
|
|||
|
|
|
|||
|
|
### 支柱六：可持续性（Sustainability）
|
|||
|
|
|
|||
|
|
**核心问题**：你的架构是否环保节能？
|
|||
|
|
|
|||
|
|
**关键实践**：
|
|||
|
|
|
|||
|
|
| 实践 | 说明 |
|
|||
|
|
|------|------|
|
|||
|
|
| 选择高效区域 | 选择使用可再生能源的 AWS 区域 |
|
|||
|
|
| 最大化利用率 | 减少闲置资源 |
|
|||
|
|
| 使用托管服务 | 共享资源比独占更环保 |
|
|||
|
|
| 减少数据移动 | 数据就近处理 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 用一个例子串联五大支柱
|
|||
|
|
|
|||
|
|
### 场景：一个电商网站的架构评估
|
|||
|
|
|
|||
|
|
| 支柱 | 问题 | 改进建议 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| 卓越运营 | 部署靠手动 SSH | 改用 CodePipeline 自动化部署 |
|
|||
|
|
| 安全性 | 数据库密码写在代码里 | 改用 Secrets Manager |
|
|||
|
|
| 可靠性 | 单台 EC2，挂了就完了 | 改用 Auto Scaling + Multi-AZ |
|
|||
|
|
| 性能效率 | 每次都查数据库 | 加 ElastiCache 缓存热点数据 |
|
|||
|
|
| 成本优化 | 用了太大的实例 | 根据实际负载缩小实例类型 |
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Well-Architected Tool
|
|||
|
|
|
|||
|
|
AWS 提供了一个免费的在线工具，帮你评估自己的架构：
|
|||
|
|
|
|||
|
|
1. 在 AWS 控制台打开 Well-Architected Tool
|
|||
|
|
2. 创建一个"工作负载"
|
|||
|
|
3. 回答一系列问题（每个支柱约 10-15 个问题）
|
|||
|
|
4. 工具会生成报告，指出高风险项和改进建议
|
|||
|
|
|
|||
|
|
**适合**：定期（比如每季度）对你的架构做一次"体检"。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 高可用与灾难恢复
|
|||
|
|
|
|||
|
|
### 高可用（High Availability）
|
|||
|
|
|
|||
|
|
**目标**：系统尽可能少地停机。
|
|||
|
|
|
|||
|
|
**衡量指标**：可用性百分比
|
|||
|
|
|
|||
|
|
| 可用性 | 年停机时间 | 级别 |
|
|||
|
|
|--------|-----------|------|
|
|||
|
|
| 99%（两个 9） | 3.65 天 | 低 |
|
|||
|
|
| 99.9%（三个 9） | 8.76 小时 | 中 |
|
|||
|
|
| 99.99%（四个 9） | 52.6 分钟 | 高 |
|
|||
|
|
| 99.999%（五个 9） | 5.26 分钟 | 极高 |
|
|||
|
|
|
|||
|
|
**实现方式**：
|
|||
|
|
- 多可用区部署（一个 AZ 挂了，另一个接管）
|
|||
|
|
- 负载均衡 + 健康检查
|
|||
|
|
- Auto Scaling 自动替换故障实例
|
|||
|
|
- 数据库 Multi-AZ 自动故障转移
|
|||
|
|
|
|||
|
|
### 灾难恢复（Disaster Recovery）
|
|||
|
|
|
|||
|
|
**目标**：当整个区域（Region）不可用时，能恢复服务。
|
|||
|
|
|
|||
|
|
**四种策略**（从便宜到贵）：
|
|||
|
|
|
|||
|
|
| 策略 | 恢复时间 | 成本 | 说明 |
|
|||
|
|
|------|----------|------|------|
|
|||
|
|
| 备份恢复 | 小时级 | 最低 | 定期备份到另一个区域，灾难时恢复 |
|
|||
|
|
| 灯塔模式 | 十分钟级 | 低 | 另一个区域有最小化的环境，灾难时扩展 |
|
|||
|
|
| 温备 | 分钟级 | 中 | 另一个区域有缩小版的完整环境 |
|
|||
|
|
| 热备（多活） | 秒级 | 最高 | 两个区域同时运行，实时同步 |
|
|||
|
|
|
|||
|
|
**选择建议**：根据业务对停机的容忍度和预算来选择。大多数应用用"灯塔模式"就够了。
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 今天的小测验
|
|||
|
|
|
|||
|
|
1. Well-Architected Framework 的五大支柱分别是什么？
|
|||
|
|
2. "可靠性"支柱的核心思想是什么？
|
|||
|
|
3. 四个 9（99.99%）的可用性意味着一年最多停机多久？
|
|||
|
|
4. 灾难恢复的四种策略各自的恢复时间和成本如何？
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 延伸阅读
|
|||
|
|
|
|||
|
|
- [Well-Architected Framework 白皮书](https://docs.aws.amazon.com/wellarchitected/latest/framework/)
|
|||
|
|
- [Well-Architected Tool](https://aws.amazon.com/well-architected-tool/)
|
|||
|
|
- [AWS 灾难恢复白皮书](https://docs.aws.amazon.com/whitepapers/latest/disaster-recovery-workloads-on-aws/disaster-recovery-workloads-on-aws.html)
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 明天预告
|
|||
|
|
|
|||
|
|
明天是第五阶段的收尾：运维综合实战。我们会模拟一个生产环境的故障排查过程，把监控、日志、告警、恢复等知识串联起来。
|