7.1 KiB
7.1 KiB
第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 提供了一个免费的在线工具，帮你评估自己的架构：
- 在 AWS 控制台打开 Well-Architected Tool
- 创建一个"工作负载"
- 回答一系列问题（每个支柱约 10-15 个问题）
- 工具会生成报告，指出高风险项和改进建议
适合：定期（比如每季度）对你的架构做一次"体检"。
高可用与灾难恢复
高可用（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）不可用时，能恢复服务。
四种策略（从便宜到贵）：
| 策略 | 恢复时间 | 成本 | 说明 |
|---|---|---|---|
| 备份恢复 | 小时级 | 最低 | 定期备份到另一个区域，灾难时恢复 |
| 灯塔模式 | 十分钟级 | 低 | 另一个区域有最小化的环境，灾难时扩展 |
| 温备 | 分钟级 | 中 | 另一个区域有缩小版的完整环境 |
| 热备（多活） | 秒级 | 最高 | 两个区域同时运行，实时同步 |
选择建议：根据业务对停机的容忍度和预算来选择。大多数应用用"灯塔模式"就够了。
今天的小测验
- Well-Architected Framework 的五大支柱分别是什么？
- "可靠性"支柱的核心思想是什么？
- 四个 9（99.99%）的可用性意味着一年最多停机多久？
- 灾难恢复的四种策略各自的恢复时间和成本如何？
延伸阅读
明天预告
明天是第五阶段的收尾：运维综合实战。我们会模拟一个生产环境的故障排查过程，把监控、日志、告警、恢复等知识串联起来。