4

我对 ESB 或 Biztalk 不太熟悉，如果您已经拥有 Biztalk，我正试图从 EAI 的角度了解什么是最有意义的。据我了解，Biztalk 是一个消息代理（集线器和辐条），而 ESB 模式是一种反代理，其中概念“总线”由以某种方式相互通信的各个分布式组件组成。消息代理本质上代表单点故障，而不是 ESB，其中一个组件发生故障并不会导致整个“总线”瘫痪。此外，我的理解是，Biztalk 是单一的，因为消息传递、编排紧密耦合并且扩展存在问题。

如果手头的情况是：

  • Biztalk 已经主要用于根据从外部各方收到的不同文件运行不同的编排。
  • 一堆目前与 CRM 和工资单等系统紧密耦合的内部定制应用程序需要重构以抽象出这些依赖关系。

直接使用 Biztalk 或 Biztalk ESB 工具包来实现 ESB 功能是否有意义，或者使用适当的 ESB 实现（例如 NServiceBus 或基于 Azure 服务总线的 Windows 服务总线）是否有意义。直接使用 Biztalk 实现 EAI 与使用适当的 ESB 的优缺点是什么。每个应用程序是否会严重依赖 Biztalk，这是否可取？

由于没有正确或错误的答案，我将把它作为一个开放式讨论。

@斯图尔特LC： 感谢您的答复。我已经阅读了您发布的几个链接，但仍然不清楚 Biztalk 作为 ESB 解决方案与使用 NServiceBus 之类的解决方案是否有意义。两者似乎都以一种或另一种方式实现“ESB”模式。问题是哪一个具有更清洁的实现、更好的开发经验和更短的启动时间。到目前为止，我的评估（仅来自纯粹的研究）是可以使用 Biztalk，但它很痛苦并且需要非常专业的开发人员。技能。延迟和扩展存在问题，并且 Biztalk 最终将被同化到（Azure？）服务总线和 Biztalk SKU 的事实将不复存在。另一方面，像 NService 总线这样的框架具有相对较短的启动时间，可以很容易地被开发人员使用。过得很好。NET 编程技能，可以轻松与 Biztalk 交互。鉴于上述情况，即使您目前在内部拥有 Biztalk，或者为了将来证明自己使用适当的 ESB（例如 NService Bus），走 Biztalk 路线是否仍然有意义？

4

1 回答 1

6

我相信您的开放式问题的许多组成部分已经在 SO 中介绍过：

然而，IMO 这只是一个有缺陷/短视的实现，这将导致应用程序和端点之间的紧密耦合。松耦合很容易实现：（即使没有 ESB 工具包）：

单点故障也是可以避免的：

  • 在通信适配器上配置重试和备用/备份传输
  • 通过服务器组和集群实现冗余
  • 并使用对交付失败的补偿进行回退

IMO 使用 BizTalk 作为 ESB 时的致命弱点是缺乏保证的延迟，例如，如果 BTS 进入节流状态，这种情况会加剧。

更新

IMO 的选择归结为您是否可以控制环境中的所有系统。

如果您正在集成一个内部企业，该企业只包含您可以直接控制的同质的、现代的（主要是 SOA 和 EDA）应用程序，MassTransit或者NServiceBus可能会超出工作的范围，并且您可以提高生产力和加速时间。

于 2012-12-23T12:21:25.420 回答