用于EAI的Biztalk与用于EAI场景的ESB

Question

我对ESB或Biztalk不太熟悉，如果您已经拥有Biztalk，我正试图从EAI的角度了解什么是最有意义的。据我所知，Biztalk是一个消息代理（集线器和分支），ESB模式是一个反代理，其中概念上的“总线”由各个分布式组件组成，这些组件以某种方式相互通信。消息代理本质上代表单点故障，与ESB不同，ESB中的一个组件故障不会导致整个“总线”停机。我的理解是，Biztalk是单片的，因为消息传递、业务流程是紧密耦合的，扩展是有问题的。

如果当前的情况是：

• Biztalk已主要用于根据从外部各方收到的不同文件运行不同的业务流程
• 目前与CRM和payroll等系统紧密耦合的一系列内部自定义应用程序需要进行重构，以提取出这些依赖关系

直接使用Biztalk或Biztalk ESB toolkit来实现ESB功能有意义吗？或者使用合适的ESB实现（如基于Azure服务总线的NServiceBus或Windows服务总线）有意义吗。与使用适当的ESB相比，直接使用Biztalk实现EAI有哪些优点和缺点。每个应用程序是否都会对Biztalk产生硬依赖，这是否可取？

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

@斯图尔特：谢谢你的回复。我已经阅读了您发布的几个链接，但仍然没有弄清楚Biztalk作为ESB解决方案与使用NServiceBus之类的解决方案是否有意义。两者似乎都以某种方式实现了“ESB”模式。问题是哪一个有更干净的实现、更好的开发经验和较低的启动时间。到目前为止，我的评估（仅限于纯研究）是可以使用Biztalk，但这很痛苦，需要非常专业的开发技能。延迟和扩展是有问题的，Biztalk最终将被吸收到（Azure？）服务总线和Biztalk SKU将不再存在。另一方面，像NService bus这样的框架具有相对较低的启动时间，可以很容易地被具有良好性能的开发人员接受。NET编程技能，可以轻松地与Biztalk进行接口。鉴于上述情况，即使您目前拥有Biztalk，还是选择Biztalk路线，或者选择合适的ESB（如NService Bus），这是否仍然有意义？

Answer 1

我相信你的开放式问题的许多组成部分已经涵盖了SO：

• 使用BizTalk而不是NServiceBus或MassTransit的优缺点
• 什么样的ESB系统最适合客户。净堆栈
• Microsoft BizTalk Server vs Azure AppFabric服务总线
• BizTalk 2009 ESB混乱
• BizTalk是ESB吗

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

• 通过使用多部分消息和规范的内部模式来解耦依赖关系。
• 编排和端口应该通过消息框发布来解耦

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

• 在通信适配器上配置重试和备用/备份传输

在我看来，将BizTalk用作ESB时的致命弱点是缺乏保证的延迟，例如，在这里，如果BTS进入节流状态，这种延迟就会加剧。

最新消息

在我看来，选择归根结底是一个问题，即您是否能够控制环境中的所有系统。

如果您正在集成一个内部企业，该企业仅由您直接控制的同质、当代（主要是SOA和EDA）应用程序组成，MassTransit或NServiceBus可能比这项工作更能提高生产率和启动时间。