几年前，我问自己同样的问题。我希望nservicebus使用不同的消息队列，但问题是相同的。
我决定不使用nservicebus。
6个月后，我意识到我已经重建了nservicebus的一半功能。。。更糟糕的是。
同样的问题是，当您有公共语言运行时时，为什么需要带有rabbitmq的nservicebus，即为什么需要带有asp.net mvc的.net framework、winforms、xaml或.net附带的任何内置库。
毕竟clr还不够吗？
当然不是。拥有代码可以在其上执行的运行时（msil解释器和执行引擎）远远不够高效。
当然，您可以编写接受输入并生成输出的命令行应用程序。但是试着构建一个没有公共库的真正应用程序——没有内置的sql server驱动程序；没有任何第三方控件或库。生成不带system.windows命名空间的windows桌面应用程序。
您需要这些库来提供集合、数据库访问、窗口对象和ui控件。
类似地，rabbitmq提供了启动和工作所需的一切，但不足以维持生产力。
当然，您可以获取rabbitmq的.net驱动程序并开始生成和使用消息。
有一段时间，这会很好。
很快，您就会发现自己在驱动程序周围创建了一个 Package 器，这样就可以减少需要编写的代码量。
然后您会发现自己需要处理ack和nack，您将为此创建一个简单的api。
然后，对死信队列的需求将随着nack调用而出现，您将在api中进行封装—当然，与rabbitmq驱动程序相比，简化了。
最终，您将需要处理有害消息—格式错误并导致异常的消息。再说一次，您不想为此编写一次性代码，因此需要编写一个库来处理它。
名单上还有很多。
6个月后，您将发现自己正在使用一个半编写的、几乎没有指定的、不稳定的库，它只模仿nservicebus（或massttransit或您选择的任何其他服务总线库）的价值和功能。
我不会说你必须使用nservicebus。我想说的是，你应该学习rabbitmq是如何工作的，没有它。但是，一旦您超越了发送和接收消息的基础知识，nservicebus和其他服务总线实现的价值就会变得非常明显、非常迅速。

现在似乎有社区支持nservicebus中的Kafka交通：https://docs.particular.net/nservicebus/kafka/ （我自己还没试过）。