微服务 vs. SOA

理解面向服务架构

SOA是通过消息中间件进行服务间通信的服务集合。中间件层还支持多协议的互通。服务的范围可以一直延伸到企业内的子系统大小。

SOA通常被认为是在运行多操作系统(如 Linux 和Windows)的大型混合环境中集成不同系统的最好的选择。

理解微服务

另一方面，在微服务中，每个应用程序都被构造成一个小型服务的集合，围绕一个业务域建模。该体系结构使用应用程序编程接口（API）层而不是中间件，并且协议是轻量级的。微服务的最佳实践要求开发人员在设计之初使用API进行构建。

微服务在构建小的、分区良好的基于Web的系统方面工作得更好，这些系统给开发人员很大的控制权。每个服务都是为了实现特定的目的而设计的——比如激活订单或提供购物车服务的Web服务——并且在实现这一目的方面表现出色。

比较微服务和SOA

SOA和微服务都通过用更容易管理的模块化组件替换旧的单体结构来简化软件开发。然而，SOA和MSA在包括一般体系结构、服务特性、组件共享方法、数据库支持等方面存在显著差异。

以下是一些关键区别：

通常架构

SOA定义了一个提供者层（包括系统中的所有服务）和一个使用者层，或者消费者（如用户或其他服务）与系统交互的点。企业服务总线（Enterprise Service Bus，ESB）允许服务提供者和服务使用者之间进行各种点对点连接。服务可以由多个开发团队创建，但每个团队都需要了解通用的通信机制。

另一方面，在MSA中，小型的、独立的进程在高度粒度和敏捷的应用程序中相互通信。每个服务能够独立部署，这意味着服务能够在不影响整个系统的情况下被下线。MSA使得开发现有服务的新版本更加容易和快速。这个架构符合DevOps的最佳实践。此外，根据负载要求，服务可以独立扩展。

服务特点

SOA和微服务都依赖服务作为他们的主要组件，然而，这两种架构在服务特性方面存在很大差异。

SOA定义了四个基础的服务类型：

• SOA的功能服务，也简称为业务服务，用于定义核心业务操作的粗粒度服务。功能服务通过可扩展标记语言（XML）和业务流程执行语言（BPEL）等协议来表示。

• 企业服务实现由业务服务定义的功能，使用应用程序服务和基础设施服务来满足业务请求。

• 应用程序服务是仅在特定应用程序上下文中使用的细粒度服务。可以通过专用用户界面（UI）调用服务。

• 基础设施服务实现诸如日志记录、身份验证、审计和安全性等非功能性任务。这些服务可以被应用程序服务或企业服务来调用。

相比之下，MSA只定义了两种基本服务类型：

• 在MSA中，功能性服务支持特定的业务操作。这些服务是从外部访问的，不与其他服务共享。

• 与SOA一样，MSA的基础设施服务用于支持诸如日志记录、审计和安全性等任务。不过，MSA的基础设施服务不与其他服务共享，只能在内部访问。

中间件与API

SOA的中间件提供了许多API中没有的功能，这些API用于MSA中服务提供者和消费者之间的通信。

中间件层的优点包括协议转换、消息增强以及调解和路由。由于MSA不支持中间件，并且MSA应用程序非常小，而且是专门为之设计的，所以SOA通常被认为是大型和复杂企业系统的最佳体系结构。

数据库支持

在SOA中，所有的服务使用相同的底层数据库。服务一般支持传统的关系型数据库。

MSA在这方面也更加灵活和复杂。一个数据库可以只给一个特定的微服务使用，也可以给多个微服务共用。MSA也更可能使用更新的非关系型数据库。与仅支持结构化数据的关系数据库不同，非关系数据库还支持半结构化数据（如电子邮件和XML文档）和非结构化数据（如Microsoft Windows文档、网页、社交媒体消息和视频文件）。

组件共享

SOA旨在通过增强组件共享来促进业务功能的重用。实际上，组件共享是SOA企业服务的主要角色。服务通常作为完整的子系统实现。但是，由于SOA使用多个组件来满足业务请求，因此SOA服务的效率可能低于微服务。

另一方面，微服务通过“有界上下文”最小化了组件共享，组件及其数据以最小依赖性作为单个单元耦合。应用程序需要通过服务实现提供的API访问持久数据存储。