EAI场景中的Biztalk与ESB

Question

我对ESB或Biztalk并不太熟悉，如果您已经拥有Biztalk，那么我正试图了解从EAI的角度来看最有意义的是什么。据我所知，Biztalk是一个消息代理(集线器和辐条)，ESB模式是一种反代理模式，概念上的“总线”是由不同的分布式组件组成的，它们以某种方式相互交流。消息代理本质上代表一个单一的故障点，而不是ESB，在ESB中，一个组件失败并不会使整个“总线”崩溃。另外，我的理解是，Biztalk在消息传递、编排紧密耦合和缩放是有问题的意义上是一成不变的。

如果目前的情况是：

• Biztalk主要用于根据从外部接收的不同文件运行不同的编排。
• 一组内部自定义应用程序目前紧密耦合到系统，如CRM和工资，需要重构以提取这些依赖项。

直接使用Biztalk还是使用Biztalk ESB工具包来实现ESB功能是有意义的，还是使用适当的ESB实现(如基于Azure的NServiceBus或Service )是否有意义。直接使用Biztalk来实现EAI与使用适当的ESB有什么优缺点。每个应用程序是否都对Biztalk有严格的依赖，这是否可取？

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

@StuartLC:感谢您的回复。我读过您发布的几个链接，但仍然不清楚Biztalk作为ESB解决方案是否有意义，还是使用类似NServiceBus之类的东西。两者似乎都以某种方式实现了"ESB“模式。问题是哪一个有一个更干净的实施，更好的开发经验和较低的提升时间。到目前为止，我的评估(仅从纯研究)是，是的，Biztalk可以使用，但它是痛苦的，需要非常专门的开发。技能组合。延迟和缩放是有问题的，而且Biztalk最终会被同化到(Azure?)服务总线和Biztalk SKU将不复存在。另一方面，像NService总线这样的框架具有相对较低的提升时间，可以很容易地被开发人员获取。具有良好的.NET编程能力，能轻松与Biztalk接口。鉴于以上所述，即使您目前拥有Biztalk，或者将来使用适当的ESB (如NService总线)来证明自己，走Biztalk路线仍然有意义吗？

Answer 1

我相信你的开放式问题的许多组成部分已经涉及到这样的问题：

• 使用BizTalk而不是NServiceBus或MassTransit的利弊
• 哪些ESB系统最适合.Net堆栈？
• 微软BizTalk服务器对Azure AppFabric服务总线.？
• BizTalk 2009 ESB混淆
• BizTalk是ESB吗？

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

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

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

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

使用BizTalk作为ESB时的致命弱点是缺乏保证的延迟，例如，如果BTS进入节流状态，就会出现这里。

更新

海事组织的选择归结为一个问题，你是否有控制所有的系统在你的环境。

如果您正在集成一个内部企业，该内部企业仅由您直接控制的同构的、当代的(主要是SOA和EDA)应用程序组成，那么MassTransit或NServiceBus可能比工作提供的更多，而且您的生产率和增加时间也会更好。