Mulesoft 简明教程
MuleSoft - Introduction to Mule ESB
ESB 表示 Enterprise Service Bus ，它基本上是一个中间件工具，用于通过类似于总线的架构将各种应用程序集成在一起。从根本上说，它是一种设计，用于为集成应用程序之间的工作移动提供统一的手段。通过这种方式，在 ESB 架构的帮助下，我们可以通过通信总线连接不同的应用程序，并使它们能够在不相互依赖的情况下进行通信。
Implementing ESB
ESB 架构的主要重点是将系统彼此解耦，并允许它们以稳定且可控的方式进行通信。ESB 的实现可以通过以下方式借助 ‘Bus’ 和 ‘Adapter’ 来完成：
-
通过 JMS 或 AMQP 等消息传递服务器实现的“总线”概念用于将不同的应用程序相互解耦。
-
负责与后端应用程序进行通信并将数据从应用程序格式转换为总线格式的“适配器”概念用于应用程序和总线之间。
通过总线从一个应用程序传递到另一个应用程序的数据或消息采用规范格式，这意味着将有一个一致的消息格式。
适配器还可以执行其他活动，如安全、监视、错误处理和消息路由管理。
ESB’s Guiding Principles
我们可以将这些原则称为核心集成原则。它们如下：
-
Orchestration - 集成两个或多个服务以实现数据和过程之间的同步。
-
Transformation - 将数据从规范格式转换为特定于应用程序的格式。
-
Transportation - 处理 FTP、HTTP、JMS 等格式之间的协议协商。
-
Mediation − 提供多重接口以支持服务的多个版本。
-
Non-functional consistency − 提供用于管理事务和安全性的机制。
Need of ESB
ESB 架构使我们能够集成不同的应用程序，其中每个应用程序都可以通过它来通信。以下是在何时使用 ESB 的一些指南 −
-
Integrating two or more applications − 当需要集成两个或更多个服务或应用程序时，使用 ESB 架构是有益的。
-
Integration of more applications in future − 假设如果将来我们想要添加更多服务或应用程序，那么借助 ESB 架构可以轻松完成。
-
Using multiple protocols − 万一我们需要使用多个协议，如 HTTP、FTP、JMS 等，那么 ESB 是正确选择。
-
Message routing − 如果我们需要基于消息内容和其他类似参数进行消息路由，那么我们可以使用 ESB。
-
Composition and consumption − 如果我们需要发布服务供组合和消费，那么可以使用 ESB。
P2P integration vs. ESB integration
随着应用程序数量的增加，摆在开发人员面前的一个大问题是，如何连接不同的应用程序？这种情况可以通过手动编写各种应用程序之间的连接来处理。这称为 point-to-point integration 。
Rigidity 是点对点集成的最明显的缺点。连接和接口的数量越多，复杂性也会越大。P-2-P 集成的缺点导致了我们使用 ESB 集成。
ESB 是用于实现应用程序集成的更灵活的方式。它将每个应用程序功能封装并公开为一组离散的可重用功能。没有任何应用程序直接与其他应用程序集成，取而代之的是通过 ESB 来集成，如下所示 −
为了管理集成，ESB 具有以下两个组件 −
-
Service Registry − Mule ESB 具有服务注册表/存储库，其中公开到 ESB 中的所有服务都已发布并注册。它充当一个从其它应用程序中消费服务和功能的发现点。
-
Centralized Administration − 正如名称所示，它提供了在 ESB 内发生的交互性能的事务流程视图。
ESB Functionality − VETRO 缩写通常用于总结 ESB 的功能。具体如下 −
-
V (验证) − 正如名称所示，它会验证架构验证。它需要一个验证解析器和最新架构。XML 文档符合最新架构就是其中一个示例。
-
E (丰富) − 它向消息中添加了额外的数据。其目的是使消息对目标服务更有意义并且更有用。
-
T (转换) − 它将数据结构转换成规范化格式，或从规范化格式转换成其它格式。示例包括日期/时间、货币等的转换。
-
*R(*路由) − 它会路由消息，充当服务端点的守门员。
-
O （操作）−此功能的主要工作是调用目标服务或与目标应用程序交互。它们在后端运行。
VETRO 模式为集成提供了整体灵活性，并确保只有经过验证一致的数据才能在整个 ESB 中路由。