ESB 通常会提供多少业务逻辑/抽象

Question

我正在查看指定 ESB 的客户需求（非常详细）。我不是专业的开发人员，我倾向于担任产品负责人类型的角色，但 ESB 是一个我以前从未真正掌握过的术语。谷歌搜索显示，它更像是一种架构风格，而不是特定组件，提供各种数据传输和翻译服务以允许不同的应用程序松散耦合。

我想就 ESB 可能包含的内容获得一些专家意见。例如，如果我有一堆应用程序，其中许多应用程序具有从另一个应用程序接收“命令”的概念，但每个应用程序具有不同的协议和内容，那么 ESB 可能会提供一个通用的“发送命令”方法，使用通用语法访问一系列协议？本质上是跨应用程序提供高级 API？这些方法可能包括业务逻辑（例如优先发送哪些命令、根据当前操作条件拒绝命令等？）

ESB 通常会保存状态信息还是更短暂？例如，如果某些应用程序定期报告状态，是否可以将其保存在总线中以供其他应用程序检索（或者将其视为使用 ESB 的持久性应用程序）？我读过 ESB 通常包含消息功能，所以我猜是的，但我在这里所追求的是典型的开发人员或架构师认为的典型 ESB 功能，以便指导我如何解释需求​​和什么问题问我何时与我们自己的建筑师交谈。感谢这是相当广泛的，但希望足以被认为是一个可以接受的问题。

Answer 1

由于您有一个广泛的问题，我想为您提供一个概述，并从您发布的内容中挑选一些您的问题。希望这些信息对您有所帮助。

ESB 可能包括哪些内容？

ESB 允许业务信息在跨多个硬件和软件平台的不同应用程序之间流动。 ESB 更像是一个中间件层，它包含应用程序连接逻辑和最小的业务逻辑。这允许应用程序做它最擅长的事情，而不必担心嵌入任何连接逻辑来与需要来自它的数据的其他 N 个应用程序交互。 ESB 架构试图解决企业中的点对点意大利面混乱。

下面列出了 ESB 的许多重要功能：

Data transformation : For example, XML to JSON format or JSON to CSV format

Protocol transformation : For example, FTP to HTTPS 

Enrichment : Data passing through ESB layer could be enriched before delivery to destination

Routing : Based on payload or pre-determined rules, route data to appropriate destination

下面的 wiki 页面给出了 ESB 的详细描述，包括 ESB 名称的由来。 https://en.wikipedia.org/wiki/Enterprise_service_bus

ESB 通常会保存状态信息还是更短暂？

理想情况下，ESB 不应保存任何状态信息。特别是，现在所有 ESB 供应商都在从单体 ESB 部署转向基于微服务的部署。企业有一个单独的消息传递层来临时排队数据。消息传递允许您的应用程序解耦。例如，当 App A 想与 App B 通话时，App B 必须在线。但是，如果 App A 可以在消息传递层中丢弃消息，那么在这种情况下，App B 不需要等待来自 App A 的消息。它可以在准备好时从消息传递层中提取数据。自己的节奏。这样，App A 和 App B 就相互解耦了。您可以通过以下有关消息和队列的链接 => https://en.wikipedia.org/wiki/Message_queuing_service

您可能应该开始了解企业中当前的应用程序格局以及应用程序如何相互交互。由于您的帖子中已经提到了 ESB，因此请讨论通过集成层（ESB 是其中的一个组件）对数据的可见性。例如，假设应用程序 A 推送数据，而应用程序 B 抱怨没有收到来自最终业务用户的数据，那么在联系应用程序支持团队之前，他如何进行调查。此外，您可能想了解 ESB 的治理方面。

Answer 2

您在这里提出了一个非常广泛的问题，其中充满了您的特定架构师可能不会持有的意见和最佳实践。这里给出的任何建议都注定过于宽泛，通常只会让你与你的建筑师争论。

与您的架构师进行对话会比与 StackOverflow 进行对话要好得多。该免责声明，请从MuleSoft 阅读本文。它很好地概述了 ESB 的一般功能和用途。这需要考虑到您的组织可能以不同方式使用它的事实。 ESB 是一种工具，它适合您的环境的地方可能并不适合其他组织的环境。

您所询问的事情都可以通过 ESB 完成，是否应该完成取决于您的架构师如何设计解决方案。继续阅读这篇文章，然后与您的架构师就您的组织中如何使用这项技术进行开诚布公的对话。