微服务 vs. SOA

微服务和面向软件架构（SOA）是软件开发的两个组件化体系结构。随着云计算时代的发展，更高粒度的微服务架构（MSA）已经从早期的SOA发展而来。然而，这两种方法仍然被广泛使用。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访问持久数据存储。

契约解耦

SOA的一个主要原则是契约去耦，它提供了服务提供者和消费者之间最高程度的去耦。

然而，MSA不支持契约解耦。

容器

容器和微服务是天然匹配的。Dockers和Linux容器等容器在微服务体系结构中工作得很好，但在SOA中使用频率较低。

通过为应用程序封装一个轻量级的运行时环境，容器在微服务应用程序通过DevOps的持续开发、测试和部署周期时提供了一个一致的软件环境。容器可以在虚拟机（VM）和物理机上运行，并且具有较高的服务器利用率。

 

Web服务

SOA和MSA都为Web服务提供支持。事实上，一些但不是所有的MSA微服务都可以被描述为Web服务。

与Web服务一样，微服务对于编程语言（如Java、Perl、Ruby和C++）是无感知的。

远程访问协议

SOA体系结构通常使用简单对象访问协议（SOAP）和消息传递协议（如Microsoft消息队列（MSMQ）和开放标准高级消息队列协议（AMQP）作为其主要的远程访问协议。但是，表示状态转移（REST）有时与SOA一起使用。

MSA通常使用更精简的REST API和AMQP消息传递进行远程访问。

 

容错

SOA的ESB可以成为整个系统的单点故障（SPOF）。如果一个服务速度变慢来，ESB可能会被对该服务的请求压垮。

MSA更具容错性。例如，一个微服务的内存泄漏是，它只会影响特定的微服务。其他微服务将能够继续处理请求。

线程

SOA是多线程的，有更多的开销来处理输入/输出（IOS）。

MSA是单线程的。然而，微服务体系结构通常包括用于处理I/O的一个事件循环event loop。

系统变更

在SOA中，系统变更需要修改整个系统。

在MSA中，可以通过创建新的服务来完成系统性的更改。

 

微服务和SOA相关术语

• API：API通过提供一组用于访问其他应用程序、操作系统或其他软件服务的数据或功能的功能和程序来促进软件开发。

• Web service：Web服务是一种API，它使用一种标准化的方式，通过Web为客户机和服务器提供应用程序之间的互操作性。Web服务使用包括REST、SOAP、XML、Web服务定义层（WSDL）和通用描述、描述和集成（UDDI）的技术通过超文本传输协议（HTTP）进行通信。

• REST  API：REST API是一种遵循REST规则的API，这种体系结构样式现在被用来取代旧的体系结构，例如SOAP，作为访问Web服务的一种更简单、更快的方法。RESTAPI使用超文本传输协议（HTTP）请求指示Web上需要的操作。REST的主要规则是客户端和服务器统一接口的四条规则：通过资源提供访问、通过陈述表示资源、交换自描述性消息以及通过链接连接资源。

• Middleware：中间件是驻留在操作系统外部的软件层，为无法通过内核获得的应用程序提供服务。它为构建应用程序提供统一的高级接口，这些应用程序可以跨不同的系统进行互操作，并提供一组公共服务，以改进应用程序之间的协作。中间件用于SOA而不是MSA，它隐藏了操作系统、硬件和协议的异构性，以及分布式应用程序的复杂性。