为什么说做架构其实就是做权衡？

---

面试记录 2026-10-08

题目：为什么说做架构其实就是做权衡？

难度：high

标签：arch/design, architecture/design, difficulty/high

评分：⭐⭐⭐☆☆（3/5）

我的回答

架构做权衡，这个事本身就是一个很现实的问题。做架构本身是因为当前的资源不足，才要去考虑架构的。资源完全充足的情况下，可以完全大力飞砖。单台机器性能足够高，就可以选择单体去承接所有的流量。单个机器的单个的那个服务的能力足够强，这个数据库可能能承载几十万的、几百万的并发数据库，它就不需要做分布式数据库，不需要做分库分表。另外就是架构就是为了处理单台处理不了，或者是说你本身这个结构。他需要去更用更少的资源去做更多的事，才做这个架构这件事。而在执行架构的设计过程中，会考虑到方方面面的事，比如安全性、一致性、性能，然后可靠性，各种东西的权衡。比如像 CAP 原理，一致性、可用性、分区容错性，在分布式里边，这几个，这三个东西就你都无法同时拿到。你只能去权衡取舍，是考虑要强一致还是高可用，这都是需要通过架构去取舍。而这个取舍的过程其实就是架构设计。也是根据自己的业务情况去不同的选择。能接受高可用，能接受一定的不一致，就可以选，最好选高可用。接受不了不一致，就选择强一致，放弃一些高可用。权衡，一方面是对成本的权衡，一方面是对性能的权衡。取舍，各方面都会有这种取舍。

点评

优点：抓准"架构是为了应对资源不足"的本质；用 CAP 举例说明取舍；强调业务导向（能接受不一致就选 AP）。

不足：维度不够系统（缺开发效率 vs 复杂度、实时性 vs 一致性、扩展性 vs 简单性）；缺方法论（如何决策）；缺权衡的边界（YAGNI）；缺权衡的动态性（架构会演进）；缺具体案例深度。

补充：架构权衡七大维度（CAP/实时 vs 最终/性能 vs 成本/扩展性 vs 简单性/开发效率 vs 复杂度/可维护 vs 灵活/可观测 vs 侵入）；四步方法论（约束条件→候选方案→多维打分→最坏情况评估）；架构演进核心是"够用就行，问题驱动"。

完整讲解

第一部分：知识重点剖析

核心考点定位：考察对架构权衡的系统性理解——不是知道要权衡，而是能系统性地列出权衡维度、方法论、边界和案例。

知识点拆解：

1. 架构权衡的本质：

• 架构是业务约束下的最优解，不是"技术最优"或"理论最优"；
• 架构是为了应对"当前方案已经不够用"才引入的，不是主动炫技；
• YAGNI 原则（You Aren't Gonna Need It）：不要过度设计，简单能扛就先简单扛；
• 权衡的核心是"没有银弹"——每个方案都有代价，关键是代价是否可承受。

1. 架构权衡七大维度：
2. 一致性 vs 可用性（CAP）：CP 强一致（ZK、MySQL 主从同步）、AP 弱一致（Redis、Cassandra）
3. 实时性 vs 最终一致性：同步 RPC（实时强一致）vs MQ 异步（解耦但最终一致）
4. 性能 vs 成本：自研 vs 云服务、垂直优化 vs 水平扩展、单机优化 vs 分布式
5. 扩展性 vs 简单性：微服务拆分 vs 单体、水平扩展 vs 提前分片
6. 开发效率 vs 复杂度：微服务治理（注册中心、熔断、链路追踪）成本高，但利于团队扩张
7. 可维护性 vs 灵活性：模块化强类型（可维护）vs 快速原型开发（灵活）
8. 可观测性 vs 侵入性：链路追踪埋点（可观测）vs 业务代码被污染（侵入）
9. 权衡方法论四步：

• 第一步：明确业务约束——QPS 峰值、并发、SLA（P99 响应时间）、预算、团队能力、上线时间
• 第二步：列出候选方案——至少 2-3 个（如 Redis vs MySQL vs 混合；单机 vs 分布式）
• 第三步：多维度打分对比——性能/成本/复杂度/风险/可维护性/团队能力
• 第四步：最坏情况评估——选错了代价是什么？能否灰度回滚？

1. 架构演进的动态性：

• 架构是演进的，不是一次定死；
• 业务变化时权衡结论要重新评估（比如原来 1000 QPS 用单体，现在 100000 QPS 必须微服务）；
• 阿里早期是单体，业务增长后逐步微服务化，不是一开始就上微服务——这是"够用就行"的典型；
• 反模式：过度设计（早期就上微服务+分库分表+服务网格，团队 3 个人根本扛不住）。

按「本质认知 → 七大维度 → 四步方法论 → 演进动态性」递进。

第二部分：考察方向与延伸递进

考察方向：

• 深度：能否系统列出权衡维度、说出四步方法论
• 广度：能否举出 2-3 个具体权衡案例（如 Redis 缓存 vs DB、MQ 异步 vs RPC 同步、微服务 vs 单体）
• 应用：能否结合自己项目说清某个权衡的决策过程

延伸递进面试题：

1. 举一个你项目中做过的重要架构权衡，说清权衡维度和最终决策。

• 解答要点：说清业务背景、候选方案、权衡维度、决策过程、上线效果、后续演进

1. 微服务拆分什么时候合适？什么时候应该用单体？

• 解答要点：微服务适用于团队规模 > 10 人、服务间依赖复杂、独立部署/扩容需求强、业务领域边界清晰；单体的适用场景：早期快速迭代、团队小、依赖简单、QPS 不高

1. 如果业务突然 100 倍增长，你原来的架构决策还成立吗？

• 解答要点：架构决策依赖当时的业务约束，业务变化后必须重新评估；关键是架构的扩展性预留（如设计时就考虑分片、异步化）；演进路径（垂直优化 → 水平扩展 → 拆分）

第三部分：面试者参考回答（300-600 字口语化）

面试官您好，架构做权衡，是因为没有任何技术能同时满足所有诉求，我们只能在业务约束下选最优解。

架构权衡的三大前提：

1. 架构是为了应对"当前方案已经不够用"才引入，不是主动炫技。资源充足时单体能扛就用单体，YAGNI 原则（You Aren't Gonna Need It），别过度设计。
2. 架构是业务约束下的最优解，不是技术最优。同样一个需求，金融业务和 C 端业务选的方案完全不一样。
3. 权衡的核心是"代价是否可承受"——每个方案都有代价，关键是业务能不能接受。

架构权衡七大维度：

• 一致性 vs 可用性（CAP）：CP 选 ZK/MySQL 主从同步、AP 选 Redis/Cassandra；
• 实时性 vs 最终一致性：同步 RPC 强一致 vs MQ 异步最终一致；
• 性能 vs 成本：自研 vs 云服务、垂直优化 vs 水平扩展；
• 扩展性 vs 简单性：微服务拆分 vs 单体，水平扩展 vs 提前分片；
• 开发效率 vs 复杂度：微服务治理成本高，但利于团队扩张；
• 可维护性 vs 灵活性：模块化强类型 vs 快速原型；
• 可观测性 vs 侵入性：链路追踪埋点 vs 业务代码被污染。

权衡方法论四步：

1. 明确业务约束：QPS 峰值、SLA、P99 响应、预算、团队能力、上线时间；
2. 列出候选方案：至少 2-3 个（Redis vs MySQL vs 混合）；
3. 多维度打分对比：性能/成本/复杂度/风险/可维护/团队能力；
4. 最坏情况评估：选错了代价是什么？能否灰度回滚？

举例——我在项目里做过一个典型权衡：早期用户查询订单，一开始用 MySQL 单表直接查，QPS 几百。业务量涨到几千 QPS，我评估三个方案：加 Redis 缓存（性能好但有一致性问题）、分库分表（复杂度高但可扩展）、读副本（简单但有主从延迟）。权衡结果是选加 Redis 缓存 + 延迟双删，因为成本最低、开发最快、能满足 90% 场景，同时用业务幂等兜底缓存不一致的极端情况。

架构演进的核心：不是"想清楚再做"，而是"够用就行，问题驱动演进"。阿里早期也是单体，业务增长后逐步微服务化。过早微服务化、过早分库分表，都是拿团队成本和复杂度换不存在的扩展性。

总结：架构不是画图，是在业务约束下用最少代价满足最多诉求——权衡的本质是"没有银弹"，权衡的价值是"选到最优解"，权衡的边界是"够用就行"。