云架构设计原则是什么
云架构设计原则通常指 Well-Architected 框架里的六个支柱：高可用、弹性、安全、成本、运维、性能。它不是一份验收清单，而是一套评审语言：每个设计决策都要在这些维度上显式说明取舍，比如为了降低延迟做同城双活，就要接受更高的成本与复杂度。评审的价值在于把隐含假设摊到桌面上，让风险在方案阶段暴露，而不是上线后追责。
基本信息
| 适用对象 | 云上新建系统、重大改造、上云迁移方案 |
|---|---|
| 六个支柱 | 高可用、弹性、安全、成本、运维、性能 |
| 评审时机 | 方案设计阶段、上线前、重大变更（数据库迁移、多活改造）之前 |
| 输出物 | 评审记录、待办项与负责人、风险登记表 |
| 常见误区 | 把评审做成签字仪式，问题挂账无人闭环 |
典型使用场景
- 新系统方案评审：上线前逐支柱过一遍，避免单点与权限设计缺陷进入生产
- 上云迁移评审：确认迁移范围、回滚方案与数据一致性验证手段
- 重大变更前评审：数据库版本升级、多活改造这类改动必须有架构层评审
- 故障复盘反查：事故后回看哪一支柱在设计时被忽略，把结论写回清单
- 容量与预算规划：弹性与成本两个支柱一起过，明确扩容上限受什么配额制约
设计评审清单（摘）
设计评审清单（摘）
□ 单点在哪里？故障时自动还是手动切换？
□ 高峰扩容靠什么？扩容上限受什么配额限制？
□ 密钥与凭证放哪？谁有生产权限？
□ 成本大头是什么？有没有优化空间？
□ 监控告警覆盖哪些指标？谁在什么时候会被叫醒？
□ 数据多久备份一次、多久验证一次恢复？六大支柱与要点
| 支柱 | 核心要点 | 常用手段 |
|---|---|---|
| 高可用 | 消除单点，故障自动转移 | 多 AZ、健康检查、自动切换 |
| 弹性 | 按需扩缩，容量与负载匹配 | 弹性伸缩、Serverless、队列削峰 |
| 安全 | 纵深防御，最小权限 | 安全组、IAM、加密、审计 |
| 成本 | 为价值付费，持续优化 | 按量与预留组合、生命周期规则 |
| 运维 | 可观测、可自动化 | 监控告警、IaC、混沌演练 |
| 性能 | 选型与压测数据说话 | 压测、缓存、CDN、读写分离 |
架构评审用清单逐项过，比依赖个人经验可靠；每个『以后再补』都要记录负责人与期限，否则评审就变成走过场。
六个支柱之间天然冲突：可用性越高越贵，弹性越好越复杂。评审的产出应该是明确的取舍与理由，而不是宣称每一项都要做到最好。