我在NServiceBus和MassTransit的优缺点列表上苦苦挣扎。
现在我知道这里已经有一个线程，但是它并不能真正回答我的问题。
到目前为止，这是我读到的内容：
NServiceBus较旧，并且具有更多参考。很难找到有关MassTransit的信息，但是我很开放。但是，我必须提供一个可靠的解决方案，因此我不得不问。
所以，请有两个框架经验的人。为什么要选择NServiceBus？或为什么我应该选择MassTransit？
是性能，安全性，规模还是？
Answers:
如果我必须总结一下，这就是我要说的：
如果您需要商业支持，请使用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 Service Bus
我们与Azure Service Bus团队的协作水平更高，.net核心SDK拥有70多个PR。
使用NServiceBus时，您将从这些知识的全部深度中受益。
工装
这是最大的区别。
构建完备的系统后，了解所有不同的运动部件之间如何相互交流变得非常重要。除了通过Diagnostic Source与诊断工具到Application Insights或Open Trace之类的第三方工具进行小规模集成之外，MassTransit在此领域中没有很多。
NServiceBus周围的服务平台还有很多，使您能够使用ServiceInsight查看所有端点上的序列图：
您还可以获取所有端点和消息的逻辑视图：
本质上，您可以获得有关系统体系结构的实时文档。
管理与监控
这是MassTransit所没有的其他领域。当您要与之集成的第三方系统不可用并且系统中的一堆消息最终出现在错误队列中时，MassTransit唯一的解决方案是让您稍后使用RabbitMQ Shovel插件将这些消息手动移回。
围绕NServiceBus的服务平台包括对该错误队列的监视，图形工具以查看那些错误的原因，以及重播这些失败消息的组并查看它们是否已在简单的Web应用程序中被成功处理的能力。称为ServicePulse。
还具有定期运行的健康检查的可视化功能，可以在消息开始失败之前提供问题的早期警告。
最后，平台中提供了性能监控：
当涉及到生产支持时，您确实可以获得完整的软件包。
长期支持和向后兼容
尽管大众运输公司向来擅长帮助在Gitter或Google网上论坛上有疑问的人，但我认为他们不提供较早版本的错误修复。当您的生产系统已经使用了几年，而您不能一直升级所有产品时，这便变得很重要。
使用NServiceBus，支持包括：
咨询与培训
从离线角度来看，NServiceBus上有世界各地的公共课程，以及许多可以在现场启动项目或在遇到问题时提供帮助的顾问。我听说有几家公司决定从MassTransit转换为NServiceBus，因为他们无法在需要时在现场找人。
发牌
对于NServiceBus来说，有些人仍然不知道的是，它对于个人使用和启动都是免费的。
当用于商业用途时，NServiceBus周围的许可模型非常灵活，正如广泛的客户所表明的那样，并且可以很好地证明其适用于管理。当然，使用MassTransit，许可是免费的。
希望以某种方式有所帮助。
我知道现在就解决这个问题已经很晚了，但是出于可穿戴性的考虑，我不得不提到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中单击几下即可随时查看，管理和重试失败的消息。
您可以随时使用Shuttle（FOSS）：https：//github.com/Shuttle/shuttle-esb :)
文档（一直在改进）：http : //shuttle.github.io/shuttle-esb/
航天飞机项目已经进行了将近2年，并且是二手生产系统。选择与您产生共鸣的问题。
NServiceBus拥有良好的记录。我以前在生产系统（1.9）上使用过它，但是由于它已经商业化（我从Shuttle开始的那一点）就没有使用过。
我还没有尝试过MassTransit。
我想您所有的选项都将具有基础知识（命令/事件/发布-订阅）。但是，尽管我认为NServiceBus确实很容易处理sagas和数据总线，但可以轻松处理服务总线本身之外的数据，例如在端点消息处理程序中。我不知道MassTransit是否有sagas /数据总线，但Shuttle当然没有。
另一个考虑因素可能是您打算如何使用服务总线。如果要将其作为产品的一部分，则对于诸如NServiceBus的商业选择，您将需要考虑对产品用户的成本影响，尽管对于内部开发来说仍然需要考虑这一点，但可以肯定的是，有道理。
为了给出最新的答案，我已经使用两种生态系统进行了专业开发，它们现在都支持广泛的MQ技术和.NET Core。
几年前，我在新的云产品上使用了NServicebus，我们需要Mass Transit当时不支持的.NET Core。我不得不说-作为开发人员，这是一件很可爱的事情，其中有很多不错的工具，出色的工具/监控工具，而且文档非常好。
可以提供各种级别的支持和许可，而且有一次我们需要一些帮助，它的质量很高。
我在一家新公司使用大众运输已经有几个月了，他们非常喜欢拥有免费的开源库。旅程有些艰难-缺少MT的文档，而且很多示例/问题已经过时。也没有足够的高级功能，但是您可能不需要它们作为用例。
但是，它运行良好，并且MT开发人员似乎在支持OSS上付出了很多努力-超出了您合理预期的范围。
因此，就我个人而言，我的TLDR将是-如果可以说服您的公司为NServicebus买单，则可以使用NServicebus，但是MT是一种可服务的替代选择，也是免费提供的最好的选择。