单体应用、SOA、微服务架构有什么区别？
- 标签：Spring Cloud、后端、微服务
🏛 业务架构师
三者的演进本质是**"业务复杂度与组织规模增长"驱动的架构演进**：
单体应用：所有功能一个进程一个库。业务早期（0→1，几人团队）开发调试效率最高——本地跑起来啥都有，改个下单逻辑带改个报表，一次发布。痛点在长大之后：任何小改动全量回归、发布互相阻塞、一个模块内存泄漏全站陪葬、几百人合并冲突。
SOA（约 2000-2010）：以 ESB（企业服务总线）为中心，把异构系统（ERP、CRM、老系统）通过标准协议接入互通——解决的是企业内已有系统集成的互联互通问题。但 ESB 是中心化瓶颈和单点，协议重（SOAP/WS-*），服务治理弱，业务复用多于业务解耦。
微服务：去中心化——智能端点 + 哑管道（HTTP/gRPC 直连，无总线），围绕业务域细粒度拆分，独立部署与数据自治，配套自动化治理（K8s、监控、CI/CD）。它解决的是大规模组织并行研发与独立演进的问题。
我用一张对比收尾：
| 维度 | 单体 | SOA | 微服务 |
|---|---|---|---|
| 拆分依据 | 不拆 | 按系统集成 | 按业务域 |
| 通信 | 进程内 | ESB 总线 | 轻量直连 |
| 数据 | 单库共享 | 多库共享 | 库表私有 |
| 部署 | 整体 | 系统级 | 服务级独立 |
架构师结论：没有最好的架构，只有匹配业务阶段与团队规模的架构——我经手的从单体演进的项目，活得好的一定是"边界先想清楚、组件后跟上"的，而不是"先把服务拆了再说"的。
🏗 系统架构师
三代对比：
- 单体：一个部署单元、一个数据库、进程内调用。优点：开发调试简单、本地事务一致、运维对象单一；痛点：代码腐化后牵一发动全身、扩容只能整体复制（资源浪费）、发布节奏互相绑架；
- SOA：面向服务的架构，企业集成背景——粗粒度服务加 ESB 总线做路由、协议转换、编排。总线是能力中心，也是瓶颈与单点，变更链路长、治理重；
- 微服务：细粒度、独立数据、智能端点哑管道（ESB 职责分摊到网关、SDK、mesh）、去中心化、自动化部署。
演进逻辑（架构视角）：三者不是替代关系，而是粒度与治理权重的权衡。ESB 的「集中智能」在云原生时代被解构：南北向流量归网关，东西向治理归 SDK/mesh，编排归流程引擎——微服务本质是 SOA 思想在康威定律约束下的工程化重构。
我的实践口径：初创与小团队单体优先（模块化做好）；中大型按领域拆微服务；遗留 ESB 系统改造走绞杀者模式渐进替换——新功能走新架构、旧功能按流量逐步迁移，不推倒重来。
💻 全栈开发专家
用表格对比最清楚：
| 维度 | 单体 | SOA | 微服务 |
|---|---|---|---|
| 拆分 | 不拆/模块化 | 粗粒度（按系统集成） | 细粒度（按业务能力） |
| 通信 | 进程内 | ESB 总线（SOAP，智能管道） | 轻量 HTTP/RPC/MQ（哑管道+智能端点） |
| 数据 | 单库 | 常共享 DB | 每服务独立库 |
| 部署 | 整体一次 | 服务化部署 | 独立部署独立伸缩 |
| 典型问题 | 牵一发动全身、发布慢 | ESB 成瓶颈单点、治理重 | 分布式复杂度、运维成本 |
演进关系：SOA 解决"企业内遗留系统怎么互通"（ESB 做协议转换与编排）；微服务解决"业务怎么快速演进"（去中心化、独立交付），可视为 SOA 理念的轻量化实践。
实践观点：三者没有绝对优劣，按阶段选——0→1 用单体最快；团队与业务膨胀后拆微服务；SOA 形态今天主要体现在企业集成场景（ESB 换成 API 网关 + 消息平台）。面试抓住两个分水岭：哑管道 vs ESB、数据库是否独占，比背表格加分。