# 34 · 技术选型决策树

> 一句话点题:**技术选型不是在一堆工具里挑最强的,而是沿着需求、约束、阶段、团队能力和退出成本一路剪枝。成熟的选型,不是证明某个技术好,而是证明在当前约束下,它的收益配得上代价。**

---

> **🧰 技术栈选型篇第 8 章 · 本篇收束**
>
> 前 7 章分别讲了语言、数据库、缓存队列、API、部署、观测、AI 基础设施。这一章不再新增工具,而是给你一棵统一的决策树。以后遇到任何「要不要上 X」,都按这棵树走一遍。

---

## 开场:选型的根节点不是 A 还是 B

技术选型的第一个问题,不是:

```
   PostgreSQL 还是 MongoDB?
   REST 还是 gRPC?
   PaaS 还是 K8s?
   API 还是自建推理?
```

而是:

> 我们真的需要引入新技术吗?

如果现有技术栈能在目标性能、成本、可靠性和交付周期内解决问题,默认沿用现有栈。任何新技术都会带来学习成本、集成成本、运维成本和未来迁移成本。

这和前面反复说的克制是一脉相承的:能单体就别微服务,能工作流就别 Agent,能托管 API 起步就别自建 GPU。架构师把选型理解成**为一个明确问题支付一笔明确成本**。

---

## 一、第一刀:现在处在哪个阶段

同一个系统,不同阶段答案完全不同:

| 阶段 | 最缺什么 | 选型倾向 |
|---|---|---|
| **MVP** | 验证速度 | 少组件、主流栈、托管优先、低迁移成本 |
| **成长期** | 可控增长 | 可观测、灰度、边界清晰、能局部扩展 |
| **规模期** | 效率与成本 | 深度优化、平台化、单位成本、自动化治理 |
| **关键期** | 稳定与合规 | 审计、隔离、容灾、SLO、事故流程 |

一个技术在成熟期是正确答案,在 MVP 可能就是过度设计。验证需求时,优先少组件;支撑增长时,优先可控;优化规模时,才值得为单位成本、吞吐和深度定制付出复杂度。

---

## 二、第二刀:系统会先死在哪里

当确认现有栈不够,不要马上找工具,先定位失败模式:

| 失败模式 | 优先看 |
|---|---|
| 数据错、状态对不上 | 数据模型、事务边界、幂等、Outbox、对账 |
| 读热点打爆主库 | 缓存、读模型、CDN、限流 |
| 写洪峰压垮后端 | 队列、背压、削峰、异步状态 |
| P99 被扇出放大 | API 边界、超时预算、降级、trace |
| 发布容易出事故 | 部署平台、灰度、回滚、配置治理 |
| 出事定位困难 | 指标、日志、链路追踪、SLO 告警 |
| AI 质量漂移 | eval、trace、RAG 评测、模型路由 |
| 团队协作卡住 | 模块边界、平台工程、服务 ownership |

> **判断句:**工具只是答案的外壳,失败模式才是选型的题目。

---

## 三、第三刀:团队能不能养得起

很多技术在 benchmark(基准测试)里很好看,但你的团队不一定养得起。养得起包括:

- 会不会部署?
- 会不会排障?
- 有没有监控?
- 线上坏了谁能修?
- 版本升级会不会炸?
- 有没有足够多的人理解它?

一个「性能更强但没人会修」的系统,在生产里常常输给「性能够用但团队熟悉」的系统。技术选型不是实验室比赛,而是长期运营合同。要把可运维性和关键人员风险写进判断,否则选中的不是技术,是未来事故。

---

## 四、第四刀:能不能退出

成熟的选型一定有退出方案:

| 技术 | 退出问题 |
|---|---|
| 新数据库 | 数据怎么迁移?双写如何校验?回滚到哪里? |
| 模型供应商 | API 能否适配?提示和 eval 能否复用? |
| 框架 | 业务逻辑是否被框架吞掉?能否分层隔离? |
| 消息系统 | topic / schema / 消费位点如何迁移? |
| 云平台 | 镜像、配置、密钥、存储、网络能否移走? |

没有退出路线的选型,就是把未来绑死。重要技术进入生产前,至少要有 Spike(小实验)、灰度计划、回滚方案和 ADR。

---

## 五、统一决策树

```
要不要引入新技术?
  │
  ├─ 现有栈能满足目标? ── 是 ─▶ 沿用 + 局部优化
  │
  └─ 否
      │
      ├─ 现在是 MVP? ── 是 ─▶ 选最少组件、最快验证、低迁移成本
      │
      └─ 否
          │
          ├─ 失败模式是什么?
          │    ├─ 数据/一致性 → 先看存储与事务边界
          │    ├─ 延迟/吞吐   → 先看缓存、批处理、扩展方式
          │    ├─ 可用性/失败 → 先看冗余、降级、隔离
          │    ├─ AI 质量     → 先看 eval、RAG、模型路由
          │    └─ 团队协作    → 先看模块边界、平台能力
          │
          └─ 候选方案能否被团队养住、能否退出?
               ├─ 不能 → 换轻一点的方案
               └─ 能   → Spike 验证 → 写 ADR → 灰度采用
```

---

## 六、技术选型 ADR 模板

```md
### ADR-034:引入 OpenTelemetry 统一链路追踪

- 背景:订单请求跨 7 个服务,P99 偶发超过 2s,只有各服务日志,定位一次问题平均 3 小时。
- 目标:把跨服务请求路径和每跳耗时串起来,把 MTTR(平均恢复时间)降到 30 分钟以内。
- 候选:
  - 继续加日志:成本低,但无法稳定还原调用路径。
  - 引入私有追踪方案:定制强,但未来迁移困难。
  - 使用 OpenTelemetry:埋点标准化,后端可替换。
- 选择:使用 OpenTelemetry 采集 trace,先覆盖订单、库存、支付三条关键链路。
- 放弃:短期增加埋点工作和采样治理成本。
- 换来:慢请求能跨服务定位,后续可接不同观测后端。
- 复审条件:采样成本超过预算,或关键链路覆盖率低于 90%,重新评估采样策略和埋点规范。
- 退出方案:保留标准 trace context,观测后端可替换;业务代码不绑定某个厂商 SDK。
```

ADR 的重点不是格式,而是把「为什么选」和「选错怎么退」写清楚。

---

## 七、总表:每章的核心判断

| 章节 | 不要先问 | 先问 |
|---|---|---|
| [27](27-编程语言与后端框架选型.md) 语言/框架 | 哪个语言更先进 | 团队、生态、运行时、业务复杂度匹配吗 |
| [28](28-数据库与存储选型.md) 数据库/存储 | 哪个数据库最强 | 事实源是谁,查询形态是什么 |
| [29](29-缓存消息队列与事件系统选型.md) 缓存/队列/事件 | 要不要上 Kafka | 是读热点、时间错配,还是业务事实广播 |
| [30](30-API与服务通信选型.md) API/通信 | REST 还是 gRPC | 同步/异步、内部/外部、契约强度是什么 |
| [31](31-云原生与部署平台选型.md) 部署平台 | 要不要 K8s | 团队是否需要并养得起平台能力 |
| [32](32-可观测性与可靠性技术栈选型.md) 观测/可靠性 | 用哪个监控工具 | 用户 SLO 是什么,事故怎么收场 |
| [33](33-AI基础设施技术栈选型.md) AI 基础设施 | 要不要自建 GPU | 稀缺资源是模型、上下文、成本、质量还是可控性 |

---

## 🎯 随堂检验

<Quiz
  question="团队准备引入一个很新的数据库,理由是 benchmark 很快。但现有数据库还没到瓶颈,团队也没人有生产运维经验。按本章决策树,最合理的判断是?"
  :options="['马上引入,性能强就是正确答案', '先不引入;没有明确失败模式,团队也养不起,这是为未来事故买单', '把所有数据一次性迁过去,逼团队学习']"
  :answer="1"
  explanation="决策树第一刀是有没有必要。现有栈没到瓶颈,就没有为新技术付成本的理由;团队不会运维又放大了生产风险。benchmark 不是选型结论,失败模式、阶段和团队能力才是。"
/>

<Quiz
  question="一个重要技术选型在进入生产前,最应该留下什么?"
  :options="['一段「这个技术很先进」的说明', 'ADR:选择理由、替代方案、接受的代价、重新评估条件和退出方案', '只要能跑通 demo 就够了']"
  :answer="1"
  explanation="重要选型必须可追溯、可复盘、可退出。ADR 把为什么选、为什么不选其他、代价是什么、何时重评估、失败怎么退写清楚,这才是架构判断的沉淀。"
/>

---

## 本章小结

- **选型的根节点是「要不要新技术」**:现有栈能满足目标,默认沿用。
- **阶段决定答案**:MVP 买速度,成长期买可控,规模期买效率,关键期买稳定与合规。
- **先定位失败模式,再比较工具**:数据、延迟、成本、质量、协作,对应的是不同问题。
- **团队养得起才算选得上**:可运维性比纸面性能更接近生产真相。
- **好选型必须能退出**:Spike 验证、ADR 记录、灰度采用、保留迁移路线。

> **技术栈选型篇收束**:这 8 章不是让你记住更多技术名,而是训练一句话:**先看约束,再选技术;先承认代价,再享受收益。** 接下来读 `templates/` 和 `cases/` 时,你可以反过来问每一个系统:它为什么是这套技术栈?如果约束换了,答案会不会变?

---

## 相关链接

- 方法论本体:[02 · 架构师的思考框架](02-架构师的思考框架.md) · [06 · 质量属性与取舍](06-质量属性与取舍.md) · [08 · 架构决策记录与演进](08-架构决策记录与演进.md) · [09 · 架构品味](09-架构品味.md)
- 练习入口:[templates/README](../templates/README.md) · [cases/README](../cases/README.md)
- 本篇回看:[27](27-编程语言与后端框架选型.md) · [28](28-数据库与存储选型.md) · [29](29-缓存消息队列与事件系统选型.md) · [30](30-API与服务通信选型.md) · [31](31-云原生与部署平台选型.md) · [32](32-可观测性与可靠性技术栈选型.md) · [33](33-AI基础设施技术栈选型.md)