请你建议 - 如果我需要最大的系统间/语言兼容性，而主服务器将在.NET上实现，我可以使用NServiceBus或MassTransit，还是使用纯RabbitMQ更好？ NServiceBus或MassTransit会给出非常好的抽象级别，但不同解决方案和环境之间的通信容易是至关重要的。我现在更多地考虑使用纯粹的RabbitMQ，但如果我考虑错误的话，我会非常感激地指出一些利弊。
答案 0 :(得分：4)
如果您在内部有多个不同语言的应用程序必须发送和接收消息，我不建议使用NServiceBus或MassTransit。它们需要他们自己添加的某些消息头。您永远无法利用这些消息传递框架提供的所有功能。但是，如果在内部您都是.NET并且您有多个将使用消息传递基础结构的应用程序，那么NServiceBus和MassTransit将增加很多价值。
关于与第三方的互操作性。 NServiceBus和MassTransit的优点和缺点是您必须以强类型类或接口发送和接收消息。这些序列化为JSON / XML / BSON等，并再次反序列化为类型。
因此，它们需要消息头来指示用于反序列化目的的消息类型。如果没有消息类型标题，他们就无法工作。
使用类型更容易，但可能会导致互操作性问题。当与发送没有类型的XML或JSON消息的第三方集成时，需要在服务和第三方之间创建转换层。
您可以转换为映射到XML / JSON的自己的类型，或者转换为包含XML / JSON的字符串属性的简单类型。无论哪种方式，您的翻译层都会使用MassTransit / NServiceBus在内部发布消息，因此消息将包含所有必要的标题，以充分利用它们提供的所有功能。
为了向第三方发送消息，翻译层会将消息转换为第三方期望的XML / JSON。
第三方/系统间集成涉及多少邮件系统？如果答案很小，那么NServiceBus和MassTransit将是很好的选择，因为它们提供了很多很棒的功能。
如果答案很多，那么他们可能仍然是不错的选择。拥有翻译层将保护您的内部服务不会暴露于您的第三方的要求和更改模式。它将为您提供更大的控制力和灵活性，但需要额外的移动部件。
最终，翻译层并不像实施NServiceBus和MassTransit开箱即用的模式那么复杂。所以我会认真考虑它们是一个可行的选择。
有关互操作性的一些链接
https://docs.particular.net/nservicebus/messaging/third-party-integration
http://masstransit-project.com/MassTransit/advanced/interoperability.html