针对EAI场景的EAI与ESB的Biztalk

Question

我不太熟悉ESB或Biztalk，如果你已经拥有Biztalk，我试图从EAI的角度来看看最有意义的东西。据我所知，Biztalk是一个消息代理（hub和spoke），ESB模式是一个反代理，其中概念“总线”由各个分布式组件构成，它们以某种方式相互通信。 消息代理本质上代表单点故障，而不是ESB，其中一个组件发生故障并不会导致整个“总线”失效。另外我的理解是Biztalk是单片的，因为消息传递，编排是紧密耦合的，并且缩放是有问题的。

如果手头的情况是：

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

直接使用Biztalk或Biztalk ESB工具包实现ESB功能是否有意义，或者使用适当的ESB实现（例如基于Azure Service Bus的NServiceBus或Service Bus for Windows）是否有意义。 使用Biztalk直接实现EAI与使用适当的ESB相比有哪些优缺点。 每个应用程序是否会严格依赖Biztalk以及这是否可取？

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

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

Answer 1

我相信您的开放式问题的许多组成部分已在SO上涵盖：

• Pros/Cons of using BizTalk instead of NServiceBus or MassTransit
• What ESB systems work best for the .Net stack?
• Microsoft BizTalk Server vs Azure AppFabric Service Bus...?
• BizTalk 2009 ESB Confusion
• Is BizTalk an ESB?

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

• 使用multipart messages and canonical internal schemas解耦依赖关系。
• 应通过消息框
发布解耦业务流程和端口

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

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

当使用BizTalk作为ESB时IMO的致命弱点是缺乏有保证的延迟，例如如果BTS进入here，则throttling state会被解除。

<强>更新

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

如果您正在整合仅由您可以直接控制的同类，当代（以及主要是SOA和EDA）应用程序组成的内部企业，MassTransit或NServiceBus可能比工作更多并且你提高了生产力并增加了时间。