SOA 风格自 20 世纪 80 年代末以来一直存在，其起源于 CORBA、DCOM、DCE 和其他人引入的思想。关于 SOA 已经谈了很多，也有一些不同的实现模式，但从本质上讲，SOA 只关注几个概念，并没有给出任何关于如何实现它们的规定：

面向用户的应用程序的可组合性；可重复使用的业务服务；技术栈独立；自主性（独立进化、可扩展性和可部署性）。

SOA 是一套独立于任何技术或产品的架构原则，就像多态和封装一样。

在这篇文章中，我将讨论以下与 SOA 相关的模式：

CORBA——通用对象请求代理架构网页服务消息队列企业服务总线 (ESB)微服务

CORBA——通用对象请求代理架构

在 20 世纪 80 年代，由于企业网络和客户端/服务器架构的使用不断增长，越来越需要一种通用的方式来获取使用不同技术构建并运行在具有不同操作系统的不同计算机上的应用程序，以便进行通信. CORBA 就是为满足这些需求而开发的。它是分布式计算的标准，在 1980 年代开发，并于 1991 年达到第一个成熟版本。

CORBA 标准由多家供应商实施，旨在提供：

平台中立的远程过程调用；交易（也是远程交易！！）；安全;活动；编程语言独立性；操作系统独立性；硬件独立性；与数据传输/通信细节隔离；通过接口定义语言 (IDL) 进行数据类型化。

目前 CORBA 仍然用于异构计算，例如，它仍然是 JAVA EE 的一部分，尽管它从 JAVA 9 开始将被打包为一个单独的模块。

不过，重要的是要注意，我不认为 CORBA 是一种 SOA 模式 （尽管我确实认为 CORBA 和 SOA 模式都属于分布式计算的范畴）。我选择将它包括在这里是因为我觉得是它的缺点导致了 SOA运动。

怎么运行的

首先，我们需要获取一个对象请求代理（Object Request Broker，ORB），它符合 CORBA 规范，由供应商提供，使用语言映射器生成客户端代码语言的存根和骨架。使用该 ORB 和使用 IDL（类似于 WSDL）定义的接口定义，在客户端中，我们生成可以远程调用的真实类的存根类，在服务器中，我们生成 可以处理传入请求的骨架类并调用真实的目标对象。

调用者调用由存根实现的本地过程；存根验证调用并创建传递给 ORB 的请求消息；客户端 ORB 通过网络向服务器发送消息并阻塞当前执行线程；服务器ORB接收请求消息并实例化骨架；骨架在被调用的对象上执行过程；被调用对象执行计算并返回结果；框架将输出参数打包成响应消息并将其传递给 ORB；ORB 通过网络将消息发送回客户端；客户端ORB收到响应消息，解包并传递给存根；存根将输出参数传递给调用者，释放执行线程，调用者继续执行。优点技术堆栈独立性（ORB 实现除外）；与数据传输/通信细节隔离。缺点位置透明性： 客户端代码不知道调用是本地的还是远程的。这听起来像是一件好事，但是，延迟和故障类型完全不同，具体取决于它是本地调用还是远程调用。不知道它是什么类型的调用，使应用程序无法选择适当的策略来处理方法调用，并最终在循环内进行远程调用，从而大大降低整个系统的速度。复杂、冗余和模棱两可的规范： 它是作为几个现有供应商版本的混搭而创建的，因此（当时）它是模棱两可和冗余的，因此难以实施。阻塞的通信管道： 它使用基于 TCP/IP 的特定协议和特定端口，甚至是随机端口。但是企业安全规则和防火墙通常只允许通过端口 80 进行 HTTP 通信，有效地阻止了 CORBA 通信。网页服务

虽然 CORBA 现在仍然有它的用例，但我们了解到我们需要减少远程通信以使系统性能更高， 我们需要可靠的通信管道，我们需要更简单的通信规范。

因此，在 20 世纪 90 年代后期，Web 服务开始兴起，其目标是解决上述问题：

我们需要一个可靠的通信管道，所以：通过端口 80 的 HTTP是默认的通信管道；使用不可知的通信语言（如XML或JSON）；我们需要减少远程通信，因此：我们有明确的远程通信，以便我们准确知道何时进行远程调用；我们有粗粒度的远程调用，即。我们不再经常调用远程对象，而是更少地调用远程服务；我们需要一个更简单的通信规范，因此：SOAP在 1998 年有了第一个草案，并在 2003 年获得了 W3C 推荐，使其成为一个有效的标准。它体现了 CORBA 的一些思想，例如处理通信的层和使用Web 服务描述语言(WSDL) 定义接口的“文档”；REST于 2000 年由 Roy Fielding 在他的博士论文“架构风格和基于网络的软件架构设计”中定义，它是一个比 SOAP 简单得多的规范，这使得它很快获得了比稍旧的 SOAP 规范更高的采用率。GraphQL由 Facebook 于 2012 年开发并于 2015 年向公众发布。它是一种 API 查询语言，它允许客户端准确指定服务器应该发送回哪些数据，而不是一个临时的有效负载，避免了过度获取和获取数据不足。

[Web] 服务可以以技术中立的标准形式发布、发现和使用。

Microsoft 2004， 了解面向服务的体系结构

通过 Web 服务，SOA 实现了从一种远程调用对象方法 (CORBA) 到一种在服务之间传递消息的范式转变。

不过，我们需要了解，在 SOA 的保护下，Web 服务不仅仅是一个通用 API，它只是通过 HTTP 提供对其数据库的 CRUD 访问。虽然该实施在某些情况下可能有用，但它要求用户了解底层模型并遵守业务规则以确保您的数据完整性得到保护。SOA 意味着 Web 服务被设计为业务子域的有界上下文，从它们提供的概念服务中抽象实现。

从技术角度来看，SOA 不仅仅是一种服务架构，还是我们确保提供和使用正确服务所依据的策略、实践和框架。

Microsoft 2004，了解面向服务的体系结构

优点独立的技术栈，服务的部署和可扩展性；通用、简单且可靠的通信通道（通过 HTTP 的文本，端口 80）；优化沟通；稳定的通信规范；域上下文的隔离。缺点由于不同的通信语言，即难以集成不同的 Web 服务。使用相同概念的不同 JSON 表示的两个 Web 服务；同步通信会使系统过载。消息队列

核心思想是让多个应用程序在它们之间使用不可知消息进行异步通信。Message Queue 提高了应用程序之间的可伸缩性和更高的解耦性，因为它们不需要知道其他应用程序的位置、数量，甚至不需要知道它们是谁。尽管如此，它们都需要使用相同的通信语言，即预先确定的文本格式来表示数据。

消息队列使用消息代理软件（即 RabbitMQ、Beanstalkd、Kafka 等）作为基础设施人工制品，并且可以以不同的方式设置以实现应用程序之间的通信：

请求/回复客户端向消息队列发送消息，包括“会话”引用。消息被传送到一个特定的节点，该节点将用另一条消息回复给原始发送者，其中包含相同的 对话 引用，以便接收者知道 该消息指的是哪个对话，并可以继续该过程。它对于中长期运行的业务流程 ( sagas ) 非常有用。发布/订阅基于列表

它维护已发布主题和这些主题的订阅者的列表。当它接收到某个主题的消息时，它会将消息放入相应的主题列表中。将消息与主题匹配可以通过消息类型或一组更复杂的预定标准来完成，这些标准可以包括消息内容本身。基于广播

当它接收到消息时，它会将它们广播到正在侦听队列的所有节点。每个监听节点只负责过滤和处理它感兴趣的消息。

所有这些模式都可以在拉（又名 轮询）或推送方法中设置 ：

在pull 场景中，客户端将每隔X时间向队列请求一条消息。这样做的好处是客户端能够控制其负载，但也可能有引入延迟的缺点，即。当队列中有消息并且客户端不处理消息而只是等待轮询新消息的时刻时；在推送场景中，队列会在收到消息后立即将消息推送给客户端。这里的优点是没有延迟，但客户端不能自行管理他们的负载。优点独立的技术栈，服务的部署和可扩展性；通用、简单且可靠的通信通道（通过 HTTP 的文本，端口 80）；优化沟通；稳定的通信规范；域上下文的隔离；轻松连接和分离服务；异步通信有助于管理系统的负载。缺点由于不同的通信语言，即难以集成不同的 Web 服务。使用相同概念的不同 JSON 表示的两个 Web 服务；企业服务总线 (ESB)

在 1990 年代，在 Web 服务不断发展的同时，企业服务总线已经在使用它们（也许某些实现最初甚至使用 CORBA？）。

ESB 在公司拥有独立应用程序的环境中诞生，例如一个财务应用程序、一个人力资源应用程序、另一个库存管理应用程序等，他们需要让这些应用程序相互通信，他们需要整合它们。但是这些应用程序并没有考虑到集成，没有用于应用程序通信的通用语言格式（因为今天没有）。因此，合理的解决方案是应用程序供应商创建端点以特定格式发送和接收数据。然后，客户公司必须通过建立通信管道并将消息从一种应用程序语言翻译成另一种来集成应用程序。

Message Queue 可能有助于解决这个问题，但它仍然无法解决应用程序具有不同语言格式的问题。尽管如此，将 Message Queue 从一个愚蠢的通信通道转变为一个中间件只是一小步，它可以处理传递消息并将它们转换为接收方期望的语言/格式。ESB 是更简单的 Message Queue 的自然演变。

在这种架构类型中，我们有复合应用程序，通常是面向用户的，它们联系 Web 服务来执行某些操作。反过来，此 Web 服务也可以联系其他 Web 服务，最后，它们可能会将一些数据返回给复合应用程序。然而，复合应用程序和后端服务都不知道彼此的详细信息，即它们的位置或通信协议。他们所知道的是他们需要什么服务以及服务总线的位置。

因此，客户端应用程序（无论是服务还是复合应用程序）将其请求发送到服务总线，服务总线又将消息转换为目的地期望的格式并将请求路由到目的地。重要的是要注意所有通信都通过 ESB，这意味着如果 ESB 发生故障，所有通信都会发生故障并且所有系统都将无法运行。最后，ESB 就像中间件一样工作，其中会发生很多事情，使其成为高度复杂的人工制品。

当然，这是对什么是 ESB 架构的非常基本的解释。此外，虽然 ESB 是该架构中的主要构件，但还可能涉及其他构件，例如域代理、数据服务、流程编排服务或规则引擎。同样的架构模式也可以在联合设计中设置，其中系统在业务域中分离，每个业务域都有自己的 ESB 设置，所有这些设置都在它们之间连接。这有助于提高性能并减轻单点故障的问题，即。如果一个 ESB 发生故障，只会影响其业务领域。

ESB 的主要职责是：

监视和控制服务间消息交换的路由；解决通信服务组件之间消息的翻译；控制服务的部署和版本控制；元帅使用冗余服务；迎合商品服务，如事件处理、数据转换和映射、消息和事件排队和排序、安全或异常处理、协议转换和实施适当的通信服务质量；

在不同进程之间构建通信结构时，我们看到许多产品和方法都强调将重要的智慧融入通信机制本身。这方面的一个很好的例子是企业服务总线 (ESB)，其中 ESB 产品通常包括用于消息路由、编排、转换和应用业务规则的复杂设施。

Martin Fowler 2014， 微服务

这种架构模式具有优势，但我发现如果我们不“拥有”Web 服务并且因此需要一个中间件来转换它们之间的消息、编排涉及多个 Web 服务的业务流程等，它特别有用。

记住 ESB 实现已经发展，今天对于大多数用例，我们甚至可以使用简单的拖放 UI 来配置 ESB。

优点独立的技术栈，服务的部署和可扩展性；通用、简单且可靠的通信通道（通过 HTTP 的文本，端口 80）；优化沟通；稳定的通信规范；域上下文的隔离；轻松连接和分离服务；异步通信有助于管理系统的负载；版本控制和翻译管理的单点。缺点通信速度较慢，尤其是对于那些已经兼容的服务；集中逻辑：单点故障可能会导致企业中的所有通信中断；配置和维护复杂度高；ESB 最终可以包含业务规则；由于其复杂性，最终需要一个团队来管理它；服务变得高度依赖于 ESB。微服务

微服务架构以 SOA 概念为基础，并与 ESB 共享相同的全球目标：从多个更具体的业务领域应用程序创建一个全球企业应用程序。

关键区别在于，ESB 诞生于需要集成以实现企业范围的分布式应用程序的独立应用程序环境中，而微服务架构诞生于快节奏且不断变化的企业环境中（大部分）从头开始创建自己的云应用程序。

换句话说，出发点不同。对于 ESB，我们从我们不“拥有”的现有应用程序开始，因此我们无法更改它们。但是通过微服务，我们可以完全控制应用程序（这并不意味着系统中不能涉及任何第 3 方 Web 服务）。

构建/设计微服务的方式避免了对集成的高度需求。微服务应该特定于一个业务概念，一个有界上下文，它们应该保持自己的状态，这样它们就不会直接依赖于其他微服务，因此需要更少的集成。换句话说，微服务提供的低耦合和高内聚性具有减少集成需求的良好副作用。

[微服务是] 围绕业务领域建模的协同工作的小型自治服务。

Sam Newman 2015，微服务原理

由于 ESB 架构的最大缺点是所有其他应用程序都依赖于它的非常复杂和集中的应用程序，微服务架构通过几乎完全删除它来解决这个问题。

仍然有一些元素横切整个微服务生态系统，但它们不像 ESB 那样包含那么多职责。例如，还有一个用于微服务之间异步通信的消息队列，但它只是一个消息管道，没有其他职责。另一个例子是微服务生态系统网关，所有与外部的通信都通过它进行。

Building Microservices的作者 Sam Newman确定了微服务架构的 8 条原则：

服务围绕业务领域建模

因为它可以为我们提供围绕业务概念的稳定接口、非常内聚和解耦的代码单元以及明确标识的限界上下文；自动化文化

因为我们将有更多的移动部件和可部署单元；隐藏实现细节

允许一项服务独立于另一项服务发展；Decentralize all the things

去中心化决策权和架构概念，赋予团队自主权，使组织将自身转变为一个能够快速适应变化的复杂适应性系统；独立部署

这样我们就可以部署一个新版本的服务而不需要改变任何其他东西；消费者至上

一个服务应该易于消费，易于被其他服务使用；隔离故障

，即使一个服务出现故障，其他服务仍继续运行，使整个系统具有很高的故障恢复能力；高度可观察性

由于系统的部件数量多，了解所有事情的发生变得更加困难，所以我们需要复杂的监控工具，让我们知道系统的每个角落发生了什么，并了解任何连锁反应。

微服务社区倾向于另一种方法：智能端点和哑管道。从微服务构建的应用程序旨在尽可能地解耦和结合——它们拥有自己的域逻辑，并且更多地充当经典 Unix 意义上的过滤器——接收请求，适当地应用逻辑并产生响应。这些是使用简单的 RESTish 协议编排的，而不是复杂的协议，例如 WS-Choreography 或 BPEL 或中央工具编排。

Martin Fowler 2014， 微服务

优点独立的技术栈，服务的部署和可扩展性；通用、简单且可靠的通信通道（通过 HTTP 的文本，端口 80）；优化沟通；稳定的通信规范；域上下文的隔离；轻松连接和分离服务；异步通信有助于管理系统的负载；同步通信有助于管理系统的性能；真正独立自主的服务；服务之外没有业务逻辑；有可能将组织转变为一个 复杂的适应性系统，由几个能够快速适应业务变化的小型自治部分/团队组成。缺点高操作复杂性：需要对强大的 DevOps 文化进行大量投资；使用多种技术和库可能会失控；输入和输出 API 的更改必须小心管理，因为会有依赖这些接口的软件；最终一致性的使用具有重要意义，必须在开发应用程序时解决，从后端到 UX 层；测试变得更加复杂，因为接口更改可能会对其他服务产生不可预测的后果。反模式：馄饨架构

Ravioli Architecture是通常用来指代 微服务架构反模式的名称。当我们最终创建一个微服务生态系统时，就会发生这种情况，其中微服务太多、太小并且不能单独代表领域概念。

结论

SOA 在过去几十年中发生了很大变化，并且由于已实施解决方案的不足和技术进步，我们已经达到了微服务架构。

整个演变背后的想法一直是解决复杂问题的常用策略：将问题分解成更小的、可解决的部分。

当我们有一个整体时，也可以用相同的方式解决代码复杂性，将其分解为解耦的域组件（有界上下文）。但是，随着团队和代码库的增长，对独立进化、可扩展性和可部署性的需求也在增长。SOA 为这种独立性提供了工具，强制在有界上下文之间建立更严格的界限。

再一次，它是关于低耦合和高内聚的，这次的粒度比以前更粗。同样，以实用主义分析我们的需求也是最基本的：仅在我们真正需要时使用 SOA，因为它给组合带来了很多复杂性，如果我们确实需要使用 SOA，让我们创建规模和数量上的微服务真正满足我们的需求，不多也不少。