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有一个很棒的Administration interface
• MSMQ已存在更长时间并且是Microsoft产品
• RabbitMQ是较新的，开源的，免费的，由VMWare赞助
• 默认情况下，MSMQ安装在大多数Windows计算机上

Udi Dahan和MassTransit球员（Chris Patterson，Dru Sellers和Travis Smith）都是出色的人。

Answer 2

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

<强> Transport support

NServiceBus和MassTransit都支持RabbitMQ和Azure Service Bus，但NServiceBus也支持：

• Amazon SQS
• Azure Storage Queues
• SQL Server (using plain tables)
• MSMQ

关于RabbitMQ的主题

可以说NServiceBus对RabbitMQ有更强的支持 - 例如，在delayed delivery functionality而Mass Transit states，他们的“插件仍然被认为是实验性的。它由MassTransit支持，但我们不能保证比插件保证更多的东西。“

我们还与RabbitMQ团队contributing to the .net SDK密切合作，为整个生态系统带来好处。

说到Azure Service Bus

我们与Azure Service Bus团队的协作水平更高，with over 70 PRs to their .net core SDK。

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

工具

这是最大的区别。

一旦你建立了一个实质性的系统，了解所有不同的运动部件如何相互通信变得非常重要。除了通过Diagnostic Source到第三方工具（如Application Insights或Open Trace）的小型集成之外，MassTransit在此领域的用户不多。

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

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

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

管理层＆amp;监测

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

围绕NServiceBus的服务平台包括监视该错误队列，图形工具以查看这些错误的原因，以及重放这些失败消息的组的能力以及看到它们实际上已成功处理所有这些都在名为ServicePulse的简单网络应用中。

还可以定期运行运行状况检查，可以在消息开始失败之前提供问题的早期警告。

最后，平台上有performance monitoring：

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

长期支持＆amp;向后兼容性

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

使用NServiceBus support includes：

• 每个主要版本2年以上
• extended support
额外2年
• 保证关键问题的响应时间
• 24x7可用性

咨询与咨询训练

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

<强>许可

有些人仍然不了解NServiceBus，它是FREE for personal use and startups。

谈到commercial use，围绕NServiceBus的许可模式非常灵活，因为广泛的客户表明，并且可以很好地管理。当然，使用MassTransit，许可是免费的。

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

Answer 3

你可以随时使用Shuttle（FOSS）：https://github.com/Shuttle/shuttle-esb：）

文档（始终在改进）：http://shuttle.github.io/shuttle-esb/

Shuttle项目已经用了近两年时间，用于生产系统。这将是一个选择与你产生共鸣的问题。

NServiceBus有良好的记录。我以前在生产系统（1.9）上使用过它，但是因为它已经商业化了（我从Shuttle开始的时候）。

我没有尝试过MassTransit。

我猜所有选项都有基础知识（命令/ event / pub-sub）。但是，NServiceBus确实有sagas和数据总线的东西，虽然我认为它很容易处理服务总线本身之外的数据，例如在你的端点消息处理程序中。我不知道MassTransit是否有传真/数据总线，但Shuttle当然没有。

另一个考虑因素可能是您打算如何使用服务总线。如果要成为产品的一部分，那么对于商业选择，例如NServiceBus，您需要考虑产品用户的成本影响，尽管仍然需要考虑内部开发，但它当然可以合理的。

Answer 4

我知道现在就解决这个问题已经很晚了，但是出于可穿戴性的考虑，我不得不提到Rebus（我刚好是它的主要作者）。

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

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

The documentation wiki相当全面，尽管似乎很多人都习惯了，因为Rebus的API很容易被发现。

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

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

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

Answer 5

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

几年前，我在新的云产品上使用了NServicebus，我们需要当时大众运输公司不支持的.NET Core。我不得不说-作为开发人员，这是一件很可爱的事情，有很多不错的工具，出色的工具/监控工具，而且文档非常好。

可以获得各种级别的支持和许可，有一次我们需要一些帮助，它的质量很高。

---

我在一家新公司使用大众运输已经有几个月了，他们非常喜欢拥有免费的开源库。旅程有些艰难-缺少MT的文档，而且很多示例/问题已经过时。高级功能也不是很多，但是您可能不需要它们的用例。

尽管运行良好，并且MT开发人员似乎在支持OSS上付出了很多努力-远远超出了您合理预期的范围。

因此，就我个人而言，我的TLDR是-如果可以说服您的公司为NServicebus买单，则可以使用NServicebus，但是MT是一种可维护的替代选择，也是免费提供的最好的选择。