单体架构还是微服务：技术选型决策框架

做技术选型时，单体架构还是微服务几乎是每个团队都会撞上的岔路口。它之所以难，是因为没有放之四海皆准的答案：十年前被追捧的微服务，今天正被一批公司回退成单体；而那些盲目追新的团队，往往先被分布式复杂度拖垮。本文不站队，而是给你一套可落地的技术选型决策框架，用评分表、拆分信号和决策固化方法，把”拍脑袋”变成”有据可依”。

一、先看清两种架构的真实成本

1.1 单体的隐性成本

单体被喷得最多的”臃肿、耦合”，在早期其实是优势：一个进程、一份部署、一根调用链，调试和发布都简单。它的隐性成本出现在规模拐点之后——代码库大到没人敢动、一个小改动要全量回归、技术栈被早期选择锁死。换句话说，单体的成本是被”时间”慢慢放大的。

1.2 微服务的显性成本

微服务把复杂度从”代码内部”搬到了”网络与运维”：服务发现、分布式事务、链路追踪、配置中心、多语言构建流水线，每一项都是实实在在的工程负担。很多团队上了微服务后才发现，真正吃掉人力的不是写业务，而是维持这套分布式基建。所以微服务的收益，必须能覆盖它引入的运维熵增。

二、六维决策评分表

与其凭感觉，不如把选型拆成六个维度逐项打分（1=强烈倾向单体，5=强烈倾向微服务），加权后看总分。下表列出常见维度与判别信号：

经验法则：当总分偏高且”运维成熟度”一项不低时，微服务才划算；如果运维成熟度垫底，宁可先打磨单体内的模块边界，也别急着上分布式。

三、组织信号：康威定律在说话

架构终将长成沟通结构的样子（康威定律）。如果你拆出了 20 个微服务，却只有 5 个人维护，那不过是”分布式单体”——比单体更糟。反过来，当团队已经按业务线分成了多个小组，组织结构本身就在要求架构解耦。所以选型前先问一句：我们的团队结构，撑不撑得起这套架构？

四、什么时候该坚持单体

出现以下信号时，单体仍是更优解：业务模型尚在快速探索、领域边界未稳定；团队小于 10 人；当前瓶颈是”需求交付慢”而非”系统耦合”。此时正确的做法不是拆服务，而是在单体内做模块化——用清晰的包边界、领域分层和接口契约，为将来可能的拆分预留切口。

五、什么时候该拆分微服务

当这些信号同时出现，拆分才真正划算：某个模块被高频独立发布，拖累全量；某一功能需要远超其他的算力或存储扩展；团队已多组并行、协调成本超过开发成本；核心域与非核心域需要不同可用性 SLA。注意，“该拆”的判断应来自数据和组织信号，而非技术时髦度。

六、拆分不是终点：渐进迁移

决定拆分后，千万别”大爆炸”重写。更稳妥的路径是在单体之外新起服务，用路由把流量一点点切过去，验证无误再下线旧代码。这种绞杀者模式能让你在不宕机的前提下完成演进，实战细节可参考绞杀者模式实战：遗留系统渐进式重构不宕机。拆分后新服务的上线，同样建议用金丝雀发布实战控制风险，渐进放量而非一把梭。

七、用 ADR 把决策固化下来

选型最大的坑，是半年后没人记得”为什么这么选”。用架构决策记录（ADR）把背景、选项、结论写下来，既是对当下的交代，也是对未来的负责。一份最小可用的 ADR 长这样：

# ADR-001 采用微服务拆分订单域

## 状态
已采纳（2026-09）

## 背景
订单域发布频率是全站的 3 倍，且大促期间需独立扩容，
单体全量发布已无法支撑。

## 决策
将订单域拆分为独立服务，使用独立数据库，
通过 API 网关与单体通信。

## 后果
+ 订单域可独立发布与扩缩容
- 引入分布式事务与链路追踪的运维成本
- 需建设服务注册与配置中心

关于 ADR 的模板与协作流程，ADR 架构决策记录实战一文有更完整的写法，建议和本文搭配使用。

八、方案评审时问自己的 5 个问题

在把选型提交评审前，先用这五个问题自检，能挡掉大多数冲动决策：

• 这个拆分解决了哪个具体痛点？能否用模块化代替？
• 我们的运维体系能不能接住新增的分布式复杂度？
• 团队结构和服务边界是否对齐（康威定律）？
• 未来 12 个月，哪个维度会发生质变（规模/频率/异构）？
• 如果选错，回退成本有多高？

拆分完成后，用Feature Flag 实战里的特性开关做渐进发布，可以把”上线即全量”的风险进一步压低。

九、决策框架速查清单

把上面的逻辑压缩成一张”信号到倾向”的速查表，选型会上照着打勾即可：

十、结语

单体与微服务不是优劣之争，而是适配度之争。最好的架构，是当下团队、业务和组织结构下”恰好够用”的那一个。用评分表量化取舍、用信号判断时机、用 ADR 固化结论、用渐进迁移控制风险——当你把选型变成一套可复用的决策框架，技术争论就会回归理性。记住：架构是为业务服务的，别让业务为架构买单。