请问您是否可以建议 - 如果我需要最大的系统间/语言兼容性，而主服务器将在.NET上实现，我可以使用NServiceBus或MassTransit，还是使用纯RabbitMQ代替？ NServiceBus或MassTransit将提供相当不错的抽象级别，但不同解决方案和环境之间的通信的容易性至关重要。我现在想更多地使用纯RabbitMQ，但如果我把它看成是错误的，那么指出一些优点和缺点会非常困难。最大系统间兼容性 - 纯RabbitMQ或NServiceBus，MassTransit？
如果您有多个内部具有不同语言的应用程序必须发送和接收消息，我不会推荐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
Hi Vanlyly！谢谢你的解释。我唯一不喜欢的帖子是翻译层应该直接与RebbitMQ对话，还是应该使用NServiceBus/MassTransin（如序列化为JSON字符串并通过NServiceBus/MassTransin发送）？ – Oleksii
这个想法是，“翻译层”向您的内部系统讲NServiceBus/MassTransit，并向您的第三方讲述任何外部协议/技术。细节真的取决于你的具体情况。如果你可以提供更多的细节，我可以用一个不太抽象的答案 – Vanlightly
总结这个最好的IMO的句子是“最终，翻译层不像实现现成的模式那么复杂由NServiceBus和MassTransit。所以我会认真考虑他们作为一个可行的选择。“ –
我在这里回答了类似的问题：http://stackoverflow.com/questions/25953891/why-do-we-need- service-bus-frameworks-like-nservice-bus-masstransit-on-top-of-me/25957608＃25957608 –