# 架构取舍与决策

> 架构不是「设计」出来的，是在业务、组织、成本、时间四类约束下**选**出来的。专家的能力不在于知道更多方案，而在于知道每个方案要付什么代价、什么时候可以退。

## 一、先分清「问题」和「方案的形状」

同一个需求，三种团队会给出三种架构：小团队上单体，大团队拆服务，合规团队加隔离。差别不在技术水平，而在约束不同。所以架构讨论的第一句话不该是「用什么技术」，而是：

1. 这个系统要解决的核心问题是什么？**不做会怎样**？
2. 硬约束有哪些（合规、预算、上线时间、团队规模）？
3. 哪些是**不可逆**决策，哪些可以以后再改？

## 二、四类约束

| 约束 | 具体表现 | 对架构的影响 |
| --- | --- | --- |
| 业务 | 峰值流量、数据一致性要求、上线节奏 | 决定拆分粒度、同步/异步、存储选型 |
| 组织 | 团队数量、职责边界、汇报关系 | 决定服务边界（康威定律）、接口契约成本 |
| 成本 | 人力、机器、运维、合规审计 | 决定自建还是采购、是否值得为峰值付冗余 |
| 时间 | 上线窗口、监管期限、竞争节奏 | 决定先做哪一部分，是否接受技术债 |

约束会变：今天因为人少选单体，明天因为业务翻倍要拆。**能被识别为「约束驱动」的决策，才经得起复盘。**

## 三、质量属性的权衡表

架构决策本质是在质量属性之间交换，没有全赢。

| 属性 | 提升它要付的代价 | 常见交换 |
| --- | --- | --- |
| 性能 | 缓存、冗余、专用硬件 | 一致性变弱、成本上升 |
| 一致性 | 分布式事务、串行化 | 吞吐下降、可用性下降 |
| 可用性 | 多副本、多机房、降级链路 | 成本翻倍、复杂度上升 |
| 可维护性 | 抽象层、模块边界 | 初期开发变慢、代码量增加 |
| 交付速度 | 简化流程、减少审批 | 质量风险、事故概率上升 |
| 可观测性 | 埋点、日志、追踪 | 存储与性能开销 |

写方案时，把这张表当成检查表：**你提升了哪一项，付出了哪一项，为什么这个交换值得。**

## 四、把取舍写下来：ADR

架构决策记录（ADR）不需要长，一页足够：

```text
# ADR-012 订单服务拆分
状态：已接受（2026-03）
背景：订单量大促峰值 5 倍，单体发布互相阻塞，团队 3 个组共用一个仓库
约束：6 个月内不改动账务系统；运维只有 2 人；预算增加不超过 30%
选项：
  A 单体内部模块化（成本低，发布仍耦合）
  B 按域拆 3 个服务（发布独立，运维与联调成本上升）
  C 只拆读链路（收益一半，复杂度增加一半）
决定：选 B，先拆订单与库存两个服务
代价：需要引入服务注册、链路追踪；团队要学分布式事务（见 ADR-013）
放弃：A 无法解决发布耦合；C 的收益不足以覆盖改造量
复审：6 个月后评估拆分是否带来预期的发布效率
```

ADR 最重要的两行是**「代价」和「放弃」**。只写优点的方案不是决策，是推销。

## 五、可逆决策与不可逆决策

把所有决策按「改回去的成本」分类：

| 类型 | 例子 | 处理方式 |
| --- | --- | --- |
| 可逆 | 缓存组件、日志方案、框架内工具库 | 快决策，先跑起来，错了再换 |
| 半可逆 | 服务拆分、数据库选型 | 小步验证，留迁移路径 |
| 不可逆 | 数据模型主键、对外 API 契约、合规存储位置 | 慢决策，多方评审，留冗余 |

团队最常见的浪费是：**在可逆决策上反复开会，在不可逆决策上拍脑袋。**

## 六、五个常见错误

1. **为想象中的未来设计**：为「以后可能有千万用户」提前拆分，结果复杂度先到、用户没到。正确做法是保留演进路径，而不是提前支付成本。
2. **过度抽象**：为了复用造了五层接口，实际只有一个实现。抽象应该来自第二、第三个真实用例，而不是想象。
3. **忽略组织边界**：服务拆得再漂亮，如果两个团队要天天开会才能改一个接口，拆分就是负收益。
4. **把技术选型当架构**：选 Kafka 还是 Pulsar 是选型；决定「哪些数据走事件、哪些走同步调用」才是架构。
5. **没有退出路径**：任何引入的中间件、框架、云服务，都要回答「如果不用了，怎么退」。没有退出路径的技术选型，等于给自己上锁。

## 七、演进式架构的三条原则

- **保持可逆**：优先选择能改回去的方案，把不可逆的部分做得足够小；
- **小步验证**：先在一个业务线/一个读链路验证，再推广；
- **让约束显性**：把「我们为什么这样」写进文档，否则半年后没人记得，只剩「以前就是这么设计的」。

## 八、自检清单

- [ ] 我能用三句话说清当前架构的**核心约束**与**主要代价**
- [ ] 最近的架构决策有 ADR，且写明了被否决的方案与原因
- [ ] 我能区分手上哪些决策可逆、哪些不可逆
- [ ] 我的方案包含「不做什么」，并说明为什么不做
- [ ] 引入的每个中间件都有退出路径与替代方案
- [ ] 拆分/抽象的粒度与团队边界一致，而不是与理想模型一致
- [ ] 方案里给了验证指标：上线后怎么判断这次决策对了
- [ ] 我能说出这次决策在什么条件下应当被推翻