如果非要我总结的话，我会这么说：
如果您需要商业支持，请选择NServiceBus。如果您喜欢使用论坛作为支持的方式，MassTransit是一个很好的选择。到目前为止，开发人员对我们的问题React非常积极。如果您选择MassTransit，现在您将在MSMQ和RabbitMQ之间进行选择。如果您需要DTC，请选择MSMQ。如果您想要更多的功能和更好的管理，请选择RabbitMQ。
在我们的项目中，我们从NServiceBus转向了MassTransit，原因有两个：
1.公共交通免费
1.我们爱RabbitMQ
这两个框架我都用过，我使用MassTransit的时间比使用NServiceBus的时间长。
费用：

• MassTransit是Apache 2.0许可的，可免费用于商业生产，而NServiceBus不是。

支持：

• 正如Udi提到的，有一个商业NServiceBus支持的选项，我还没有看到公共交通。

运输：

• 大众运输支持MSMQ和RabbitMQ
• NServiceBus仅支持MSMQ NServiceBus 4+中支持RabbitMQ

RabbitMQ与MSMQ：

• MSMQ支持DTC（分布式事务处理协调器），用于涉及可能在多台计算机（例如SQL Server、Windows服务）上的多个进程的事务处理
• RabbitMQ具有出色的Administration interface
• MSMQ存在的时间较长，是Microsoft的一个产品
• RabbitMQ是由VMWare赞助的较新的开源免费产品
• 默认情况下，MSMQ安装在大多数Windows计算机上

乌迪·达汉和大众运输公司的人（克里斯·帕特森、德鲁·塞勒斯和特拉维斯·史密斯）都是才华横溢的人。

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

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

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

不仅如此，NServiceBus还支持您通过其Transport Bridge在不同的传输上透明地运行不同的端点，这在将内部系统与新的云功能集成时是一件大事。

关于RabbitMQ的主题

NServiceBus对RabbitMQ有更强的支持--例如，在其delayed delivery functionality中，而Mass Transit states中，他们的“插件仍被认为是实验性的。它得到了Mass Transit的支持，但我们不能保证插件本身以外的任何东西。”
我们还与RabbitMQ团队contributing to the .net SDK密切合作，为整个生态系统带来利益，并继续获得认可，如以下推文所示：https://twitter.com/RabbitMQ/status/1547946916419231744

关于Azure服务总线

我们与Azure Service Bus团队的协作级别甚至更高，with over 70 PRs to their .net core SDK。
当您使用NServiceBus时，您将受益于该知识的全部深度。

工具

这是最大的区别。
一旦您构建了一个实质性的系统，了解所有不同的移动部件如何相互通信就变得非常重要。除了通过Diagnostic Source与第三方工具（如Application Insights或Open Trace）进行小规模集成外，MassTransit在这方面没有太多优势。
围绕NServiceBus的服务平台更进一步，使您能够使用ServiceInsight查看所有端点的序列图：

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

实际上，您可以获得系统架构的动态文档。

管理与监控

这是MassTransit没有太多功能的另一个领域。当您集成的第三方系统不可用时，系统中的一堆消息最终进入错误队列，MassTransit唯一的解决方案是稍后使用RabbitMQ Shovel plugin手动将这些消息移回。
围绕NServiceBus的服务平台包括对错误队列的监控、查看这些错误的原因的图形工具，以及重放这些失败消息组并 * 查看它们实际上已成功处理 * 的能力，所有这些都在一个名为ServicePulse的简单Web应用程序中实现。

此外，还提供了定期运行的运行状况检查的可视化功能，可以在消息开始出现故障之前提供问题的早期警告。
最后，该平台提供了performance monitoring：
x1c4d 1x指令集
当涉及到生产支持时，您确实可以获得完整的软件包。

长期支持与向后兼容性

虽然Mass Transit的人一直非常善于帮助任何在Gitter或他们的Google Group上有问题的人，但我不认为他们会提供旧版本的bug修复。当你的生产系统已经存在了几年，你不能总是升级所有的东西，这就开始变得重要了。
使用NServiceBus support includes时：

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

克里斯帕特森，公共交通的创造者，是一个长期的朋友，他多年来对社区的贡献是这样一个爱的劳动，我对他没有什么，但钦佩。
问题是，几年来，克里斯是唯一一个一直在工作的人，甚至是唯一一个有能力在公共交通系统工作的人。如果他出了什么事，我希望他只有我最好的，我真的不知道谁能接替他的位置。
对于关键任务项目和产品，组织希望确保他们在未来几年建立在坚实的基础上，这种风险可能是站不住脚的。围绕NServiceBus的大型组织，拥有数十名全职员工，并与微软、AWS和RabbitMQ建立了深入的合作伙伴关系，可能是这些环境中风险较小的选择。

咨询与培训

从离线的Angular 来看，NServiceBus在世界各地都有公共课程，也有许多顾问可以在现场启动项目或在出现问题时提供帮助。我听说有几家公司决定从MassTransit转向NServiceBus，因为他们在需要时找不到人在现场。

许可

有些人仍然不知道NServiceBus是FREE for personal use and startups，甚至也不知道它是用于某些有限的生产用途。

就commercial use而言，NServiceBus的许可模式非常灵活，正如众多客户所表明的那样，并且可以很好地证明管理层的合理性。当然，对于MassTransit，许可是免费的。
希望这能有所帮助。

我知道现在讨论这个问题已经很晚了，但是为了bingleability，我不得不提到Rebus（我碰巧是它的主要作者）。
Rebus现在大约有8岁了，它从一开始就被用来转移资金和控制发电厂。
它支持大多数基本的队列系统，如MSMQ、RabbitMQ、Azure服务总线、Azure存储队列、Amazon SQS等，但它也支持更有趣的东西，如使用MSSQL、PostgreSQL和Oracle作为传输。
The documentation wiki是相当全面的，尽管许多人似乎还过得去，因为Rebus的API很容易被发现。
Rebus一直是（也将永远是）完全免费的。它是麻省理工学院授权的，所以你基本上可以用它做你想做的事情。
如果您最终成为了一个认真的Rebus用户，并且需要正式的支持协议和额外的工具，您可以订阅Rebus Pro，它由Rebus FM（Rebus背后的公司）提供。
上述“额外工具”目前以Fleet Manager的形式提供，它可以帮助解决问题。例如，Fleet Manager * 完全取代了错误队列 *（即死信队列），因此失败的消息被存储在那里。这意味着在Fleet Manager中点击几下，就可以随时查看、管理和重试失败的消息。

为了给予一个更新的答案，我已经专业地开发了这两个生态系统，它们现在都支持广泛的MQ技术和.NET核心。
几年前，我在一个新的云产品上使用了NServicebus，我们需要.NET核心，而当时Mass Transit并不支持。我不得不说--作为开发人员使用NServicebus是一件很可爱的事情，有很多不错的单行程序，很棒的工具/监控，文档也很好。
各种级别的支持和许可证可用，有一次我们需要一些帮助，它的质量很好。
我已经在一家新公司使用Mass Transit几个月了，他们更喜欢免费的开源库。这段旅程有点坎坷--MT的文档有些地方缺乏，很多示例/问题都过时了。高级功能的范围也不太大，但你可能不需要它们。
它工作得很好，虽然，和MT开发人员似乎投入了很多努力，以支持他们的OSS -远远超出了你可以合理地期望。
因此，就我个人而言，我的TLDR将是-获得NServicebus，如果您的公司可以说服支付它，但MT是一个服务的替代品，最好的你可以免费得到。

您可以随时使用Shuttle（FOSS）：https://github.com/Shuttle/shuttle-esb：）
文档（不断改进）：http://shuttle.github.io/shuttle-esb/
航天飞机项目已经进行了近2年，并使用生产系统。这将是一个问题，选择什么与你产生共鸣。
NServiceBus有一个很好的记录。我以前在一个生产系统（1. 9）上使用过它，但自从它商业化（我开始使用Shuttle的时候）后就没有了。
我没坐过公共交通.
我猜你所有的选项都有基本的（命令/事件/ pub-sub）。然而，NServiceBus确实有sagas和数据总线的东西，尽管我认为在服务总线本身之外处理数据是足够容易的，比如在你的端点消息处理程序中。我不知道MassTransit是否有sagas/数据总线，但Shuttle肯定没有。
另一个考虑因素可能是您打算如何使用服务总线。如果它是产品的一部分，那么对于NServiceBus这样的商业选项，您需要考虑产品用户的成本影响，尽管它仍然是内部开发需要考虑的问题，但它肯定是合理的。