SQL注入攻击深度解析与防护策略
什么是企业服务总线 (ESB)?
一体化是一项让 IT 和应用程序开发团队整天忙碌的繁重工作。在成长型企业中,新的业务需求和对第三方系统的日益依赖是一种标准规范。因此,集成不同的系统和应用程序对于这些团队来说是永无休止的挑战。企业服务总线 (ESB) 是为解决此问题而设计的早期方法之一。
这篇博文是关于 ESB 概念的简短论述,涵盖其动机、应用程序、用例及其优缺点。
什么是企业服务总线 (ESB)?
过去几十年中出现了多种架构模式,以减轻在企业内集成不同系统的痛苦。客户端-服务器架构(CSA)是最早的方法之一。它很简单,但缺乏可扩展性。随后是面向服务的架构(SOA),它将业务逻辑分解为定义良好的协作服务。 ESB 被认为是 SOA 内的中间件层,用于促进这种合作。
ESB 的设计模仿了计算机硬件架构中的硬件总线,充当多个外围设备之间的通信桥梁。从长远来看,ESB 充当服务之间稳定的通信总线。它不是一个标准或有形产品,而是一种架构和通信模式。它提供了一个概念蓝图,其中包含一组通过确保充分解耦来在代表业务服务的软件组件之间进行编排和调解的指南。
ESB 的用例
ESB 被设想为 SOA 的内部组件。因此对于最终用户来说,它是一个看不见的黑匣子。与 ESB 交互的唯一角色是应用程序开发人员和 IT 工程师。
应用程序开发人员负责定义他们开发的服务的接口。这些接口成为其他服务通过 ESB 与它们通信的服务访问点。 IT 工程师负责部署、维护和监控 ESB 基础设施,以确保其附带的服务数量不断增加时达到最佳性能。
如果您查看一家拥有少量服务和应用程序的小公司的 IT 部署,那么客户端-服务器或点对点通信模型就可以满足您的需要。然而,在大型企业中,事情变得太复杂太快了。在这种情况下,ESB 的优点在处理与以下相关的复杂性时脱颖而出:
- 集成多个服务:当一个应用程序上的多个服务集成时,存在很高的依赖性。在代码实现级别反映这种依赖性会导致严重的问题,例如业务逻辑的纠缠或意大利面条式代码。 ESB 通过简化集成、提供可靠、安全且通常是即时的连接来解决这个问题。
- 与外部服务集成:当需要与外部服务连接时,ESB 提供可靠的连接,同时管理和控制服务级别承诺,以最大限度地减少服务协议调整的影响。
- 协议和消息转换: ESB 特别擅长将多种协议转换为一种协议,例如将 FTP 和 HTTP 转换为 SOAP,或者将 SMTP、IIOP、MQ/JMS 编织在一起。同样,消息转换是 ESB 最重要的功能之一。它用于使用 XPath 和 XSLT 等标准将消息从一种格式转换为另一种格式。
- 集成遗留应用程序:ESB 在集成遗留应用程序方面非常有用。它们包括各种预构建的适配器,用于将遗留应用程序与现代应用程序和服务集成。
ESB 的替代方案和完善技术
在两个或多个应用程序之间提供无缝通信的挑战并不新鲜。多年来,人们提出了许多标准,并建立了专有应用程序和协议。 ESB 的发展与基于 SOA 的企业应用程序部署趋势相一致,这种趋势几乎可以追溯到万维网诞生之初。因此它早于当前的云时代技术。
尽管 EBS 可能被认为已经过时,但它仍然与 IT 集成和数字化转型相关。然而,随着新一代技术的出现,有必要进行比较以阐明 ESB 的优点和局限性。
ESB 与服务网格– 服务网格与微服务架构 (MSA) 的当前趋势更相关,微服务架构使用容器通过云原生技术定义更细粒度的服务编排。在较高层面上,ESB 实现了与服务网格相同的功能。然而,它主要是作为一组整体的应用程序组件构建的。在过去几年中,出现了利用云的混合部署模型。因此,ESB 和服务网格之间的界限现在变得模糊。
ESB 与集成平台即服务 (iPaaS) :iPaaS 是一套云服务,支持集成流程的开发、执行和治理,将本地和基于云的流程、服务、应用程序和数据的任意组合连接起来或跨多个组织。它是一个用于在云内以及云与企业之间构建和部署集成的平台。从功能上讲,ESB 和 iPaaS 提供相同的解决方案。与整体 ESB 相比,iPaaS 成本更低且扩展更灵活。在某些情况下,ESB 是首选,例如支持传统的、流程繁重的软件系统,这些系统支撑敏感公司数据的安全管理。
ESB 与 Pub/Sub :Pub/Sub 是一个通用概念。它是一种抽象通信模式,用于构建需要解耦消息中间件的互联网规模应用程序。它可以被视为 ESB 的子系统,因为 ESB 还需要服务之间的解耦消息传递层。然而,与 ESB 不同,Pub/Sub 是一个理论概念。
ESB 与 Apache Kafka – Apache Kafka 是一个真正的产品。它最初是在 Linkedin 内构思的,由于其大规模处理系统间消息传递的独特方式,在过去十年中获得了巨大的受欢迎。您可以将 Apache Kafka 视为抽象 Pub/Sub 模式的现实实现。与 ESB 相比,Apache Kafka 的职责范围较小,仅限于消息交换。
ESB 与 ETL :ETL(提取、转换、加载)是一种数据管道,主要用作机器学习模型执行的数据预处理阶段的一部分。 它主要是一个线性过程,其中数据从一侧馈送并从另一侧检索。因此,它是与 ESB 完全不同的概念。
ESB 的组成部分
由于缺乏标准化,ESB 没有统一的架构。不同的供应商有自己的方法将 ESB 系统划分为其子系统。因此,将一组标准组件组合在一起以呈现跨供应商的一致架构并不容易。
考虑到 SOA 支持者设想的功能,以下是 ESB 的关键组件。
- Broker :与任何编排层一样,ESB 遵循中心辐射模型的通信。中央组件充当枢纽。辐条由服务生产者和消费者组成。根据可扩展性要求,多层集线器模型也是可能的。但是,请注意,这只是通信的逻辑层次结构。它与星形拓扑不同,星形拓扑中多个辐条物理连接到中央集线器。代理的主要功能是管理参与服务之间的订阅和消息路由。
- 消息传递服务:ESB 依赖于消息传递系统。它传输已发布的消息,并通过以队列的形式模拟硬件总线来工作。消息传递组件创建多个传入和传出队列,并遵循轮询机制在队列之间交换消息以传递它们,直到它们到达目的地端点。
- 中介者:ESB 旨在与多种服务进行互操作,包括内部和第三方应用程序。因此,确保所有参与服务的神圣性至关重要。中介组件通过一组预定义的检查来对服务和服务订阅进行身份验证和授权来实现此目的。 ESB 中可能存在多个中介组件,以处理额外的审计职责并管理 ESB 的整体安全方面。
- 适配器:如前所述,协议和消息转换是 ESB 与外部服务交互的关键要求。适配器提供此功能。多个基于软件的适配器组件使用一致的格式(例如 XML)执行特定功能,例如与 ESB 之间的消息格式转换。
ESB 的未来
作为老一代技术的一部分,ESB 的作用很大程度上已被更新的架构框架所取代。然而,遗留应用程序运行在 SOA 模型上,ESB 仍然可以很好地发挥作用。只要这些应用程序不进行技术更新,ESB 就会发挥关键作用。
虽然可以公平地说,ESB 将在未来几年内走向衰落,但它在塑造分布式计算的新架构模型方面的影响不容忽视。作为 ESB 的一部分提出的用于处理服务间通信的概念和机制在当前的云时代仍然有效。因此,可以说,当前这一代概念,如Service Mesh、iPaaS,是站在ESB这个巨人的肩膀上。