我正在研究架构模式，准确地说是企业服务总线 (ESB)。在阅读了这篇文章Enterprise Integration之后，几乎没有经验，我想知道 BizTalk 是 ESB 还是只是 EAI（集线器/辐条或总线）？
我发现了这个NServiceBus 和 Biztalk，将 BizTalk 描述为中央消息代理。
考虑其他 ESB 框架（NServiceBus 和 Rhino Service Bus）。这些框架没有处理消息的中心点。
Biztalk 是 EAI 而不是 ESB？
非常感谢
问问题
21893 次
10 回答
18
BizTalk 被 Microsoft 抨击为具有 ESB 功能 - 请参阅BTS ESB 工具包
但是，“ESB”一词涵盖了一个非常广泛的领域，并且关于 ESB 的确切定义存在很多主观性。恕我直言，BizTalk 声称作为 ESB 是全面的存在弱点（在该术语的 > 2010 定义中）。
- BTS 起源于 Hub-and-Spoke EAI 时代，在 ESB 普及之前。
- BTS 比同步进程更适合异步进程 - 延迟将根据系统负载、节流状态等而变化。
- BTS 在服务和模式的版本控制方面很麻烦（需要新的部署）
- BTS 在管理许多服务时很麻烦（例如，使用 BizTalk 作为企业所有 5000 个 SOA/Web 服务的外观会很痛苦）
FWIW 我们发现 BTS 非常适合：
- 我们所有的同步和异步 EAI（即主要 LOB 系统之间以及与贸易伙伴之间的正式集成合同），以及大量的适配器有助于集成大量的协议。
- 用于业务流程和业务监控功能
- 解决事务和交付可靠性 - Biztalk 具有重试、跟踪和恢复暂停消息的能力，这在不可靠的网络或与不可靠的系统集成时很有用。
更新，有一些进一步的比较经验
- BTS 非常集中——最终，即使是多服务器 BizTalk 集群/组也依赖于 Sql-Server。基于队列的 ESB 产品往往更加分散（逻辑上和物理上），因此丢失一些端点或队列服务器不应拖垮整个企业。
- 许多基于队列的 ESB 都是基于开源技术构建的，着眼于避免单一供应商锁定
- 许多当代 ESB 似乎采用商品计算方法来横向扩展。使用 BizTalk 等产品进行扩展可能会变得昂贵。
- 从好的方面来说，不应低估 BTS 等商业产品的监控和管理功能 - 确保您正在考虑的任何 ESB 具有足够的审计、检测、重试和诊断（WMI / SNMP / SCOM 等）功能 - 您将需要一个仪表板来监控您的总线的运行状况，没有什么比不知道消息去了哪里更糟糕的了。在这里，集中管理和诊断是一个优势。
于 2010-07-29T08:16:37.503 回答
9
BizTalk 是一个消息传递和工作流编排平台，您可以在其上构建 ESB 行为和功能。为了使这更容易，并使 BizTalk 上的 ESB 实现标准化，Microsoft 发布了 BizTalk ESB 工具包 - 一组指南、模式和代码。
EAI 和 BPM 的概念已经存在了一段时间，因此有许多公司利用 BizTalk 来创建这些问题的解决方案。在 BizTalk 服务器上托管完整 ESB 的公司要少得多，而且随着 WCF/WF/NServiceBus 的出现，当然还有 Azure 服务总线的出现，采用速度肯定会放缓。
所以总而言之，开箱即用的 BizTalk 既不是 EAI 也不是 ESB，但可以同时使用多个开发人员来解决问题。
于 2011-09-01T12:53:56.950 回答
4
通过“ EAI 或 ESB ”，我假设您想知道 BizTalk 是遵循 Hub&Spoke 还是 Bus 架构。
从架构模式的角度来看，集成解决方案大致属于以下两种模式之一：
Hub andspoke：这涉及到一个集中的消息代理向各个接收者发送消息，而所有发送者只将他们的消息发送给这个代理。因此，发送者和接收者都不需要相互了解。这通常是许多人所说的 EAI（尽管绝对有可能实现遵循 BUS 模式的 EAI 解决方案）。遵循此模式的解决方案易于开发和管理。所有路由逻辑都在一个地方集中管理 - 在集线器中。但正如您已经猜到的那样，这有一个明显的缺点——单点故障。如果集线器崩溃，一切都会停止。此外，该模型的扩展性不是很好。
BUS：围绕这种模式开发的企业集成解决方案通常被称为 ESB。这里没有智能的中央权威。所有发送者都在总线上发布他们的消息。接收者需要足够智能，才能确定哪些消息是发给他们的，并将它们从总线上带走。因此发送者和接收者只需要知道总线。但是这里的路由逻辑分布在接收器上，因此没有单点故障。此外，该模型具有高度可扩展性。然而，这样的解决方案相当复杂并且难以管理。
谈到 BizTalk 遵循哪种模式的问题 - 它是这两种模式的混合体。
Hub 的外观非常明显，具有集中的消息引擎和中央MessageBox 数据库。这提供了中心方法典型的简单性和易于管理性。
但是，如果您查看 BizTalk 体系结构，您可以拥有一个主机，其主机实例分布在多个服务器上。也可以在不同的服务器上配置不同的 BizTalk 数据库，如 MessageBox、Tracking、Ent SSO 等。这使得 BizTalk 解决方案比普通的集线器实现更具可扩展性和容错性 - 这是一种通常归因于总线方法的行为。
希望这能回答你的问题。
于 2015-08-09T00:21:10.113 回答
2
BizTalk 无疑是一个 ESB。EAI 是一个比较松散的概念——BizTalk 当然可以部署来支持 EAI，而且它还可以做更多的事情。
于 2010-07-28T16:38:01.523 回答
2
BizTalk 不仅仅是一个 ESB，但肯定符合要求。该链接有点旧，但可以回答您的确切问题。
编辑：这是一个更新的 MS 链接，介绍了实现的细节。
于 2010-07-28T16:39:57.727 回答
1
Biztalk Server withot "ESB Toolkit" Is not an ESB. Because of the following:
- Is a contract first, need to build you message types first.
- Need to Plan the whole scenario first to minimize the impact of changes.
- Changes requires Deployment which increases downtime.
Regarding to your qustion, Yes BizTalk Server is EAI Product
于 2014-11-17T17:14:33.757 回答
1
BizTalk 可以用作 EAI 和 ESB。
对于 ESB，BizTalk 服务器架构是发布订阅的，可以将单个消息发布到充当消息传递主干总线的消息框。订阅该消息的一个或多个目标系统可以接收该消息。当然，您可以通过使用 BizTalk 服务器（如映射器工具）和使用管道组件来获得更多功能和特性。
为了用作 EAI，BizTalk 为您提供管理业务逻辑的编排、连接到系统（也是旧版）的 LOB（业务线）适配器、映射器工具、规则引擎以及您需要的许多东西，以便集成不同的公司内外的系统。
于 2011-11-22T09:04:26.477 回答
1
绝对地！Biztalk 来自 EIS 背景，这对于 ESB 作为跨混合技术平台的面向服务架构的基础架构背板非常有意义。
在之前的一家公司中，出于功能和成本较低的原因，我们选择了 Biztalk 而不是 IBM ESB 产品。
它是微软，所以你得到你所支付的，但仍然值得研究。
于 2012-11-24T08:43:16.173 回答
1
我同意这里所说的大部分内容。即使使用 EBS 工具包，将 BizTalk 宣传为一个包罗万象的 EBS 解决方案也是一种延伸。
为了解决这里提出的几点...
•BTS 比同步进程更适合异步进程——延迟将根据系统负载、节流状态等而变化。
未更改默认值的 BizTalk 主机不适合低延迟。但是这些主机是要经过调整的。开箱即用的配置不适合任何需要吞吐量的情况。在我走进一个回避 BizTalk 的组织的经历中，总是有一个未经调整的单一主机设置位于它的中间。这有点类似于在没有索引的 dbms 中创建表，遇到性能问题并说 dbms 本身很糟糕。
•BTS 在服务和模式的版本控制方面很麻烦（需要新的部署）
与任何开发平台一样，您需要制定部署策略。如果模式在命名空间中有版本，则不需要重新部署任何东西。一个新版本可以部署而不需要任何东西。
就服务端点而言，BizTalk 可以在不使用 IIS 的情况下托管 Web 服务（BizTalk 可以像 IIS 一样使用 HTTP.SYS 来托管）。在 BizTalk 中托管进程内服务只是导入绑定的问题，无需停止 BizTalk 中的任何内容即可完成。在这些端点中，您也可以实现版本控制（如 http:.../thing/v1、http:.../thing/v2 等）。
无论如何~5年过去了，我相信你现在已经得出结论了：）
于 2015-02-13T00:29:00.090 回答
0
BizTalk 可以同时执行 ESB 和 EAI，这取决于您如何设计 biztalk 应用程序。
于 2018-07-06T07:23:58.007 回答