有人可以用非流行语向我解释企业服务总线吗？

Posted 2023-02-16

【中文标题】有人可以用非流行语向我解释企业服务总线吗？

【英文标题】：Can someone explain an Enterprise Service Bus to me in non-buzzspeak?

【发布时间】：2011-03-04 14:22:24

【问题描述】：

我们的一些合作伙伴告诉我们，我们的软件需要与企业服务总线交互。在对此进行了一些研究之后，我的直觉是，这只是在说我们需要一种独立于平台的方式来来回传递消息。我只是想了解我们的合作伙伴告诉我们的内容。我是否正确地驳回了我们合作伙伴的请求，因为他们只是试图让我们的软件更符合流行语，或者他们告诉我们应该听什么（即使是用流行语编码）？

【问题讨论】：

您现在使用哪些技术进行消息路由和事件触发，哪些没有？

ESB 是异步消息传递的流行语，通常通过一些消息队列系统，这在大多数“企业”产品中意味着高延迟以及高配置和维护问题，具体取决于您选择使用的 ESB 实现.

我们的雇主和客户在 ESB 技术上投入了大量资金，我对最高评价的回答说它只是空谈并不感到兴奋。我觉得奇怪的是，没有将 ESB 视为流行词的两个答案既没有浮到顶部也没有被接受。我提供赏金，看看它是否会产生更好的答案，或者我认为对现有答案来说会产生更好的结果。

【参考方案1】：

虽然 ESB 是基于消息传递的，但它不仅仅是“消息传递”，也不仅仅是一个流行语。

因此，如果您从简单的老式异步消息传递开始，早期的网络往往是非常点对点的。你必须连接（即通过一些管理界面配置）每个连接和每对目的地，如果你敢于移动任何东西，总是会坏掉。由于连接点是手工连接的，因此这些网络从未达到高连接密度。增量成本太高，无法扩展。拓扑中还嵌入了许多访问控制和策略。缺乏连接密度实际上有利于这种安全方法，尽管它会抑制灵活性。

ESB 试图通过...解决这些问题

目标/服务/资源的运行时解析 位置透明度 Any-to-any 连接和最大连接密度 专为冗余、水平可扩展性、故障转移而设计 从拓扑外部化的策略、访问控制、规则 在物理消息网络层之上实现的逻辑消息网络层 通用命名空间

因此，当您的客户要求 ESB 兼容性时，他们想要上述内容。从应用程序的角度来看，这也意味着......

避免消息相关性，例如要求以严格的顺序处理或仅将请求发送到特定节点而不是通用网络目标 能够在运行时动态解析目标（即添加另一个队列实例，它会自动开始获取流量、删除一个并将流量路由到其余节点） 请求者和提供者应用程序与了解彼此的“生活”位置分离。请求者建立一个连接，无论它可能需要调用多少服务 按策略而非拓扑进行授权 能够识别和处理欺骗的服务提供者应用程序（根据 JMS 规范，请参阅“由于会话处理而导致的功能重复”） 能够运行服务提供商应用程序的多个活动实例 检测服务提供商应用程序，以便您可以在不发送实际交易的情况下查询网络状态或执行测试

另一方面，如果您的客户无法清楚地表达这些内容，那么他​​们可能只想选中“与 ESB 一起工作”的复选框。

【讨论】：

+1 非常丰富的答案。我想补充一点（从我的非专家观点），公司的 IT 基础架构越大、越复杂，ESB 的价值就越大。管理数千个连接与管理几十个连接完全不同。

【参考方案2】：

我会尽量保持它不受流行语的影响（但可能会出现流行语的首字母缩写词）。

当服务/应用程序/大型机/等...想要集成时（因此相互发送消息），您最终可能会变得一团糟。 ESB 将混乱隐藏在自身（或自身）内部，以便组织可以假装没有混乱并且它有一些可管理的东西。然后，它围绕这个包装了一大堆功能，使这个盒子对组织中决定购买如此昂贵产品的高级人员更具吸引力。这些人通常会想要引入一项花费大量资金的大型计划，以证明他们正在“做某事”并且知道如何花费大量资金。如果这是一项 SOA 计划，那么各种供应商都会告诉他们，需要 ESB 才能让供应商了解 SOA 的工作原理（通常是在他们可能想要的服务数量超过一个微不足道的数字时）。

所以 ESB 是：

供应商赚钱的工具； 顾问赚大钱的工具； 高级管理人员（IT 主管等）展示他们可以花很多钱的方式； 一个用来隐藏乱七八糟的盒子； 可供技术团队合作的完整 PITA。

【讨论】：

而尖刻的答案迅速上升。 :-/ 很难说这是真诚的还是半开玩笑的，但无论哪种方式，我都希望得到一个答案，为那些最终从事 ESB 项目的人提供一些指导，无论好坏，并且这不是。我并不是说这里的任何事情都是不真实的（喝几杯酒会很有趣），只是对于需要加快速度并产生一些结果的人来说，这并不是非常有成效的。

很抱歉，如果它显得刻薄。这不是故意的。根据我在采用这些产品的组织和产品的工作经验，我发现这些和其他事情对我来说是正确的。 OP，我关注的问题似乎对这样的请求是否应该作为符合流行语的请求而被驳回感兴趣。我的观点，也许我应该更具体和明确地转达，是它可以，但作为供应商的营销角度，它确实有价值，如果不是在道德意义上。

再次阅读这个问题，我认为没有提供足够的细节来了解 OPs 产品是否会从互操作性中受益，但是，如果互操作性很有价值，那么关注 ESB 兼容性可能是一个无益的观点.相反，任何互操作策略的选择都应考虑预期的互操作场景（频率/延迟/消息大小/等）。这可能会导致不同的方法，从基于 db 的集成到 REST，再到基于 MQ 的事件，再到同步 SOAP 等等……任何 ESB 都应该能够使用其中的任何一个。价值支撑留给客户在他们的上下文中考虑。

【参考方案3】：

经过一番研究，我的 本能是说这只是 嗡嗡声说我们需要 有一种独立于平台的传递方式 来回消息

你是对的，部分原因是 ESB 这个词总是很好的词，它与另一个流行词很吻合，无论合法与否——即 治理（即帮助你管理 谁在访问你的端点 和报告 metrics - Metrics btw 是所有西装都喜欢看到的，所以这可能是贡献者）

他们可能想要平台中立设备的另一个原因是，他们使用的任何服务始终作为来自中心位置的端点公开，而不是特定的机器资源。 ESB 使您的服务的实际物理端点与它们无关，无论如何它们不应该太在意，但这使您可以移动服务，但它们只会使用 ESB 端点。 p>

除了 Discovery 的集中存储库之外，ESB 还使服务的并行版本控制更加容易。如果我有选择并且我的公司有预算，我们会购买 IBM 的 x150 设备:(

第三，很多更高级的总线，如果我记得的话，比如 SoftwareAG 的产品，本身就能够公开遗留数据，比如来自主机上的数据作为服务，而无需通过适配器进行编码

我不知道他们的意图是利用 ESB 提供的所有好处，还是如您所说，使其符合流行语。

【参考方案4】：

在对此进行了一些研究之后，我的直觉是，这只是在说我们需要一种独立于平台的方式来来回传递消息

差不多是这样。有时，ESB 会走得更远，并包括附加功能，如消息传递保证、确认/确认消息等。 ESB 的存在通常也会显式或隐式地创建一个以前不存在的新协议，这是另一个重要的考虑因素。 （也就是说，必须针对消息的格式设置某种标准或接口。）

我是否正确地驳回了我们合作伙伴的请求，因为他们只是试图让我们的软件更符合流行语，还是他们告诉我们应该听什么（即使是用流行语编码）？

您应该始终倾听客户的意见，即使最初听起来很傻。通常至少值得花费精力来决定发生了什么。从字里行间看，您的合作伙伴可能的意思是，他们希望您的服务能够更轻松地与他们自己的服务和产品集成。

【参考方案5】：

企业服务总线以标准方式处理系统之间的消息传递。这允许您在所有平台上以完全相同的方式与总线通信，并且总线处理实际转换为特定端点所需的单个通信机制。这意味着您编写所有代码以使用通用消息传递方案与总线通信，并且总线处理采用您的通用方案并对其进行翻译，以便端点能够理解它。

【参考方案6】：

最简单的解释是解释它提供了什么：

多年来，公司收购了不同的平台和技术来实现其业务中从财务到人力资源的特定功能。这些系统需要相互通信以共享数据，因此中间件成为允许它们连接的粘合剂。在企业知道之前，他们为这些系统和中间件中的每一个的支持和维护付费。随着业务需求的变化，各部门决定创建自己的定制解决方案来解决特殊需求，而不是尝试使老化的解决方案足够灵活以满足他们的需求。不知不觉中，他们就为支持和维护遗留系统、中间件和定制解决方案付费。有了像 Sarbanes Oxley 这样的新法律，公司需要有更好的信息用于报告目的。单一视图要求它们从所有系统中捕获数据。此外，CIO 现在面临着降低成本和增加客户服务的压力。一种明显的解决方案是消除冗余系统、昂贵的支持和维护合同以及需要专家支持的高成本遗留解决方案。迁移到新平台可以实现这一点，但需要进行过渡。没有可以复制业务的交钥匙解决方案。为了满足移动信息的需求，他们使用 SOA，因为它允许通过通用实体访问信息。如果我从服务总线询问 AllEmployees，它会从 15 个 HR 系统还是 1 个系统中获取它们。当 15 个 HR 系统变为 1 个系统时，调用和结果不会改变，只是在幕后完成的。服务总线概念标准化了信息流，并允许 IT 经理在总线后面进行转换，而不会对上游用户产生长期影响。