SOA vs 微服务：架构演进之路
在微服务之前，企业级开发的主流架构叫 SOA（Service-Oriented Architecture，面向服务架构）。
很多人觉得微服务是 SOA 的「颠覆者」，是一种全新的架构模式。
但真相是：微服务是 SOA 的「去中心化版」。
理解这两者的关系，才能理解为什么微服务是「演进」而不是「革命」。
SOA 的诞生背景
21 世纪初，企业应用面临的挑战是：如何把十几年的 IT 资产（遗留系统）整合起来？
比如银行有：
- 30 年前的大型机核心系统
- 15 年前的 COBOL 批处理系统
- 5 年前的 Oracle 数据库
这些系统语言不同、协议不同、数据模型不同，怎么让它们互相通信？
SOA 的答案是：ESB（Enterprise Service Bus，企业服务总线）。
┌─────────┐ ┌─────────┐ ┌─────────┐
│ 系统 A │ │ 系统 B │ │ 系统 C │
└────┬────┘ └────┬────┘ └────┬────┘
│ │ │
└──────────────┼──────────────┘
│
┌─────┴─────┐
│ ESB │
│ 企业服务总线 │
└───────────┘所有系统都连到 ESB，ESB 负责协议转换、消息路由、服务编排。
SOA 的核心特征
1. 企业服务总线（ESB）
ESB 是 SOA 的核心，它做了很多事情：
- 协议转换：SOAP/HTTP/JMS/Socket 互相转换
- 消息路由：根据规则把请求发到正确的服务
- 服务编排：把多个服务组合成一个新服务
- 业务规则：统一的业务逻辑处理
ESB 是中心化的，所有流量都要经过它。
2. Web Service（SOAP/WSDL）
SOA 的服务通常用 SOAP 协议描述，WSDL 定义接口，UDDI 做服务注册。
<!-- SOAP 协议示例 -->
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getUserRequest xmlns="http://example.com/users">
<userId>123</userId>
</getUserRequest>
</soap:Body>
</soap:Envelope>3. 粗粒度服务
SOA 强调「服务复用」，所以服务通常是粗粒度的——一个服务做很多事情。
比如「订单服务」可能包含：下单、支付、取消、查询、统计……
微服务对 SOA 的继承与革命
微服务不是凭空出现的，它继承了 SOA 的核心思想，又做了革命性的改进。
继承了什么
- 服务化思想：把业务能力封装成服务
- 服务注册与发现：服务发布后可以被调用
- 标准化通信：服务之间有明确的接口定义
革命了什么
| 方面 | SOA | 微服务 |
|---|---|---|
| ESB | 中心化 ESB，所有流量经过 | 去中心化，无 ESB，服务直连 |
| 服务粒度 | 粗粒度（复用为主） | 细粒度（自治为主） |
| 通信协议 | SOAP/WSDL（重） | HTTP REST/gRPC（轻） |
| 数据管理 | 共享数据库（常见） | 无共享数据（原则） |
| 部署方式 | 单体应用 + ESB | 独立部署、独立扩展 |
| 治理模式 | 中心化治理（IT 部门） | 去中心化治理（DevOps 团队） |
| 技术栈 | 统一（通常 JavaEE） | 异构（按需选择） |
关键区别：ESB 的消失
SOA 和微服务最大的区别是：ESB 还在不在。
ESB 的问题是：
- 单点故障：ESB 挂了，整个系统瘫痪
- 性能瓶颈：所有流量经过 ESB，ESB 成了性能天花板
- 复杂度：ESB 本身就是一个巨型系统
- 版本锁定：升级 ESB 可能影响所有系统
微服务的思路是：不要 ESB，让服务直接通信。
但没有 ESB，协议转换、路由、编排去哪了？
答案是：服务自己管，或者用轻量级的 API Gateway。
演进路径：单体 → SOA → 微服务
架构演进不是跳跃式的，而是渐进的：
单体架构
↓ 业务复杂，团队扩张
SOA（ESB 模式）
↓ ESB 成为瓶颈，需要更灵活
微服务（去中心化）每个阶段都是对上一阶段的「打补丁」，而不是推翻重来。
这就是为什么说微服务是「演进」而不是「革命」。
大厂案例：Netflix 的演进
Netflix 是微服务领域的先驱，但它的演进也遵循了这个路径：
2006 年：单体起步
Netflix 早期是一个 DVD 租赁网站，用单体架构快速上线。
2008 年：单体崩溃
一次数据库故障导致 Netflix 宕机 3 天。这一刻，他们意识到单体的脆弱性。
2009-2011 年：迁移到云 + SOA
Netflix 开始把服务迁移到 AWS，用 SOAP + ESB 做服务集成。
2012-2015 年：从 SOA 到微服务
ESB 的问题暴露后，Netflix 开始「去 ESB」，把服务拆得更细，用 REST + JSON 替代 SOAP，用 Cassandra 做分布式数据存储。
最终，Netflix 形成了 1000+ 微服务的架构，成为微服务领域的标杆。
面试追问方向
SOA 和微服务最大的区别是什么？
ESB 是关键区别：SOA 有中心化 ESB，微服务去中心化。
微服务是不是就是「把 SOA 拆细了」？
不完全是。拆分粒度是一方面，更重要的是治理模式、技术栈、数据管理的变革。微服务强调「团队自治」，SOA 强调「企业复用」。
什么时候从 SOA 迁移到微服务？
- ESB 成为性能瓶颈
- 团队扩张，需要独立部署
- 需要更高的可用性和扩展性
- 技术栈需要异构化
迁移策略：先从边界清晰、依赖简单的服务开始，逐步替换 ESB。
留给你的问题
Netflix 的演进故事里，有一句话值得玩味：
「我们不是在设计微服务，我们是在解决每天遇到的问题，微服务只是解决方案。」
架构不是目的，是手段。
你的系统现在处于哪个阶段？面临的真正问题是什么？
有时候，把单体优化好，比盲目拆分更务实。