NServiceBus与MassTransit

Question

我正在努力寻找有关NServiceBus和MassTransit的优缺点列表.

现在我知道这里已经有了一个帖子,但它并没有真正回答我的问题.

这是我到目前为止所读到的内容:

1. NServiceBus,是的,它是许可的,它不是免费的.
2. MassTransit,是的,它是开源的,但文档似乎缺乏一些.

NServiceBus较旧,并且有更多参考.很难找到关于MassTransit的东西,但我心胸开阔.但是我必须提供可靠的解决方案,所以我不得不问.

所以,请有这两个框架经验的人.我为什么要选择NServiceBus？或者我为什么要选择MassTransit？

是性能,安全性,规模还是？

Answer 1

如果我不得不总结一下,这就是我要说的:

如果您需要商业支持,请访问NServiceBus.如果您对使用论坛作为支持手段感到满意,MassTransit是一个很好的选择.到目前为止,开发人员对我们的问题一直非常敏感.如果您选择MassTransit,现在您将在MSMQ和RabbitMQ之间进行选择.如果您需要DTC,请使用MSMQ.如果您想要更多功能和更好的管理,请使用RabbitMQ.

在我们的项目中,我们从NServiceBus切换到MassTransit有两个原因:

1. MassTransit是免费的
2. 我们喜欢RabbitMQ

我使用过两个框架.我使用的MassTransit比NServiceBus更长.以下是我看到它们的亮点.

成本:

• MassTransit是Apache 2.0许可的,可以免费用于商业生产,而NServiceBus不是.

支持:

• 正如Udi所说,有一个商业NServiceBus支持选项,我没有看到MassTransit.

运输:

• MassTransit支持MSMQ和RabbitMQ
• NServiceBus仅支持MSMQ NServiceBus 4+支持RabbitMQ

RabbitMQ vs MSMQ:

• MSMQ支持DTC(分布式事务协调器),用于涉及可能多台机器上的多个进程的事务(例如SQL服务器,Windows服务)
• RabbitMQ具有出色的管理界面
• MSMQ已经存在更长时间,是微软的产品
• RabbitMQ是较新的,开源的,免费的,并由VMWare赞助
• 默认情况下,MSMQ安装在大多数Windows计算机上

Udi Dahan和MassTransit队员(Chris Patterson,Dru Sellers和Travis Smith)都是出色的人.

Answer 2

作为NServiceBus的原作者,我可能对我自己的技术有点偏见,但我会尽量保持平衡.

运输支持

NServiceBus和MassTransit都支持RabbitMQ和Azure Service Bus,但NServiceBus还支持:

• 亚马逊SQS
• Azure存储队列
• SQL Server(使用普通表)
• MSMQ

关于RabbitMQ的主题

可以认为NServiceBus对RabbitMQ有更强的支持 - 例如,在其延迟交付功能中,而Mass Transit 声称他们的"插件仍然被认为是实验性的.它由MassTransit支持,但我们不能保证比插件更多保证自己."

我们还与RabbitMQ团队密切合作,为整个生态系统的利益贡献.net SDK.

说到Azure Service Bus

我们与Azure Service Bus团队的协作水平甚至更高,其.net核心SDK超过70个PR.

当您使用NServiceBus时,您将从该知识的全部深度中受益.

工装

这是最大的区别.

一旦你建立了一个实质性的系统,了解所有不同的运动部件如何相互通信变得非常重要.除了通过诊断源与第三方工具(如Application Insights或Open Trace)进行小型集成之外,MassTransit在此领域的功能并不多.

围绕NServiceBus的服务平台走得更远,使您能够使用ServiceInsight查看所有端点的序列图:

您还可以获得所有端点和消息的逻辑视图:

从本质上讲,您可以获得系统架构的实时文档.

管理与监督

这是MassTransit不具备的另一个领域.当您正在集成的第三方系统变得不可用并且系统中的一堆消息最终出现在错误队列中时,MassTransit唯一的解决方案是您稍后使用RabbitMQ Shovel插件手动移动这些消息.

NServiceBus周围的服务平台包括监视该错误队列,图形工具以查看这些错误的原因,以及重放这些失败消息组的能力,并在简单的Web应用程序中查看它们是否已成功处理叫做ServicePulse.

还有可视化的健康检查,这些检查定期运行,可以在消息开始失败之前提供问题的早期警告.

最后,平台中提供了性能监控:

在生产支持方面,你真的得到了完整的软件包.

长期支持和向后兼容性

虽然公共交通人员一直非常善于帮助那些对Gitter或他们的Google Group有疑问的人,但我认为他们不会在旧版本上提供错误修复.当您的生产系统已经存在了几年,并且您不能一直升级所有内容时,这开始变得非常重要.

NServiceBus 支持包括:

• 每个主要版本2年以上
• 额外2年的延长支持
• 保证关键问题的响应时间
• 全天候可用性

咨询和培训

从离线的角度来看,世界各地都有关于NServiceBus的公共课程以及许多顾问,他们可以带到现场来启动项目或协助解决问题.我听过几家公司决定从MassTransit转到NServiceBus,因为他们在需要时无法在现场找人.

许可

有些人还不了解NServiceBus,它是免费供个人使用和初创公司.

在商业用途方面,围绕NServiceBus的许可模式非常灵活,因为广泛的客户表明,并且可以很好地管理.当然,使用MassTransit,许可是免费的.

希望在某种程度上有所帮助.

Answer 3

只是为了提供最新的答案，我已经在这两个生态系统中进行了专业开发，它们现在都支持广泛的 MQ 技术和 .NET Core。

几年前，我在一个新的云产品上使用了 NServicebus，我们需要当时 Mass Transit 不支持的 .NET Core。我不得不说 - 作为开发人员使用它是一件可爱的事情，有很多很好的单衬，很棒的工具/监控和文档非常好。

提供各种级别的支持和许可，有一次我们需要一些帮助，质量很好。

我在一家新公司使用 Mass Transit 几个月了，他们更喜欢有一个免费的开源库。旅程有点坎坷——MT 的文档有些地方缺乏，而且很多例子/问题已经过时了。高级功能的范围也不大，但您可能不需要它们用于它们的用例。

不过它运行良好，并且 MT 开发人员似乎在支持他们的 OSS 方面付出了很多努力——这超出了您的合理预期。

因此，就我个人而言，我的 TLDR 将是 - 如果您的公司可以被说服为其付费，请使用 NServicebus，但 MT 是一种可用的替代方案，并且是您可以免费获得的最佳选择。

Answer 4

我知道现在就解决这个问题已经很晚了，但是出于可保留性的原因，我不得不提到Rebus（我恰好是Rebus的主要作者）。

Rebus现在已有8年历史了，它一直被用来转移资金并从一开始就控制发电厂。

它支持大多数基本的排队系统，例如MSMQ，RabbitMQ，Azure服务总线，Azure存储队列，Amazon SQS等，但是它还支持更多有趣的东西，例如使用MSSQL，PostgreSQL和Oracle作为传输工具。

尽管很多人似乎很了解，但是文档Wiki相当全面，因为Rebus的API非常容易被发现。

Rebus一直（并将永远是）完全免费的。它是MIT许可的，因此您基本上可以按照自己的意愿进行操作。

如果您最终成为Rebus的忠实用户，并且需要正式的支持协议和额外的工具，则可以订阅Rebus FM（Rebus的公司）提供的Rebus Pro。

上面提到的“额外工具”目前以Fleet Manager的形式出现，可以为您提供帮助。例如，Fleet Manager 完全替换了错误队列，因此将失败的消息存储在那里。这意味着可以在Fleet Manager中单击几下随时查看，管理和重试失败的消息。

Answer 5

你总是可以使用 Shuttle (FOSS): https://github.com/Shuttle/shuttle-esb :)

文档（不断改进）：http : //shuttle.github.io/shuttle-esb/

Shuttle 项目已经进行了将近 2 年，并使用了生产系统。这将是一个选择与你产生共鸣的问题。

NServiceBus 有着良好的记录。我以前在生产系统 (1.9) 上使用过它，但自从它商业化后就没有使用过（我开始使用 Shuttle 的时候）。

我没试过大众运输。

我想您的所有选项都将具有基础知识（命令/事件/发布订阅）。然而，NServiceBus 确实有传奇和数据总线的东西，尽管我认为处理服务总线本身之外的数据很容易，比如在你的端点消息处理程序中。我不知道 MassTransit 是否有传奇/数据总线，但 Shuttle 肯定没有。

另一个考虑因素可能是您打算如何使用服务总线。如果它是产品的一部分，那么对于像 NServiceBus 这样的商业选项，您需要考虑对产品用户的成本影响，尽管它仍然是内部开发需要考虑的事情，但肯定可以有道理。