什么是面向服务的架构（SOA）？

面向服务的架构（SOA）是一种软件设计，可通过在网络上使用基于通用通信语言的服务接口，让软件组件可重复使用。

所谓服务，是指软件功能（或一组功能）的独立单元，其设计意图是完成特定的任务（例如检索指定信息或执行某项操作）。其中包含了执行完整、离散的业务功能所需的代码和数据集成，并且可以远程访问、进行交互或独立更新。

换句话说，SOA 集成了独立部署和维护的软件组件，并允许它们相互通信和协同工作，以构建一个跨不同系统的软件应用。

在 1990 年代末 SOA 投入使用之前，将应用连接到包含在另一个系统中的服务是一个很复杂的过程，涉及深层的点到点集成（连接性、路由、数据模型转换等），且开发人员必须针对每个新项目重新进行创建。这种模型被称为“单体式架构”，因为整个应用的代码都被构建到一个部署中。如果应用的某个方面无法正常运行，则必须将整个应用暂时脱机以进行修复，然后再作为新版本部署。

通过使用标准网络协议（如 SOAP、JSON、ActiveMQ 或 Apache Thrift）来开放服务以发送请求或访问数据，SOA 消除了开发人员必须从头开始进行集成的困扰。相反，开发人员可以使用被称为企业服务总线（ESB）的模式，在集中式组件与后端系统之间执行集成，然后将其用作服务接口。这也允许开发人员重用现有功能，而不是重复创造功能。

在面向服务的架构模式中，服务使用“松散耦合”系统进行通信。这是一种将系统或网络中的组件（也称为“元素”）进行互联的方式，其目的是在传递信息或协调业务流程的同时减少它们之间的依赖程度。这实际上创建了一个新应用。

• 更快的产品上市时间和更大的灵活性：服务的可复用性让组建应用变得更加容易和快捷，而不是像单体式应用那样每次都要从头开始。
• 在新的市场中使用传统基础架构：SOA 使开发人员更容易获取一个平台或环境的功能，然后将其扩展和延伸到新的平台或环境。
• 通过更高的敏捷性和更有效的开发来降低成本
• 便于维护：由于所有服务都是彼此独立、互不依存，因此可以根据需要对其进行修改和更新，而不会影响其他服务。
• 可扩展性：由于 SOA 允许服务跨多种服务、平台和编程语言运行，因此极大地提高了可扩展性。SOA 采用的是标准通信协议，这让企业减少了客户端与服务之间的交互。减少这一级的交互可以降低应用扩展的压力，同时提高扩展的便利性。
• 更可靠：由于调试小型服务要比调试大量代码更加容易，因此 SOA 生成的应用更加可靠。
• 便利性：任何人都可以使用 SOA 设施。

面向服务的架构的构建模块是由 3 个角色组成的。

1. 服务供应商

   服务供应商创建 Web 服务并将其提供给服务注册表。服务供应商对服务的使用条款负责。

2. 服务代理或服务注册表

   服务代理或服务注册表负责向请求者提供有关服务的信息。代理可以是公共的或私有的。

3. 服务请求者或服务消费者

   服务请求者在服务代理或服务注册表发现服务，然后连接服务供应商以接受服务。

面向服务的体系架构所带来的服务概念已成为现代云计算和虚拟化的核心组成部分，比如中间件和微服务等项目。

由于它们的相似性，人们经常将 SOA 和微服务架构相混淆。二者的主要区别是它们的范围：SOA 是一种企业级的架构方案，而微服务则是应用开发团队的一种实施策略。

此外，它们与各自组件进行通信的方式也有所不同：SOA 使用 ESB，而微服务则可以通过与语言无关的 API 彼此进行无状态通信。不仅如此，微服务中与语言无关的 API 还允许开发团队选择自己想用的工具。凡此种种，让微服务变得生存力更强，也更加灵活。

人们有时也将 SOA 和软件即服务相混淆。SaaS 是一种云计算形式，可为用户提供云应用及其所有的底层 IT 基础架构和平台。SOA 中的 Web 服务可以由服务供应商作为 SaaS 应用交付。通常，云服务提供商（如 AWS、Azure 或 IBM 云）管理托管 SaaS 应用的云环境。

用户在其计算机或移动设备上通过 Web 浏览器与软件交互。他们可能使用诸如 REST 或 SOAP 等 API 将软件连接至其他功能。

得益于容器技术的进步，微服务已成为云原生应用（松散耦合，部署在 Linux 容器中，并通过 API 或网格网络进行连接以实现消息路由的微服务）的基础。

每个组成部分都由小型 DevOps 团队通过持续集成和持续部署 (CI/CD) 等工作流程独立开发，会实现一项业务功能。这就意味着我们可以实现快速软件开发、自动部署和定期更新，不再受限于单体式开发周期。

借助自己的开源产品组合（包括红帽^®企业 Linux^® 和红帽 OpenShift），红帽可以与希望将其基础架构和应用开发逐步迁移到快捷且适应性强的云计算环境，同时仍能从现有基础架构中获得最大收益的企业开展合作。