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

Question

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

如果当前的场景是:

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

直接使用 Biztalk 或 Biztalk ESB 工具包来实现 ESB 功能是否有意义，或者使用适当的 ESB 实现(例如 NServiceBus 或基于 Azure 服务总线的 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?

但是，在我看来，这只是一个有缺陷/短视的实现，这会导致应用程序和端点之间的紧密耦合。松散耦合很容易实现:(即使没有 ESB 工具包):

• 通过使用 multipart messages and canonical internal schemas用于解耦依赖。
• 编排和端口应该通过消息框发布来解耦

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

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

在我看来，使用 BizTalk 作为 ESB 时的致命弱点是缺乏有保证的延迟，例如here如果 BTS 进入throttling state，情况会更加严重。 .

更新

在我看来，选择归结为您是否可以控制环境中的所有系统。

如果您正在集成一个仅由您可以直接控制的同类、现代(主要是 SOA 和 EDA)应用程序组成的内部企业，则可能会使用 MassTransit 或 NServiceBus不仅仅是工作所能提供的，你还能提高生产力并增加时间。