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