有人能用非专业术语向我解释一下企业服务总线吗?

33

我们的一些合作伙伴告诉我们,我们的软件需要与企业服务总线进行交互。经过一些研究后,我的直觉告诉我,这只是说我们需要一种平台无关的方式来传递消息而已,这些合作伙伴可能只是想让我们的软件更符合潮流,你认为我正确地忽略了合作伙伴的要求吗?还是他们告诉了我们应该倾听的东西(即使编码成流行语)?


你现在使用哪些技术来进行消息路由和事件触发,还有什么其他的技术没有使用? - buckbova
ESB是异步消息传递的流行术语,通常通过某些消息队列系统实现,在大多数“企业级”产品中意味着高延迟和高配置以及维护难度,这取决于您选择使用的ESB实现。 - user177800
2
我们的雇主和客户正在大量投资ESB技术,但我并不喜欢最高评分答案说它只是噱头。我发现有趣的是,那两个没有将ESB视为纯粹流行语的答案既没有浮现到顶部,也没有被接受。我提供赏金,看看是否能产生更好的答案或者对现有答案进行更好的改进。 - T.Rob
6个回答

38

虽然ESB基于消息传递,但它不仅仅是“聊天”,也不只是一个流行词。

因此,如果您从普通异步消息开始,早期网络往往非常点对点。每个连接和每对目标都必须手动配置(即通过某些管理界面),如果您敢于移动任何东西,那么肯定会出现问题。由于连接点是手工连接的,所以这些网络从未实现高连接密度。增量成本太高,没有扩展性。拓扑结构中还嵌入了很多访问控制和策略。尽管缺乏连接密度有利于这种安全性方法,但它却抑制了灵活性。

ESB试图解决这些问题,包括:

  • 运行时解析目标/服务/资源
  • 位置透明性
  • 任何到任何的连接和最大连接密度
  • 为冗余性,水平可扩展性,故障转移而设计
  • 策略,访问控制,规则从拓扑结构外部化
  • 基于物理消息网络层实现的逻辑消息网络层
  • 公共命名空间

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

  • 避免消息到达亲和性,例如需要按严格顺序处理或仅将请求地址定向到特定节点而不是通用网络目标
  • 能够在运行时动态解析目标(即添加另一个队列实例,它会自动开始接收流量,删除一个实例,则流量路由到剩余节点)
  • 请求器和提供器应用程序不知道彼此“住在”哪里。请求器进行一次连接,而无论需要调用多少个服务
  • 根据策略而不是拓扑授权
  • 服务提供者应用程序能够识别和处理重复项(根据JMS规范,参见会话处理的“功能性重复项”)
  • 能够运行多个服务提供者应用程序实例
  • 为服务提供者应用程序提供工具,以便可以查询网络的状态或执行测试而无需发送实际事务

另一方面,如果您的客户无法表达这些内容,则他们可能只想勾选一个标签,表示“与ESB兼容”。


1
非常信息丰富的回答。我想补充一下(从我的非专业观点),公司IT基础设施越大、越复杂,企业服务总线的价值就越高。管理数千个连接比管理几十个连接要困难得多。 - peteorpeter

26

我会尽量避免使用流行术语(但可能会出现流行缩写)。

当服务/应用程序/主机等希望集成(因此彼此发送消息)时,可能会出现混乱。ESB将这种混乱隐藏在其内部,使组织可以假装没有混乱,并且拥有可管理的东西。然后,它包装了一系列特性,使这个盒子更具吸引力,让组织中的高级人员做出购买这种昂贵产品的决定。这些人通常希望引入一个耗资巨大的大型计划,以证明他们正在“做些什么”,并且知道如何花费大量的钱。如果这是一个面向服务体系结构(SOA)的计划,那么各种供应商将告诉他们需要一个ESB才能使供应商对SOA的愿景产生作用(一旦他们想要的服务数量超过微不足道的数量)。

因此,ESB 是:

  1. 供应商赚取大量钱的工具;
  2. 顾问赚取大量钱的工具;
  3. 高管(IT总监等)展示他们可以花费大量资金的方式;
  4. 隐藏混乱的盒子;
  5. 对技术团队来说非常麻烦。

4
而讽刺的回答却排到了首位。:-/ 很难说这是真诚还是开玩笑,但无论如何,我希望提供一个能够为那些不得不参与ESB项目(不管好坏)的人提供一些指导的答案,但这不是。我并不是在争辩这里面的任何东西是不正确的(如果有机会一起喝酒再来个愉快的讨论吧),只是对于需要迅速掌握技能、产生结果的人来说,这并不是特别有成效的。 - T.Rob
如果我的话听起来有点刻薄,我很抱歉。那并不是我的本意。根据我的经验,在那些采用这些产品的组织中工作,并与这些产品打交道时,我发现这些和其他事情对我来说都是真实的。提问者关注的是这样一个问题:是否应该将这样的请求视为对流行语言的迎合。我的观点是,它可以这样看待,但作为供应商的营销手段,它确实具有价值,即使在道德上可能没有。 - Neil
再次阅读问题,我认为没有给出足够的细节来确定OP的产品是否会受益于互操作性,但是,如果互操作性很有价值,那么专注于ESB兼容性可能是一个无益的角度。相反,任何互操作策略的选择都应该考虑到预期的互操作场景(频率/延迟/消息大小等)。这可能会导致不同的方法,从基于数据库的集成、REST、通过MQ传递事件、到同步SOAP等......任何ESB都应该能够与这些方法之一配合使用。价值主张留给客户在其上下文中考虑。 - Neil

9
经过一番调查研究,我的直觉告诉我这只是一种流行用语,意思是我们需要一种平台无关的方式来传递消息。
你说得对,部分原因是ESB这个术语总是与另一个流行用语(合法或不合法)相称——治理(即帮助您管理谁在访问您的终端点并报告指标——顺便说一句,指标是所有西装革履的人都喜欢看到的,所以这可能是一个贡献因素)。
他们可能想要一个平台中立的设备,这样他们消耗的任何服务都始终作为终端点从一个中央位置公开,而不是特定的机器资源。 ESB使您的服务的实际物理终端对他们无关紧要,他们不应该太关心,但这使您可以随意移动服务,但他们只能消耗ESB终端点。
除了集中式存储库进行发现之外,ESB还使服务的并排版本控制更加容易。如果我有选择,并且我的公司有预算,我们将购买IBM的x150设备:(
第三,许多更高级的总线,例如SoftwareAG的产品,本质上能够将遗留数据(例如来自主机上的数据)作为服务公开,而无需通过适配器进行编码。
我不知道他们的意图是利用ESB提供的所有好处,还是像你说的那样,使它符合流行用语的要求。

7
经过一番调查研究,我认为这只是说我们需要一种平台无关的方法来传递消息的流行说法。
没错,有时企业服务总线(ESB)会更进一步,包括额外的功能,如消息传递保证、确认/回执消息等等。ESB的存在通常明确或隐含地创建了一个之前不存在的新协议,这也是另一个重要的考虑因素。(也就是说,必须设定某种标准或接口来规定消息的格式。)
我是否正确地将我们的合作伙伴的请求解读为试图使我们的软件更符合流行语的要求,还是他们告诉我们应该听取的信息(即使使用流行语编码)?
您应该始终听取客户的意见,即使最初听起来很傻。至少值得花费一些精力来确定发生了什么。在字里行间阅读,您的合作伙伴可能的意思是,他们希望您的服务能够更轻松地与他们自己的服务和产品集成。

6

企业服务总线以标准化的方式处理系统之间的消息传递。这使您可以在所有平台上以完全相同的方式与总线通信,总线会处理实际的翻译工作,以满足特定端点所需的个别通信机制。这意味着您编写所有代码以使用常见的消息方案与总线进行通信,总线负责将您的通用方案转换为端点可以理解的格式。


0

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

多年来,公司为了实现业务功能,从财务到人力资源,收购了不同的平台和技术。这些系统需要相互通信以共享数据,因此中间件成为连接它们的粘合剂。在企业意识到之前,他们正在为每个系统和中间件支付支持和维护费用。随着业务需求的变化,部门决定创建自己的定制解决方案来解决特殊需求,而不是尝试使老化的解决方案足够灵活以满足他们的需求。在他们意识到之前,他们正在支付遗留系统、中间件和定制解决方案的支持和维护费用。随着像萨班斯·奥克斯利这样的新法律的出台,公司需要有更好的信息可用于报告目的。单一视图要求他们从所有系统中捕获数据。此外,首席信息官现在面临降低成本和提高客户服务的压力。一个明显的解决方案是消除冗余系统、昂贵的支持和维护合同以及需要专家支持的高成本遗留解决方案。转移到新平台可以实现这一点,但需要进行过渡。没有现成的解决方案可以复制业务所做的事情。为了解决信息传递的需求,他们选择SOA,因为它允许通过通用实体访问信息。如果我从服务总线请求所有员工,它会获取它们,无论是来自15个人力资源系统还是1个系统。当15个人力资源系统变成1个系统时,调用和结果不会改变,只是在幕后完成的方式有所不同。服务总线概念标准化了信息流,并允许IT经理在总线后面进行过渡,对上游用户没有长期影响。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接