TL;DR（30 秒扫完）
- 本质：架构是业务约束下的最优解，不是技术最优；权衡的核心是"代价是否可承受"
- 七大权衡维度：一致性 vs 可用性 / 实时 vs 最终一致 / 性能 vs 成本 / 扩展 vs 简单 / 效率 vs 复杂度 / 维护 vs 灵活 / 可观测 vs 侵入
- 四步方法论：明确业务约束 → 列出候选方案 → 多维度打分对比 → 最坏情况评估
- 设计 + 演进辩证：不是二元对立——设计决定"不能变的"（领域边界/扩展点/抽象层/数据模型/技术底座），演进适应"变化的"（业务迭代/技术升级/性能需求/团队扩张）
- YAGNI：不要过度设计，简单能扛就先简单扛
关键结论
结论 A架构权衡的本质是"没有银弹"——每个方案都有代价，关键是代价是否可承受
结论 B七大权衡维度必须完整，不能只提 CAP
结论 C四步方法论让权衡决策可复用、可复盘
结论 D架构是"设计 + 演进"结合——核心业务必须设计、应用层适合演进
结论 EYAGNI 是反面——不要过度设计，简单能扛就先简单扛
完整讲解（费曼四步）
STEP 1 · 概念
- 架构权衡：在业务约束下对多个候选方案进行多维度评估、做出取舍的过程
- 架构演进：架构随业务变化持续调整的过程，不是"想清楚再做"，而是"够用就行，问题驱动"
STEP 2 · 大白话
类比装修房子：- 设计：承重墙、水电管道——一旦定下来，改造代价极大
- 演进：家具摆放、墙面颜色——随时可以调整
- 过度设计：刚买新房就上智能家居+中央空调+地暖——3 口之家根本用不上
- 零设计：直接入住堆家具——后期承重墙不够用要砸重来
STEP 3 · 底层
3.1 架构权衡三大前提
- 架构是为了应对"当前方案已经不够用"才引入，不是主动炫技
- 架构是业务约束下的最优解，不是技术最优——金融业务和 C 端业务选的方案完全不一样
- 权衡的核心是"代价是否可承受"——每个方案都有代价，关键是业务能不能接受
3.2 架构权衡七大维度
| 维度 | 说明 | 典型选择 |
|---|---|---|
| 一致性 vs 可用性（CAP） | CP 强一致 vs AP 弱一致 | ZK/MySQL 主从同步 vs Redis/Cassandra |
| 实时性 vs 最终一致性 | 同步 RPC vs MQ 异步 | 强一致查询 vs 事件驱动解耦 |
| 性能 vs 成本 | 自研 vs 云服务、垂直优化 vs 水平扩展 | 单机 vs 分布式 |
| 扩展性 vs 简单性 | 微服务拆分 vs 单体、水平扩展 vs 提前分片 | 简单能扛就先简单扛 |
| 开发效率 vs 复杂度 | 微服务治理成本高但利于团队扩张 | 单体 vs 微服务 |
| 可维护性 vs 灵活性 | 模块化强类型 vs 快速原型开发 | 规范编码 vs 快速上线 |
| 可观测性 vs 侵入性 | 链路追踪埋点 vs 业务代码被污染 | APM 埋点 vs 侵入式监控 |
3.3 权衡方法论四步
Step 1 · 明确业务约束：- QPS 峰值、并发、SLA（P99 响应时间）、预算、团队能力、上线时间 Step 2 · 列出候选方案（至少 2-3 个）：
- 如 Redis vs MySQL vs 混合；单机 vs 分布式；同步 vs 异步 Step 3 · 多维度打分对比：
- 性能 / 成本 / 复杂度 / 风险 / 可维护性 / 团队能力 Step 4 · 最坏情况评估：
- 选错了代价是什么？能否灰度回滚？
- 业务变化时权衡结论要重新评估（原来 1000 QPS 用单体，现在 100000 QPS 必须微服务）
- 阿里早期是单体，业务增长后逐步微服务化——不是一开始就上微服务
- 反模式：过度设计（早期微服务+服务网格+分库分表，团队 3 人根本扛不住）
3.4 架构演进的核心
架构是演进的，不是一次定死
3.5 架构设计 vs 演进辩证（Q9 核心）
误区：过度倾向"演进派"完全否定设计价值 → 正确答案是"设计 + 演进"结合 设计决定"不能变的"：- 领域边界：DDD 战略设计（Bounded Context）划清服务/模块边界
- 扩展点：依赖倒置、策略模式、SPI 扩展
- 抽象层：Repository、Gateway、Adapter 等抽象
- 数据模型：核心实体、领域事件、幂等键
- 技术底座：注册中心、消息队列、缓存选型
- 业务迭代：新功能、新场景通过策略模式/插件扩展
- 技术升级：JDK 版本、框架版本、中间件升级
- 性能需求：从同步到异步、从单库到分库分表、从 MySQL 到 ES
- 团队扩张：从单体到微服务的自然演进
- DDD 领域建模：领域边界清晰，跨边界通过事件解耦
- 依赖倒置：核心业务不依赖具体实现
- 绞杀者模式（Strangler Fig Pattern）：微服务迁移时新老共存、逐步替换
- CQRS + Event Sourcing：读写分离、事件溯源
- 架构守护：ArchUnit 单元测试、依赖约束、架构决策记录（ADR）
| 场景 | 侧重点 | 原因 |
|---|---|---|
| 核心金融业务 | 设计派 | 强一致、合规审计、返工代价极高 |
| 支付/交易 | 设计派 | 分布式事务、幂等、对账，前期设计错后期无法挽救 |
| 探索性业务 | 演进派 | 需求不清、快速验证、迭代快 |
| 电商促销 | 演进派 | 需求多变、场景丰富，快速试错 |
| 基础设施 | 设计派 | 技术栈稳定、长期投入 |
| 应用层业务代码 | 演进派 | 需求变化频繁、DDD 演进友好 |
3.6 反面案例
- 过度设计：早期就上微服务+服务网格+分库分表，团队 3 人扛不住（"技术炫技"项目）
- 零设计：早期完全无规划，堆屎山代码，后期重构成本 > 重写成本
STEP 4 · 简化（口诀）
权衡本质：没有银弹、代价可承受、YAGNI 不过度>
七大维度：CAP / 实时-最终 / 性能-成本 / 扩展-简单 / 效率-复杂 / 维护-灵活 / 观测-侵入>
四步方法论：约束条件 → 候选方案 → 多维打分 → 最坏评估>
设计 + 演进：设计决定不能变的（边界/扩展点/抽象/数据/底座），演进适应变化的（迭代/升级/性能/团队）>
架构师核心能力：既能前期设计好关键抽象，又能后期演进好业务变化
延伸追问
举一个你项目中做过的重要架构权衡，说清权衡维度和最终决策。
要点：说清业务背景、候选方案、权衡维度、决策过程、上线效果、后续演进
微服务拆分什么时候合适？什么时候应该用单体？
要点：微服务适用于团队 > 10 人、服务依赖复杂、独立部署/扩容需求强、业务边界清晰；单体的适用场景：早期快速迭代、团队小、依赖简单、QPS 不高
架构守护（Architecture Guard）如何做？如何防止"演进变腐化"？
要点：ArchUnit 单元测试、依赖约束（dependency-cruiser）、代码审查、CODEOWNERS、静态分析、架构决策记录（ADR）
绞杀者模式（Strangler Fig Pattern）具体如何工作？
要点：用新服务逐步替换老服务的功能模块，通过 API Gateway 路由切流，新老共存 → 逐步替换 → 老服务下线
速查表
权衡本质 · 业务约束下最优解 · 代价可承受 · YAGNI 不过度
七大维度 · CAP · 实时-最终 · 性能-成本 · 扩展-简单 · 效率-复杂 · 维护-灵活 · 观测-侵入
四步方法论 · 约束条件 → 候选方案 → 多维打分 → 最坏评估
设计+演进 · 设计决定不能变的（边界/扩展点/抽象/数据/底座）
· 演进适应变化的（迭代/升级/性能/团队）
可演进性 · DDD 领域建模 · 依赖倒置 · 绞杀者模式 · CQRS+ES · 架构守护
反面案例 · 过度设计（3 人扛不住微服务+服务网格）
· 零设计（后期重构 > 重写）Anki 候选卡片
Q: 架构权衡的本质？
A: 业务约束下的最优解，不是技术最优；权衡的核心是"代价是否可承受"
Q: 架构权衡七大维度？
A: 一致性 vs 可用性 CAP / 实时 vs 最终一致 / 性能 vs 成本 / 扩展 vs 简单 / 效率 vs 复杂 / 维护 vs 灵活 / 可观测 vs 侵入
Q: 架构权衡四步方法论？
A: 明确业务约束（QPS/SLA/预算）→ 列出候选方案（≥2 个）→ 多维打分对比 → 最坏情况评估
Q: 架构是设计还是演进？
A: "设计 + 演进"结合，不是二元对立——核心业务必须设计、应用层适合演进
Q: 设计决定"不能变的"五类？
A: 领域边界（DDD）/ 扩展点（DIP/策略/SPI）/ 抽象层（Repository/Gateway）/ 数据模型（核心实体+领域事件）/ 技术底座（注册中心+MQ+缓存）
Q: 可演进性设计五手段？
A: DDD 领域建模 / 依赖倒置 / 绞杀者模式 / CQRS+Event Sourcing / 架构守护（ArchUnit+ADR）
Q: 绞杀者模式如何工作？
A: 用新服务逐步替换老服务的功能模块，通过 API Gateway 路由切流，新老共存 → 逐步替换 → 老服务下线
Q: 微服务什么时候用？什么时候用单体？
A: 微服务适用于团队 > 10 人、依赖复杂、独立部署扩容需求强、业务边界清晰；单体适用于早期快速迭代、团队小、依赖简单、QPS 不高
Q: 架构守护如何做？
A: ArchUnit 单元测试、依赖约束（dependency-cruiser）、代码审查、CODEOWNERS、静态分析、架构决策记录（ADR）
Q: 架构演进的两大反面案例？
A: 过度设计（3 人扛不住微服务+服务网格）/ 零设计（后期堆屎山重构 > 重写）
关联题目
- [ ] 《为什么说做架构其实就是做权衡？》—— 2026-10-08 Round 1 Q8, 评分 ⭐⭐⭐
- [ ] 《架构是设计出来的还是演进出来的？》—— 2026-10-08 Round 1 Q9, 评分 ⭐⭐⭐
- [ ] 《什么样的架构才算是好的架构？》—— 待考
- [ ] 《常见的架构设计原则有哪些？》—— 待考
关联知识
架构是业务约束下最优解；七大权衡维度 + 四步方法论；设计+演进结合不是二元对立
装修房子：承重墙水电（设计不能变）vs 家具墙面（演进可调整）；过度设计=3口家上中央空调，零设计=入住再砸墙
✦ 记 忆 口 诀 ✦
没有银弹 / 代价可承受 / YAGNI 不过度 / 设计+演进结合
关键可视化
暂无可视化
知识关系
⬆️ 前置（Prerequisite）
暂无⚡ 对比（Contrast）
暂无
🎯 概念
📏 规则
⚠️ 误区
🔍 追问
✨ 口诀
共 0 张卡，点击翻面