Awesome Architecture

简体中文

English

简体中文

English

外观

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 语言/框架哪个语言更先进团队、生态、运行时、业务复杂度匹配吗
28 数据库/存储哪个数据库最强事实源是谁,查询形态是什么
29 缓存/队列/事件要不要上 Kafka是读热点、时间错配,还是业务事实广播
30 API/通信REST 还是 gRPC同步/异步、内部/外部、契约强度是什么
31 部署平台要不要 K8s团队是否需要并养得起平台能力
32 观测/可靠性用哪个监控工具用户 SLO 是什么,事故怎么收场
33 AI 基础设施要不要自建 GPU稀缺资源是模型、上下文、成本、质量还是可控性

🎯 随堂检验 ​

🤔团队准备引入一个很新的数据库,理由是 benchmark 很快。但现有数据库还没到瓶颈,团队也没人有生产运维经验。按本章决策树,最合理的判断是?
  • A马上引入,性能强就是正确答案
  • B先不引入;没有明确失败模式,团队也养不起,这是为未来事故买单
  • C把所有数据一次性迁过去,逼团队学习
🤔一个重要技术选型在进入生产前,最应该留下什么?
  • A一段「这个技术很先进」的说明
  • BADR:选择理由、替代方案、接受的代价、重新评估条件和退出方案
  • C只要能跑通 demo 就够了

本章小结 ​

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

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

相关链接 ​

💬 评论