S27-J05 · 架构演进：从模块化到 SOA

适用读者：在"要不要拆服务"上犹豫的人。
前置：S17-B01（微服务挑战）。
覆盖旧文：554(599) + 相关 = 642 点。
扩展点：E-S27-015（拆分的四个判据）。
上一篇：S27-J04 · AOP 与对象转换：代理、拦截、MapStruct
下一篇：S27-J06 · RAG 提效。

1. 一句话结论

架构演进不是"越拆越好"，而是"按组织与变更频率切边界"：模块化解决代码耦合，SOA/微服务解决团队与部署耦合。

阶段	解决	代价
单体	简单	耦合、部署慢
模块化单体	代码边界	仍是单部署单元
SOA	服务复用	ESB 复杂、治理重
微服务	独立部署/扩展	分布式复杂度（S17-B01）

2. 拆分的四个判据（E-S27-015）

判据	说明
变更频率差异	一个模块天天改、另一个半年不动 → 可拆
伸缩性差异	一个要 100 实例、一个 1 个 → 可拆
团队边界	两个团队并行开发（S17-B01 康威定律）
故障隔离需求	一个挂了不能拖垮全部

反例：因为"微服务流行"就拆——只会得到"分布式单体"（拆了但还紧耦合）。

3. 先模块化，再服务化

步骤	收益
① 单体内部划模块（包边界 + 依赖约束）	低成本试边界
② 抽出接口（不跨模块直接访问实现）	为拆分做准备
③ 把热点模块拆成服务	有据可依

判据："在单体内部，这个模块边界清楚吗？" 不清楚 → 拆成服务会更乱。

4. SOA 的教训

SOA 的问题	微服务是否解决
ESB 成为瓶颈/单点	✅（去中心化）
服务粒度太粗	部分（粒度仍要定）
治理复杂	❌（换成另一种复杂）

"为什么 SOA 被微服务取代"：ESB 集中治理 = 单点 + 厂商锁定——但微服务并没有消灭治理，只是把它分散了。

5. 五个误区

误区	真相
"微服务一定优于单体"	复杂度换灵活性
"先拆再想边界"	会得到分布式单体
"模块化没用"	是拆分的必要准备
"拆得越细越好"	运维成本指数上升
"SOA 已淘汰"	思路仍在（服务复用/契约）

6. 自检

四个阶段的演进与代价？
四个拆分判据？
为什么"先模块化再服务化"？
SOA 的 ESB 问题微服务解决了吗？
什么是"分布式单体"？

7. 下一篇

S27-J06 · RAG 提效与数据流水线

架构讲完，下一篇讲"准确率从哪几个点提升最划算"。

本篇属于系列《S27 · 杂项归档与工具实测》。旧文来源：A-554 + 相关卡；扩展点 E-S27-015。