后端架构实战（一）：好架构的本质——没有银弹，只有权衡

Thu, 28 May 2026 10:00:00 +0800

写在前面

这是「后端架构实战」系列的第一篇。我写了不少 .NET、分布式、中间件、数据库的笔记，讲的都是"零件"。这个系列想聊的是另一件事：怎么把零件搭成一辆车——也就是软件架构。

但开篇我不想聊微服务、不聊 DDD、不聊任何具体风格。我想先回答一个更根本的问题：到底什么是"好架构"？

答案只有两个字：权衡。理解了这一点，后面七篇才有意义。

一、架构到底是什么

很多人对架构的印象是"画框图"——几张分层图、几个箭头、一堆方框。那是架构的产出，不是架构本身。

1
2
3
4
5
6
7
8
9


架构的本质：在约束下，做"职责如何分配"的决策

 - 哪些东西放在一起，哪些东西拆开
 - 哪些决策现在做，哪些决策推迟
 - 哪些东西自研，哪些东西用别人的
 - 哪些质量属性优先，哪些先牺牲

 画图只是把这些决策记录下来。
 没有决策依据的图，就是 PPT。

一个判断标准：如果你说不出"我为什么这么选、放弃了什么"，那你就没在做架构，只是在抄。

二、第一性原理：一切都是权衡

Fred Brooks 有句名言："没有银弹"（No Silver Bullet）——没有任何一种技术或方法能让软件工程的本质难题一夜消失。架构同理：

1
2
3
4
5
6
7
8


不存在"最好的架构"，只存在"在当前约束下最合适的架构"

 同一个系统，在不同团队、不同阶段、不同规模下，
 "好架构"的答案完全不同。

 10 人的电商团队和 1000 人的电商团队，
 "正确"的架构天差地别——
 不是谁对谁错，是约束变了。

所以资深架构师最常说的话不是"应该用 X"，而是 “It depends”（看情况）。这不是圆滑，是因为架构决策永远依赖上下文。

三、约束的四象限

“It depends” 到底 depend 什么？四个维度：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


┌─────────────────────────────────────────────────────────┐
│ 1. 规模（Scale） │
│ 用户量、数据量、QPS、团队人数 │
│ → 决定要不要拆、要不要分布式 │
│ │
│ 2. 时间（Time） │
│ 上市压力、迭代节奏、技术债务容忍度 │
│ → 决定先糙快还是先打好地基 │
│ │
│ 3. 团队（Team） │
│ 人数、技能栈、分布式经验、运维能力 │
│ → 决定能 hold 住多复杂的架构 │
│ │
│ 4. 成本（Cost） │
│ 服务器、人力、第三方服务、维护开销 │
│ → 决定自研还是采购、能上多少中间件 │
└─────────────────────────────────────────────────────────┘

 四个维度互相牵制。规模涨了 → 团队要扩 → 成本要加 → 时间可能更紧。
 架构决策 = 在这四个约束的"可行域"里找最优解。

关键认知：约束是会变的。今天的最优解，半年后可能就是技术债。所以架构不是一次定死，而是要能演进（第七节会展开）。

四、几个经典的权衡

4.1 性能 vs 可维护性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


追求极致性能 → 紧凑的代码、手工优化、绕过抽象
 ✓ 跑得快
 ✗ 晦涩难懂、改一处崩三处、新人接手难

追求可维护性 → 清晰的抽象、分层、命名
 ✓ 好改、好懂、好测
 ✗ 多一层调用、多一点开销

 绝大多数业务系统：优先可维护性（性能够用就行）
 少数热路径（交易撮合、广告竞价）：性能压倒一切

4.2 一致性 vs 可用性

这就是 CAP。分布式系统的所有痛苦都源于此：

1
2
3
4
5


要强一致 → 协调多数节点、锁、阻塞 → 牺牲可用性和性能
要高可用 → 允许暂时不一致 → 牺牲一致性，要处理冲突

 详见我写的《分布式系统学习笔记（一）：CAP 与一致性》。
 本系列第五篇会讲它在数据层怎么落地。

4.3 简单 vs 灵活（最容易踩的坑）

1
2
3
4
5
6
7
8
9


过度设计（Over-engineering）：
 为"将来可能要用"的需求，提前搭了一堆抽象层
 → 现在用不上，将来真要用时发现猜错了
 → 维护成本白白增加

 YAGNI 原则：You Aren't Gonna Need It。
 不要为想象中的需求买单。
 但也要留"可演进"的接缝——这不是矛盾，区别在于：
 抽象 ≠ 灵活；接缝 ≠ 提前实现。

4.4 自研 vs 采购

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


自研：完全可控、贴合业务、无授权费
 ✗ 要投入人力、要自己维护、要踩坑

采购/开源：成熟、快、社区支持
 ✗ 黑盒、受制于人、可能有授权/合规问题

 经验法则：
 核心竞争力、差异化能力 → 自研
 通用能力（消息队列、缓存、监控） → 用成熟方案
 不要重新发明轮子，除非轮子是你的核心业务。

五、两大反模式

5.1 不设计（Cargo Cult 抄作业）

1
2
3
4
5
6


"大厂都用微服务，我们也上微服务"
"别人用 K8s，我们也要 K8s"
→ 完全不看自己的规模、团队、问题

 这是把"别人的解"套到"自己的题"上。
 约束不同，照抄就是灾难。

5.2 过度设计（Resume Driven Development）

1
2
3
4
5


"我想在简历上写 K8s + Service Mesh + 事件驱动 + CQRS"
→ 一个日活 100 的内部系统，上了全套云原生

 简历好看了，系统难维护了，公司买单了。
 技术选型的依据应是"问题"，不是"我想学/想用"。

这两种病的共同点：决策没有回到约束和问题上。

六、架构是演进的，不是一次定死

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


架构的演进路径（也是本系列的主线）：

 单体 ──→ 模块化单体 ──→ 按领域拆分 ──→ 微服务 ──→ 云原生

 每一步升级，都是在"旧架构扛不住新约束"时才发生：
 单体扛不住团队规模 → 模块化
 模块化扛不住并发 → 拆服务
 服务多了扛不住运维 → 云原生

 关键：
 不要跳级。跳级 = 把未来的税提前交，还可能白交。
 能用单体解决的问题，上微服务就是自找麻烦。

这也是为什么第二篇我要先为单体正名——大多数人低估了单体，高估了微服务。

七、怎么做一个架构决策

给一个可落地的决策框架：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


1. 把问题讲清楚
 不是"要不要上微服务"，而是
 "当前的痛点是什么？是发布耦合、扩容困难，还是团队协作？"

2. 列出所有候选方案
 至少 3 个。哪怕第 3 个是"什么都不做"。
 只有一个方案不叫决策，叫拍脑袋。

3. 对照四象限约束评估每个方案
 规模 / 时间 / 团队 / 成本
 列出每个方案的收益和代价（尤其是代价）。

4. 选定，并记录为什么放弃其他方案
 这一步最重要。用 ADR（Architecture Decision Record）记下来：
 - 背景、决策、理由、后果
 半年后你会感谢自己。

5. 留好回滚 / 演进的接缝
 决策可能是错的，约束会变。
 确保架构能"进"也能"退"。

八、小结

架构 = 在约束下分配职责的决策，画图只是产出
没有银弹：不存在最好的架构，只有当前约束下最合适的
约束四象限：规模、时间、团队、成本——架构决策永远依赖上下文
四大经典权衡：性能↔可维护性、一致性↔可用性、简单↔灵活、自研↔采购
两大反模式：不设计（照抄）、过度设计（简历驱动）
架构是演进的：单体 → 模块化 → 拆服务 → 云原生，不要跳级
决策要记录：用 ADR 写清"为什么这么选、放弃了什么"

下一篇，我先替"单体"说句公道话——模块化单体才是大多数团队被低估的最佳实践。

决策 on 纪伟的个人博客