什么是企业服务总线 （ESB）？

集成。这是一件让 IT 和应用程序开发团队整天忙碌的苦差事。在成长型企业中，新的业务需求和对第三方系统的日益依赖是一种标准规范。因此，对于这些团队来说，集成不同的系统和应用程序是一个永无止境的挑战。企业服务总线 （ESB） 代表了为解决此问题而设计的早期方法之一。

这篇博客文章是关于 ESB 概念的简短论文，涵盖了它的动机、应用程序、用例及其优缺点。

什么是企业服务总线 （ESB）？

在过去的几十年中，出现了几种架构模式，以减轻在企业内集成不同系统的痛苦。客户端-服务器体系结构 （CSA） 是最早的方法之一。它很简单，但缺乏可扩展性。紧随其后的是面向服务的体系结构 （SOA），它将业务逻辑拆分为定义良好的协作服务。ESB 被设想为 SOA 中的一个中间件层，用于促进这种合作。

ESB 的设计模仿了计算机硬件体系结构中的硬件总线，该总线充当多个外围设备之间的通信桥梁。从正确的角度来看，ESB 充当服务之间的稳定通信总线。它不是一个标准或有形的产品，而是一种架构和沟通模式。它提供了一个概念蓝图，其中包含一组准则，用于通过确保充分解耦来协调和中介表示业务服务的软件组件。

SB 的用例

ESB 被设想为 SOA 的一个内部组件。因此，对于最终用户来说，它是一个看不见的黑匣子。与 ESB 交互的唯一角色是应用程序开发人员和 IT 工程师。

应用程序开发人员负责定义他们开发的服务的接口。这些接口成为其他服务通过 ESB 与它们进行通信的服务接入点。IT 工程师负责部署、维护和监视 ESB 基础结构，以确保在附加越来越多的服务时达到最佳性能。

如果您查看一家具有少量服务和应用程序的小型公司的IT部署，则客户端 – 服务器或对等通信模型可以达到目的。但是，在大型企业中，事情变得太复杂太快。ESB 的优点在此类场合脱颖而出，以处理与以下方面相关的复杂性：

1. 集成多个服务：集成应用程序上的多个服务时，存在高度依赖性。在代码实现级别镜像这种依赖关系会导致严重的问题，例如业务逻辑或意大利面条式代码的纠缠。ESB 通过简化集成、提供可靠、安全且通常即时的连接来解决此问题。
2. 与外部服务的集成：在需要与外部服务接口的情况下，ESB 提供可靠的连接，同时管理和控制服务级别承诺，以最大程度地减少对服务协议进行调整的影响。
3. 协议和消息转换：ESB特别擅长将多个协议转换为一个协议，例如FTP和HTTP转换为SOAP或将SMTP，IIOP，MQ / JMS编织在一起。同样，消息转换是 ESB 最重要的功能之一。它用于使用 XPath 和 XSLT 等标准将消息从一种格式转换为另一种格式。
4. 集成旧版应用程序：ESB 在集成旧版应用程序时非常有用。它们包括各种预构建的适配器，用于将旧版应用程序与现代应用程序和服务集成。

ESB 和完成技术的替代方案

在两个或多个应用程序之间提供无缝通信的挑战并不新鲜。多年来，已经提出了许多标准，并建立了专有应用程序和协议。ESB 的发展与基于 SOA 的企业应用程序部署趋势保持一致，这些趋势几乎可以追溯到万维网的曙光。因此，它早于当前的云时代技术。

虽然EBS可能被视为过时，但它仍然与IT集成和数字化转型有关。但是，随着新一代技术的出现，必须进行类比以阐明 ESB 的优点和局限性。

ESB 与服务网格 – 服务网格与微服务体系结构 （MSA） 的当前趋势更相关，MSA 使用容器使用云本机技术定义更细粒度的服务编排。在较高级别上，ESB 实现了与服务网格相同的功能。但是，它主要是作为一组整体式应用程序组件构建的。在过去几年中，出现了利用云的混合部署模型。因此，ESB 和服务网格之间的界限现在变得模糊不清。

ESB 与集成平台即服务 （iPaaS）：iPaaS 是一套云服务，支持开发、执行和治理集成流，这些集成流连接单个或跨多个组织内的本地和基于云的流程、服务、应用程序和数据的任意组合。它是一个用于在云中以及云与企业之间构建和部署集成的平台。从功能上讲，ESB 和 iPaaS 都提供了相同的解决方案。与整体式 ESB 相比，iPaaS 更便宜，而且扩展起来也更灵活。在某些情况下，ESB 是首选，例如支持支持对敏感公司数据进行安全管理的旧式流程密集型软件系统。

ESB 与 Pub/Sub：Pub/Sub 是一个通用概念。它是一种抽象的通信模式，用于构建需要解耦消息传递中间件的 Internet 规模的应用程序。它可以被认为是 ESB 的子系统，因为 ESB 还需要服务之间的非耦合消息传递层。但是，Pub/Sub 是一个理论概念，与 ESB 不同。

ESB vs. Apache Kafka – Apache Kafka是一个真正的产品。它最初是在LinkedIn中构思的，由于其大规模处理系统间消息传递的独特方式，它在过去十年中获得了巨大的普及。您可以将 Apache Kafka 视为抽象 Pub/Sub 模式的实际实现。与 ESB 相比，Apache Kafka 的责任范围更小，仅限于消息交换。

ESB 与 ETL：ETL（提取、转换、加载）是一种数据管道，主要用作机器学习模型执行的数据预处理阶段的一部分。它主要是一个线性过程，其中数据从一侧馈送并从另一侧检索。因此，它是一个与 ESB 完全不同的概念。

ESB 的组件

由于缺乏任何标准化，ESB 的统一体系结构不可用。不同的供应商有将 ESB 系统分离到其子系统中的方法。因此，将一组标准组件拼凑在一起以在供应商之间呈现一致的体系结构并不容易。

考虑到 SOA 支持者所设想的功能，以下是 ESB 的关键组件。

1. 代理：与任何编排层一样，ESB 遵循中心辐射型通信模型。中心组件充当集线器。发言人包括服务生产者和消费者。根据可伸缩性要求，还可以使用多层中心模型。但是，请注意，这只是通信的逻辑层次结构。它与星形拓扑不同，在星形拓扑中，多个分支在物理上连接到中央集线器。代理的主要功能是管理参与服务之间的订阅和消息路由。
2. 消息传递服务：ESB 依赖于消息传递系统。它传输已发布的消息，并通过以队列的形式模拟硬件总线来工作。消息传递组件创建多个传入和传出队列，并遵循轮询机制在队列之间交换消息，以传递消息，直到它们到达其目标终结点。
3. 中介：ESB 旨在与多个服务（包括内部和第三方应用程序）进行互操作。因此，确保所有参与服务的神圣性至关重要。中介组件通过一组预定义的检查来实现此目的，以对服务和服务订阅进行身份验证和授权。ESB 中可能存在多个中介器组件，以处理额外的审计职责并管理 ESB 的整体安全性方面。
4. 适配器：如前所述，协议和消息转换是 ESB 与外部服务接口的关键要求。适配器提供此功能。多个基于软件的适配器组件使用一致的格式（如 XML）执行特定功能，例如与 ESB 之间的消息格式转换。

ESB 的未来

作为老一代技术的一部分，ESB的角色在很大程度上已被较新的架构框架所取代。但是，遗留应用程序在 SOA 模型上运行，其中 ESB 仍然运行良好。只要这些应用程序不进行技术更新，ESB 就会发挥关键作用。

虽然公平地说，ESB将在未来几年见证日落，但它在塑造分布式计算的新架构模型方面的影响不容忽视。作为 ESB 的一部分，用于处理服务间通信的概念和机制在当前的云时代仍然适用。因此，说服务网格和iPaaS等当前一代概念站在名为ESB的巨人的肩膀上是没有错的。

Last Updated on 2022-07-12 by admin