我正在为有关 NServiceBus 和 MassTransit 的优缺点列表而苦苦挣扎。
现在我知道这里已经有一个线程，但它并没有真正回答我的问题。
这是我到目前为止所读到的：
NServiceBus 较旧，并且有更多参考。很难找到有关 MassTransit 的信息，但我很开放。但是我必须提供一个可靠的解决方案，所以我不得不问。
所以，请有这两个框架经验的人。我为什么要选择 NServiceBus？或者 我为什么要选择 MassTransit？
是性能、安全性、规模还是？
如果我必须总结一下，这就是我要说的：
如果您需要商业支持，请选择 NServiceBus。如果您对使用论坛作为支持手段感到满意，MassTransit 是一个不错的选择。到目前为止，开发人员对我们的问题非常敏感。如果您选择 MassTransit，现在您将在 MSMQ 和 RabbitMQ 之间进行选择。如果您需要 DTC，请使用 MSMQ。如果您想要更多功能和更好的管理，请使用 RabbitMQ。
在我们的项目中，我们从 NServiceBus 切换到 MassTransit 有两个原因：
这两个框架我都用过。我使用 MassTransit 的时间比使用 NServiceBus 的时间长。这是我看到的亮点。
成本：
支持：
运输：
RabbitMQ 与 MSMQ：
Udi Dahan 和 MassTransit 的人（Chris Patterson、Dru Sellers 和 Travis Smith）都是才华横溢的人。
作为 NServiceBus 的原作者，我可能对自己的技术有点偏颇，但我会尽量保持平衡。
NServiceBus 和 MassTransit 都支持RabbitMQ和Azure Service Bus，但 NServiceBus 也支持：
关于 RabbitMQ 的话题
可以说 NServiceBus 对 RabbitMQ 有更强的支持——例如，在它的延迟交付功能中，而 Mass Transit声明他们的“插件仍被认为是实验性的。它由 MassTransit 支持，但我们不能保证除了插件之外的任何东西保证自己。”
我们还与 RabbitMQ 团队密切合作，为 .net SDK 做出贡献，以造福整个生态系统。
谈到 Azure 服务总线
我们与 Azure 服务总线团队的合作水平更高，他们的 .net 核心 SDK 有超过 70 个 PR。
当您使用 NServiceBus 时，您将受益于该知识的全部深度。
工装
这是最大的不同。
一旦你建立了一个实质性的系统，了解所有不同的移动部件如何相互通信就变得非常重要。除了通过诊断源与 Application Insights 或 Open Trace 等第 3 方工具进行小规模集成外，MassTransit 在这方面没有太多优势。
NServiceBus 周围的服务平台走得更远，使您能够使用ServiceInsight查看所有端点的序列图：
您还可以获得所有端点和消息的逻辑视图：
从本质上讲，您可以获得系统架构的实时文档。
管理与监控
这是 MassTransit 没有太多资源的另一个领域。当您集成的第 3 方系统变得不可用并且系统中的一堆消息最终进入错误队列时，MassTransit 的唯一解决方案是让您稍后使用RabbitMQ Shovel 插件手动将这些消息移回。
NServiceBus 周围的服务平台包括对该错误队列的监控、用于查看这些错误原因的图形工具，以及重放这些失败消息的组并查看它们实际上是否在一个简单的 Web 应用程序中得到成功处理的能力称为ServicePulse。
还有定期运行的健康检查的可视化，可以在消息开始失败之前提供问题的早期警告。
最后，平台中提供了性能监控：
在生产支持方面，您确实获得了完整的软件包。
长期支持和向后兼容性
虽然 Mass Transit 的人一直非常擅长帮助任何在Gitter或他们的Google Group上对此有疑问的人，但我认为他们不会为旧版本提供错误修复。当您的生产系统已经存在了几年，并且您不能一直升级所有内容时，这开始变得很重要。
NServiceBus支持包括：
咨询与培训
从线下的角度来看，NServiceBus 上有世界各地的公共课程，还有许多顾问可以被带到现场来启动项目或在出现问题时提供帮助。我听说有几家公司决定从 MassTransit 切换到 NServiceBus，因为他们在需要时无法派人到现场。
许可
有些人仍然不知道 NServiceBus 是免费供个人使用和初创公司使用的。
在商业用途方面，NServiceBus 周围的许可模型非常灵活，正如广泛的客户所表明的那样，并且可以很好地证明管理的合理性。当然，使用 MassTransit，许可是免费的。
希望在某种程度上有所帮助。
我知道现在回答这个问题已经很晚了，但是为了可折叠性，我不得不提到Rebus（我恰好是它的主要作者）。
Rebus 现在大约 8 岁了，它从一开始就被用来转移资金和控制发电厂。
它支持大多数基本的队列系统，如 MSMQ、RabbitMQ、Azure 服务总线、Azure 存储队列、Amazon SQS 等，但它也支持更有趣的东西，如使用 MSSQL、PostgreSQL 和 Oracle 作为传输。
文档 wiki相当全面，尽管很多人似乎都过得去，因为 Rebus 的 API 很容易被发现。
Rebus 一直（并且将永远）完全免费。它是 MIT 许可的，因此您基本上可以随心所欲地使用它。
如果您最终成为一名认真的 Rebus 用户，并且您需要正式的支持协议和额外的工具，您可以订阅Rebus Pro，它由Rebus FM（Rebus 背后的公司）提供。
上面提到的“额外工具”目前以Fleet Manager的形式出现，它可以帮助解决问题。例如，Fleet Manager完全替换了错误队列，因此失败的消息被存储在那里。这意味着在 Fleet Manager 中单击几下即可随时查看、管理和重试失败的消息。
只是为了给出一个更新的答案，我已经在这两个生态系统中进行了专业开发，它们现在都支持广泛的 MQ 技术和 .NET Core。
几年前我在一个新的云产品上使用了 NServicebus，我们需要当时 Mass Transit 不支持的 .NET Core。我不得不说 - 作为开发人员使用它是一件很可爱的事情，有很多不错的单线，很棒的工具/监控和文档非常好。
提供各种级别的支持和许可，有一次我们需要一些帮助，质量很好。
我在一家新公司使用了几个月的 Mass Transit，他们更喜欢拥有一个免费的开源库。旅程有点坎坷——机器翻译的文档有些地方缺乏，很多例子/问题已经过时了。高级功能的范围也不大，但您可能不需要它们的用例。
不过它工作得很好，而且 MT 开发人员似乎付出了很多努力来支持他们的 OSS——远远超出了您的合理预期。
因此，就我个人而言，我的 TLDR 将是 - 如果您的公司能够被说服支付 NServicebus，则购买 NServicebus，但 MT 是一种可用的替代方案，并且您可以免费获得最好的。
您总是可以使用 Shuttle (FOSS)：https ://github.com/Shuttle/shuttle-esb :)
文档（不断改进）：http ://shuttle.github.io/shuttle-esb/
Shuttle 项目已经进行了将近 2 年，并用于生产系统。这将是一个选择与你产生共鸣的问题。
NServiceBus 有良好的记录。我以前在生产系统（1.9）上使用过它，但自从它商业化（我开始使用 Shuttle 时）之后就没有使用过。
我还没有尝试过大众运输。
我想您的所有选项都将具有基础知识（命令/事件/发布-订阅）。然而，NServiceBus 确实有 sagas 和数据总线的东西，尽管我认为它很容易处理服务总线本身之外的数据，例如在您的端点消息处理程序中。我不知道 MassTransit 是否有 sagas/data 总线，但 Shuttle 肯定没有。
另一个考虑因素可能是您打算如何使用服务总线。如果它要成为产品的一部分，那么对于 NServiceBus 等商业选项，您需要考虑对产品用户的成本影响，尽管它仍然是内部开发需要考虑的事情，但它当然可以有道理。