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