請問您是否可以建議 - 如果我需要最大的系統間/語言兼容性，而主服務器將在.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 –