开始之前，我们先简单看下单体架构、SOA与微服务之间的区别，如下图所示：简单来讲，对于单体架构，其就像一个超大容器，容器内集中包含了该应用的所有软件组件，并且组件与组件之间紧密耦合。
而对于SOA架构来说，其本质上也是服务的集合，服务与服务之间彼此调用，这种调用可能涉及到简单的数据处理或者有超过多个服务之间相互协作共同完成模型业务操作，在SOA中我们需要考虑服务之间应如何相互通信。
最后说到微服务，或者我们称之为微服务架构，这是一种架构风格，聚焦业务领域，将应用通过一个个小而自治的服务组织起来。
说到SOA与微服务，两者均依赖于服务作为其主要组件，但不同架构下的服务特征却有很大的不同，下面我们看下SOA与微服务之间的主要区别都有哪些？
对于SOA来说，其定义了四种基本类型的服务
Business Services： 业务类服务
- 粗粒度服务，主要定义关键业务操作
- 通常可以通过XML或者BPEL语言来表示
Enterprise Services： 企业级服务
- 实现业务类服务所定义的相关功能
- 主要依赖于应用级服务和架构级服务来满足业务需求
Application Services： 应用级服务
- 细粒度服务，聚焦特定的应用上下文
- 特定的用户接口界面可直接调用这些服务
Infrastructure Services： 基础架构级服务
- 主要负责非功能性操作，比如：认证、授权、安全、日志等等
- 可由应用级服务或者企业级服务直接调用。
微服务则减少了服务的分类，仅包含了两种类型服务
Functional Services： 功能性服务
- 支持特定的业务操作
- 服务聚焦对外服务，服务之间不共享
Infrastructure Services： 基础架构级服务
- 和SOA一样，基础架构级服务侧重于审计、安全和日志类等基础类支持服务
- 基础架构级服务并不对外开放
| SOA | MSA |
|---|---|
| 遵循尽可能多的共享 | 仅可能少的共享 |
| 更多的强调业务功能的重用 | 侧重边界上下文：bounded context |
| 遵从共同的标准和公约 | 侧重于协作，强调自治 |
| 服务之间采用ESB通信 | 简单消息系统 |
| 支持多种协议 | 更青睐于简单消息通信，比如：HTTP REST |
| 多线程，阻塞IO，开销大 | 通常是单线程，事件驱动，非阻塞IO处理机制 |
| 最大化应用服务的可重用性 | 侧重解耦 |
| 通常使用传统的关系型数据库 | 除了传统的关系型数据库，更常见NO SQL等新型关系型数据库的运用 |
| 系统级的更改可能会导致整个系统的修改 | 系统级修改仅需构造新的服务来满足 |
| DevOps/持续交付成为可能，但并非主流 | 着眼于DevOps/持续交付 |
SOA与微服务（MSA）主要区别总结
-
服务粒度 ：微服务强调的是服务功能的纯粹性和单一性，而对于SOA 来说，其服务组件可大可小，比如从很小的应用服务或者很大的企业级服务，比如在SOA中，我们用一个很大的产品或者子系统来表示一个服务
-
组件共享：组件共享是SOA架构的核心原则，而MSA则通过边界上下文Bounded Context来尽可能的减少这种共享的可能性。边界上下文涉及到组件的耦合性以及组件内部的数据的独立性。SOA通常依赖于多个服务来满足实现业务需求，在这种场景下，SOA系统通常较之MSA响应慢
-
中间件 vs API服务网关：MSA架构通常包含我们所熟知的服务网关，而SOA通常则包含消息中间件组件，消息中间件组件一般具备消息路由、协议转换等功能，而MSA的服务网关则主要扮演服务提供方与服务消费者的桥梁作用。
-
远程服务调用：SOA主要依赖于AMQP, MSMQ,SOAP等服务访问协议，而MSA则主要依赖于 REST和JMS, MSMQ等简单消息协议
-
异构的互操作性：SOA通过消息中间件组件使得多个不同协议的相互传递的成为可能，而SOA则简化了服务间的访问协议，如果你希望通过不同的协议来集成多个异构环境，你则需要考虑使用SOA架构，相反，如果你希望通过同样的协议来访问访问，那么MSA可能是一个更好的选择。
最后，总结一句，不能简单的来讲孰优孰劣，而是应该结合您当前正在构建的应用系统来综合考虑。SOA更适合大型、复杂的业务应用程序，比如应用需要许多异构环境的相互交互，换句话讲，相对较小的应用程序并不适合SOA，因为它们不需要消息传递中间件组件。而微服务则更适合较小的、业务分区良好的、基于WEB应用，在这些应用中，开发人员可以有更大的控制权。
原文链接：