微服务与SOA的四维度对比：本质是两种不同理念，仅在"服务"上交集

关于微服务和SOA的关系，常见三种观点：微服务是SOA的一种具体实现方式；微服务是去掉ESB后的轻量化SOA；微服务和SOA只是相似、本质上是两种不同的架构理念。要判断哪种观点更准确，需要对比几个具体维度。服务粒度上，SOA的服务通常更粗（比如”员工管理系统”整体作为一项SOA服务），微服务的服务更细（同一个”员工管理系统”在微服务架构下会拆成员工信息管理、考勤管理、假期管理、福利管理等更多独立服务）。服务通信上，SOA靠ESB这个重量级组件负责服务定义、路由、消息转换、消息传递；微服务推荐用统一的轻量协议（RESTful、RPC），Martin Fowler把这种通信理念称为”Smart endpoints and dumb pipes”（聪明的终端，愚蠢的管道）——之所以说管道”愚蠢”，是相对ESB而言：ESB既知道每个服务用什么协议（RMI还是HTTP）、又知道数据类型（XML还是JSON）、还知道具体格式（日期是2017-01-01还是01/01/2017），而微服务的”dumb pipes”只负责传消息，对消息内容和格式一无所知。服务交付上，SOA对交付方式没有特殊要求（因为它更关注兼容已有系统），微服务的理念要求”快速交付”，因此天然要求自动化测试、持续集成、自动化部署这类敏捷开发能力，没有这些支撑，微服务数量一旦超过约20个，整体交付速度反而会明显变慢。应用场景上，SOA更适合庞大、复杂、异构的企业级系统（这正是SOA的诞生背景：很多系统已运行多年、技术栈各异、有自研有采购，无法推倒重来，只能靠ESB兼容），微服务更适合快速、轻量、基于Web的互联网系统（业务变化快、需要快速试错快速交付，虽然技术栈也可能不同，但对外基本都是HTTP RESTful接口，不需要ESB那套复杂适配）。综合这几个维度，微服务和SOA本质上是两种不同的架构设计理念，只是在”服务”这个点上有交集——这正对应前述第三种观点。Martin Fowler本人对微服务的定义精炼出了三个关键词：small（小）、lightweight（轻量）、automated（自动化），这三个词基本浓缩了微服务的精髓，也正是它和SOA的本质区别所在。

结构图：

flowchart TB
  A["微服务 vs SOA 四维度对比"]
  A --> B["服务粒度：SOA粗 vs 微服务细"]
  A --> C["服务通信：SOA靠重量级ESB<br/>vs 微服务用轻量协议(Smart endpoints, dumb pipes)"]
  A --> D["服务交付：SOA无特殊要求<br/>vs 微服务要求自动化测试/CI/CD支撑"]
  A --> E["应用场景：SOA适合庞大复杂异构企业系统<br/>vs 微服务适合快速轻量Web互联网系统"]
  B --> F["结论：本质是两种不同理念<br/>只在'服务'这一点交集<br/>Martin Fowler三词：small/lightweight/automated"]
  C --> F
  D --> F
  E --> F

内容

参考来源