“要不要拆微服务"大概是被问得最多的架构问题。我的答案一直是:它不是技术判断题,是复杂度分配题——拆分不会消灭复杂度,只会把它从代码内部搬到网络边界上。
拆分的真实收益
按重要性排序:
- 独立部署:团队 A 发版不再需要团队 B 回归测试——这是微服务唯一不可替代的收益
- 故障隔离:一个模块 OOM 不再拖死整个进程
- 异构技术栈:推荐服务用 Python、网关用 Go,各用所长
- 独立扩缩容(多数团队用不到,单库瓶颈往往先于服务瓶颈出现)
注意"代码复用"“性能提升"不在列表里——它们通常是拆分的幻觉收益。
拆分的成本
- 一次跨服务调用 = 序列化 + 网络 + 重试 + 超时 + 幂等,原先的一个函数调用变成了一场分布式事务
- 排查问题从"看栈"变成"看分布式追踪”,可观测性投入从可选变成必选
- 数据一致性从数据库事务退化为最终一致,业务要学着接受中间态
我的判断标准:三个信号
信号一:部署耦合。两个模块频繁一起发版、互相等窗口 → 拆了能解耦部署链。 信号二:团队边界。康威定律:系统结构终将长成组织结构。两个模块由不同团队维护、接口经常扯皮 → 按团队边界拆。 信号三:资源画像悬殊。一个模块 CPU 密集、一个内存密集,混部互相干扰 → 拆开独立扩缩。
三个信号一个都没有?恭喜,你的单体是资产不是负债,别拆。
拆到什么粒度停手
比"微"更重要的是"可独立”。一个服务满足:单团队可维护、单会话可理解、单部署单元可发布,就够小了。再往细拆得到的是"纳米服务"——分布式单体,最糟的形态:享受着微服务的全部运维成本,却保留着单体的全部耦合。
演进式路线
单体 → 模块化单体(包边界清晰,内部强制依赖规则)
→ 剥离 1-2 个"痛点服务"(部署最频繁/资源最特殊)
→ 观察半年,按信号决定是否继续
绝大多数中小团队的最优解停在第二层。架构演进的正确姿势是小步试探,而不是一次重写——后者通常是你能遇到的最大的"第二系统效应"现场(见《人月神话》笔记)。
一句话:拆分解决的是人的协作问题,不是代码的质量问题。人没到那个规模,别让架构先到。