我正在研究架构模式，特别是企业服务总线（ESB）。在阅读了这篇文章《企业集成》之后，虽然没有太多经验，但我想知道BizTalk是一个ESB还是只是一个EAI（中心/辐条或总线）。
我发现这篇NServiceBus和BizTalk的文章将BizTalk描述为中央消息代理。
考虑到其他ESB框架（如NServiceBus和Rhino Service Bus），这些框架没有处理消息的中心点。
BizTalk是EAI而非ESB吗？
非常感谢！
10个回答
18
微软将BizTalk推销为具有ESB功能的工具-请参见BTS ESB toolkit
然而，“ESB”这个术语涵盖了一个非常广泛的领域，对于ESB的确切定义存在很多主观性。在我看来，BizTalk声称作为ESB全面是有弱点的（按照大于2010年的定义）。
- BTS起源于轮毂与辐条EAI时代，在ESB变得普及之前。
- BTS更适合于异步过程而不是同步过程——延迟时间将取决于系统负载、调节状态等。
- BTS在服务和模式版本控制方面不太方便（需要新部署）
- BTS在管理许多服务方面很繁琐（例如，使用BizTalk作为公司SOA/Web Services的所有5000个服务的门面将会很痛苦）
FWIW我们发现BTS非常适合：
- 我们所有同步和异步EAI（即主要LOB系统之间和与交易伙伴之间的正式集成合同）以及大量的适配器有助于集成各种协议。
- 对于业务流程和业务监控功能
- 解决事务处理和传递可靠性 - Biztalk具有重试、跟踪和恢复暂停消息的能力，这在不可靠的网络或与不可靠的系统集成时非常有用。
更新，附带一些比较经验
- BTS非常集中化 - 最终，即使是多服务器BizTalk集群/组也依赖于Sql-Server。基于队列的ESB产品倾向于更分散（逻辑上和物理上），因此失去几个端点或队列服务器不应该使整个企业崩溃。
- 许多基于队列的ESB都建立在开源技术上，目的是避免单一供应商锁定
- 许多当代ESB似乎采用commodity-computing方法进行扩展。使用BizTalk等产品进行扩展可能变得昂贵。
- 好处是，不应低估商业产品（如BTS）的监视和管理能力 - 确保您正在考虑的任何ESB都具有足够的审计、仪表、重试和诊断（WMI / SNMP / SCOM等）功能 - 您需要一个仪表板来监视总线的健康状况，不知道消息去哪里是最糟糕的。在这里，集中化管理和诊断是一种优势。
- StuartLC
1
你对Mule有什么看法？ - amphibient
9
BizTalk是一种消息和工作流编排平台，您可以在其上构建ESB行为和功能。为了使这更加容易，并在BizTalk上标准化ESB实现，微软发布了BizTalk ESB Toolkit - 一套指南、模式和代码。
EAI和BPM的概念已经存在一段时间了，因此有许多公司利用BizTalk创建了解决这些问题的解决方案。但在BizTalk服务器上托管完整ESB的公司非常少，随着WCF/WF/NServiceBus和Azure Service Bus的出现，采纳情况显然有所放缓。
综上所述，BizTalk开箱即用既不是EAI也不是ESB，但可以通过应用若干开发人员来实现两者的功能。
- Rob Potter
4
我认为你是想知道BizTalk是否遵循中心枢纽或总线架构，所以根据"EAI或ESB"的定义。
从架构模式的角度来看，集成解决方案大致可以分为两种模式：
- 中心枢纽：这涉及一个集中的消息代理向各个接收者发送消息，而所有发件人仅向此代理发送其消息。因此，发件人和收件人都不需要彼此了解。这通常被许多人称为EAI（尽管完全可以实现遵循总线模式的EAI解决方案）。遵循该模式的解决方案易于开发和管理。所有路由逻辑都在中心（枢纽）处集中管理。但是，显然存在一个明显的缺陷 - 单点故障。如果中心崩溃，一切都会停止。此外，该模型的可伸缩性不佳。 - 总线架构：围绕该模式开发的企业集成解决方案通常称为ESB。这里没有智能中央机构。所有发件人都在总线上发布其消息。接收者需要足够聪明，以确定哪些消息是针对他们的，并将它们取出总线。因此，发件人和收件人只需要了解总线。但是，路由逻辑分布在接收者之间，因此没有单一故障点。此外，该模型具有高度可扩展性。然而，这些解决方案非常复杂且难以管理。
至于BizTalk的架构模式，它是两种模式的混合体。像中心枢纽一样的外观非常明显，其中包括集中的消息引擎和中央MessageBox数据库。这使得它具有中心枢纽方法的简单性和易于管理性。但是，如果查看BizTalk的架构，可以将主机与其主机实例分布在多个服务器上。还可以将不同的BizTalk数据库（如MessageBox、Tracking、Ent SSO等）配置在不同的服务器上。这使得BizTalk解决方案比通常归因于总线方法的基本枢纽实现更具可伸缩性和容错性。
希望这回答了你的问题。
从架构模式的角度来看，集成解决方案大致可以分为两种模式：
- 中心枢纽：这涉及一个集中的消息代理向各个接收者发送消息，而所有发件人仅向此代理发送其消息。因此，发件人和收件人都不需要彼此了解。这通常被许多人称为EAI（尽管完全可以实现遵循总线模式的EAI解决方案）。遵循该模式的解决方案易于开发和管理。所有路由逻辑都在中心（枢纽）处集中管理。但是，显然存在一个明显的缺陷 - 单点故障。如果中心崩溃，一切都会停止。此外，该模型的可伸缩性不佳。 - 总线架构：围绕该模式开发的企业集成解决方案通常称为ESB。这里没有智能中央机构。所有发件人都在总线上发布其消息。接收者需要足够聪明，以确定哪些消息是针对他们的，并将它们取出总线。因此，发件人和收件人只需要了解总线。但是，路由逻辑分布在接收者之间，因此没有单一故障点。此外，该模型具有高度可扩展性。然而，这些解决方案非常复杂且难以管理。
至于BizTalk的架构模式，它是两种模式的混合体。像中心枢纽一样的外观非常明显，其中包括集中的消息引擎和中央MessageBox数据库。这使得它具有中心枢纽方法的简单性和易于管理性。但是，如果查看BizTalk的架构，可以将主机与其主机实例分布在多个服务器上。还可以将不同的BizTalk数据库（如MessageBox、Tracking、Ent SSO等）配置在不同的服务器上。这使得BizTalk解决方案比通常归因于总线方法的基本枢纽实现更具可伸缩性和容错性。
希望这回答了你的问题。
- Parag Patil
5
我不太明白你所说的“接收器需要足够智能，以确定哪些消息是针对它们的，并将它们从总线上取下。因此，发送器和接收器只需要知道总线的存在。但是在这里，路由逻辑分布在接收器之间，因此没有单一故障点。” 你能否进一步阐述？ - Motivated
假设有两个订阅者- A 订阅类型为 Foo 的消息，而 B 订阅类型为 Bar 的消息。发布者在总线上发布了 3 条类型为 Foo 的消息和 2 条类型为 Bar 的消息。现在 A 和 B 应该有逻辑来确定这 5 条消息中哪些是针对他们的，并且他们必须自己从总线上取出这些消息。总线不会有这种逻辑。 - Parag Patil
那么如何与编排、业务规则等配合工作呢？ - Motivated
@Motivated，我不太明白你的问题。你能详细说明一下吗？另外，你所说的“编排”是指概念上的编排还是BizTalk中的编排？ - Parag Patil
如果我理解正确，总线驱动架构的工作原理是没有“愚蠢的管道”，即在这种情况下，订阅者具有处理适当消息的能力。如果是这样，那么这如何与编排（即工作流程、次要目标以及业务规则）配合工作呢？A和B是否需要执行自己的工作流程和业务规则，并协调次要目标，即一旦A完成处理，就将其移交给B，反之亦然，直到事务完成。这也如何在重放事务时工作？ - Motivated
2
BizTalk肯定是一个ESB。EAI更多的是一个宽泛的概念 - BizTalk肯定可以被部署来支持EAI，而且它还可以做更多的事情。
- Colin Pickard
1
当然可以！Biztalk源自EIS背景，这对于ESB作为跨混合技术平台的面向服务架构基础设施是非常合理的。
在以前的公司中，我们选择了Biztalk而不是IBM ESB产品，原因是功能和成本更低。
它是微软的产品，所以你得到你所付出的代价，但仍然值得研究。
在以前的公司中，我们选择了Biztalk而不是IBM ESB产品，原因是功能和成本更低。
它是微软的产品，所以你得到你所付出的代价，但仍然值得研究。
- Robert Morschel
1
如果没有"ESB Toolkit"，Biztalk Server就不是ESB。
- 它是基于契约的，需要先构建消息类型。
- 需要事先规划整个场景，以最小化变更的影响。
- 变更需要部署，这会增加停机时间。
关于您的问题，是的，BizTalk Server是EAI产品。
- Saffi Ali
1
我同意这里说的大部分内容。即使使用EBS工具包，将BizTalk作为全面的EBS解决方案也是一种牵强附会。
针对这里提出的几个观点...
•BTS更适合异步过程而不是同步过程-延迟时间将因系统负载、节流状态等而变化。
BizTalk主机默认设置下并不适合低延迟。但是这些主机是可以进行调整的。开箱即用的配置不适用于任何需要吞吐量的情况。在我的经验中，当我走进一个被避开BizTalk的组织时，总会有一个未调整的单一主机设置坐落其中。这有点类似于在没有索引的数据库管理系统中创建表格，然后出现性能问题并说dbms本身很糟糕。
•BTS在服务和模式版本控制方面很麻烦（需要新部署）。
就像任何开发平台一样，您需要有部署策略。如果模式在命名空间中具有版本，则无需重新部署任何内容。新版本可以在不关闭任何内容的情况下部署。
就服务端点而言，BizTalk可以在不使用IIS的情况下托管Web服务（BizTalk可以像IIS一样使用HTTP.SYS进行托管）。在BizTalk中托管进程内服务只是导入绑定的问题，可以在不停止BizTalk中的任何操作的情况下完成。在这些端点中，您也可以实现版本控制（例如http：... /thing/v1，http：... /thing/v2等）。无论如何，已经过去了约5年，我相信你现在已经得出了结论 :)
- Tom Stevens
1
BizTalk可以用作EAI和ESB。
对于ESB，BizTalk服务器架构是发布-订阅的，单个消息可以发布到消息框中，该框充当消息骨干总线。该消息可以被订阅该消息的一个或多个目标系统接收。当然，使用BizTalk服务器可以获得更多功能和特性，例如映射器工具和使用管道组件。
对于EAI的使用，BizTalk为您提供了编排来管理业务逻辑，LOB（业务线）适配器以连接到系统（也包括传统系统），映射器工具，规则引擎以及您需要集成公司内外不同系统所需的大量功能。
- Shay Feldman
0
BizTalk 可以同时实现 ESB 和 EAI，这取决于您如何设计 BizTalk 应用程序。
- Ed Bangga
网页内容由stack overflow 提供, 点击上面的可以查看英文原文，
原文链接
原文链接