我正在权衡使用NServiceBus和MassTransit的优缺点。
据我所知，这里已经有一个讨论帖子了，但它并没有真正回答我的问题。
以下是我迄今为止阅读的内容：
NServiceBus比较老，参考资料更多。MassTransit很难找到相关资料，但我持开放态度。然而，我必须提供一个稳定的解决方案，因此我不得不问问。
因此，请有使用过这两个框架的人。我为什么要选择NServiceBus？或者为什么要选择MassTransit？
是性能、安全性、可扩展性还是其他原因？
如果我必须总结一下，我会这样说:
如果你需要商业支持，请选择NServiceBus。如果你习惯使用论坛作为支持手段，MassTransit是一个不错的选择。开发人员迄今为止非常积极地响应我们的问题。如果您选择MassTransit，现在您将在MSMQ和RabbitMQ之间进行选择。如果您需要DTC，请选择MSMQ；如果您想要更多功能和更好的管理，请选择RabbitMQ。
在我们的项目中，我们从NServiceBus切换到MassTransit的原因有两个:
我使用过这两个框架。我使用MassTransit的时间比NServiceBus长。以下是我认为的亮点。
费用：
支持：
传输：
RabbitMQ vs MSMQ：
帮助你不仅仅是这样，NServiceBus还通过其Transport Bridge使您能够在不同的传输上透明地运行不同的端点，在将本地系统与新的云功能集成时非常重要。
关于RabbitMQ
可以说NServiceBus对RabbitMQ的支持更强大-例如在其延迟交付功能方面，而Mass Transit则声明他们的“插件仍被认为是实验性的。它得到了MassTransit的支持，但我们不能保证除插件本身外还有其他东西。”
我们还与RabbitMQ团队密切合作，为整个生态系统的利益贡献.net SDK，并继续因此而受到认可，例如在这条推文中：https://twitter.com/RabbitMQ/status/1547946916419231744。
当谈到Azure Service Bus时
我们与Azure Service Bus团队的合作水平更高，已经对他们的.net core SDK进行了70多个PR。
当您使用NServiceBus时，您将受益于这些知识的全部深度。
工具
这是最大的区别。
一旦您建立了一个实质性的系统，了解所有不同移动部件如何相互通信变得非常重要。MassTransit在这个领域没有太多内容，除了通过Diagnostic Source到第三方工具（如Application Insights或Open Trace）的小型集成。
NServiceBus周围的服务平台走得更远，使您能够使用ServiceInsight查看所有端点的序列图：
此外，还有定期运行的健康检查的可视化，可以在消息开始失败之前提供问题的早期警告。
最后，平台上提供了性能监控：
当涉及到生产支持时，您真的可以获得全方位的服务。
长期支持和向后兼容性
虽然 Mass Transit 的开发人员一直非常擅长在 Gitter 或他们的 Google Group 上帮助任何有疑问的人，但我认为他们不会为旧版本提供错误修复。当您的生产系统运行了几年，而您不能一直升级所有内容时，这就变得很重要。
NServiceBus 的 support includes：
风险管理
Chris Patterson是MassTransit的创造者，他是我的老朋友，多年来他对社区的贡献都是出于对这项工作的热爱，我对他充满敬意。
问题在于，多年来，只有Chris一个人在开发和维护MassTransit，而且他也是唯一一个能够胜任这项工作的人。如果他出了什么事情（我祝他最好的），我真的不知道谁能够接替他的位置。
对于那些希望确保自己建立在坚实基础上的使命关键项目和产品来说，这种风险可能是无法承受的。相比之下，NServiceBus周围的大型组织拥有数十名全职员工，并与Microsoft、AWS和RabbitMQ建立了深入的合作关系，对于这些环境来说，选择NServiceBus可能是更少风险的选择。
咨询和培训
从离线角度来看，全球范围内提供有关NServiceBus的公共课程以及许多顾问可以被引进现场启动项目或在出现问题时提供帮助。我听说过几家公司决定从MassTransit转向NServiceBus，因为他们在需要时找不到现场支持。
许可证
有些人可能还不知道关于NServiceBus的一件事，那就是它对于个人使用和创业公司是免费的, 甚至对于一些有限的生产使用也是如此。
当涉及到商业使用时，NServiceBus的许可模型非常灵活，正如广泛的客户群所表明的那样，并且可以很好地向管理层进行证明。当然，对于MassTransit，许可是免费的。
为了给予更实时的回答，我曾经在两个技术生态系统中进行过专业开发，它们现在都支持广泛的MQ技术和.NET Core。
几年前，在新的云产品上，我使用了NServicebus，我们需要.NET Core，而当时Mass Transit不支持。我必须说 - 作为开发者，使用它是一件美妙的事情，有很多不错的单行代码、出色的工具/监控和非常好的文档。
可提供各种级别的支持和许可证，我们某个时候需要帮助，它提供的质量很高。
在一家新公司里，我已经使用Mass Transit几个月了，并且他们更喜欢使用免费的开源库。这个过程有点坎坷 - MT的文档在某些地方缺乏，很多示例/问题已经过时。也没有相应的高级功能，但对于他们的用例可能并不需要。
它能正常工作，MT的开发人员似乎会投入很多精力来支持他们的OSS - 远远超出你可以合理期望的范围。
因此，个人认为 - 如果公司可以被说服支付费用，那就选择NServicebus，但MT是一个可用的替代品，并且是免费使用中最好的。
