使用 BizTalk 而不是 NServiceBus 或 MassTransit 的优点/缺点

Posted 2023-02-15

【中文标题】使用 BizTalk 而不是 NServiceBus 或 MassTransit 的优点/缺点

【英文标题】：Pros/Cons of using BizTalk instead of NServiceBus or MassTransit

【发布时间】：2011-04-11 23:50:14

【问题描述】：

我很好奇它是否甚至考虑将 BizTalk 用于实现发布/订阅消息传递架构（基本上你可以使用 NServiceBus 或 MassTransit 来做我真正需要的一切）。我的经理倾向于坚持使用 Microsoft 直接提供的框架，因此作为我尽职调查的一部分，我需要为双方提供一套好的优缺点。任何指导将不胜感激！

【参考方案1】：

代理的主要缺点之一是版本和升级非常困难。您必须停止消息流才能升级特定端点。服务总线允许端点自治并独立升级。

然后在规模上有所不同。使用代理的趋势是向上扩展（垂直）而不是为向外扩展（水平）而构建的服务总线。您还必须通过某种 HA 设置（通常是集群）使代理具有高可用性。再加上这样做的软件成本可能会变得非常昂贵。

特别是 NSB 将提供付费支持模式，因此如果您的经理担心在出现问题时没有人在电话的另一端，您可以购买支持。

【参考方案2】：

Biztalk 是一个代理，更适合不同业务服务范围内的 EAI。服务总线是根本不同的。比较可以在这里找到：

http://docs.particular.net/nservicebus/architecture/nservicebus-and-biztalk

如果您能分享您的一些要求，我或许可以提供更多指导。

【参考方案3】：

请务必注意，BizTalk 是用于企业应用程序集成（EAI——正如 Andreas 所述）的服务器产品。它比框架更复杂。

Microsoft 确实有可在 BizTalk 中使用的 Enterprise Service Bus Toolkit，因此您可以将 BizTalk 环境称为 ESB。他们认为的“ESB”可能不是您认为的 ESB。您可以查看他们的 ESB 工具包页面 (http://msdn.microsoft.com/en-us/biztalk/dd876606.aspx)，但其中包含以下内容：

动态（即在运行时）消息 转换和翻译。 消息路由可以基于内容、基于行程或基于上下文，并在运行时确定。

当然，发布-订阅模式与使用服务总线不同。

BizTalk 是否 可以很好地完成发布-订阅，无论您是否使用 ESB 工具包。将单个消息发布到 BizTalk“消息框”非常简单，并将消息路由到任何和所有订阅者。 pub-sub 解决方案意味着 BizTalk 充当代理，但这有助于保证不会丢失消息，并跟踪所有消息。 BizTalk 发布-订阅解决方案具有内置的扩展点，允许我们添加、更改或删除端点，而不会影响解决方案的其余部分。

话虽如此，您的要求可能并不规定广泛的消息可靠性、监控和跟踪，因此 BizTalk 可能不是最适合您的。这是一笔巨大的投资，而且由于该产品可以同时做很多不同的事情，乍一看可能会让人望而生畏。

刚刚出版了一本名为“Microsoft 平台上的应用架构模式”的新书，其中涵盖了大部分内容。该书的作者之一，Richard Seroter，也发表了 SOA Patterns with BIzTalk Server 2009，如果您决定为您的公司使用 BizTalk，这将是必不可少的读物。

【讨论】：

由于我忽略了在我的回答中发布这两本书的链接，请随意使用我的 Amazon.com 链接 :-) amzn.to/ce5gVT

顺便说一句，Richard Seroter 就他的博客采访了我，专门介绍了 NServiceBus：seroter.wordpress.com/2010/04/01/…

【参考方案4】：

我支持 Andreas - BizTalk 通常更适合“增值”集成和业务流程管理，而不是 ESB 类型的活动。 BizTalk 擅长：

BPEL 长期运行/有偿交易 EAI 代理/映射 协议更改（MQ 到 WCF，平面文件到 SAP 等） EDI、RFID

但是，已经努力将 BizTalk 用作服务总线，特别是 ESB Toolkit