105

只是做一些快速的峰值可能使用消息系统来处理在一个很好的解耦的工作流系统中的文件。

人们发现使用上述每个框架的优点和缺点是什么？与带有 WCF 绑定和/或非 MSMQ 解决方案的手动 MSMQ 系统相比，使用这些系统有什么优势？

4

4 回答 4

72

我建议远离手动解决方案，因为有一堆有点困难的东西需要得到恰到好处 - 比如如何处理事务，异常如何导致回滚，如何停止无休止的回滚（毒消息），如何与长期运行的工作流集成，以使状态管理边界对齐，等等。

您可能需要某种持久/事务性消息传递基础架构，因此不使用 MSMQ，您将在 Microsoft 平台上使用 Service Broker，或使用 ActiveMQ 等其他替代方案。MSMQ 的好处是已经安装在所有 Windows 机器上，而 Service Broker 则没有。

在 NServiceBus、Mass Transit 和 Rhino Service Bus 之间进行选择方面 - 这个 Stackoverflow 答案比较 NServiceBus 和 MassTransit将是一个很好的起点。

在我们的 3.1 版本中，我们引入了 NSB Studio - 一组 Visual Studio 集成建模工具，使您能够在更高的抽象级别上对系统进行建模，并自动为您完成 NServiceBus 的大部分配置和初始化。我想说这确实使天平有利于 NServiceBus。

希望有帮助。

免责声明：我是 NServiceBus 的作者。

于 2009-10-23T19:17:42.593 回答
51

NServiceBus是一个很好的产品，但要注意许可问题。它倾向于按照作者的意愿更改其许可政策。以旧许可证信息为例。

在你的项目开发过程中，你可能会发现你必须为 NServiceBus 付出很多钱。

免费版也有性能限制。

MassTransit是完全免费的开源软件，没有任何限制，并且在 Apache 2.0 许可下。

我没有使用过Rhino Service Bus。

于 2012-04-11T08:20:42.437 回答
25

Rhino vs NServicebus 的状态更新：

http://www.infoq.com/news/2012/04/nservicebus3-0

InfoQ 致 Ayende： 您之前自己为 .NET 编写了一个服务总线，即 Rhino Service Bus。Rhino Service Bus 的用户现在应该重新考虑并迁移到 NServiceBus 吗？

Ayende: I built Rhino Service Bus around 2008. I built it mostly because I wasn't happy with the state of the other service buses at the time. I have had different concerns and direction when building my service bus, but that was 4 years ago. In that time, I think that NServiceBus made great strides in becoming an easier to use product and having a much better out of the box development story. If I was starting out with service buses today, I strongly doubt that I would be building my own.

于 2012-08-21T13:25:39.750 回答
9

任何基于 MSMQ 的潜在问题是对最大消息大小的限制。IIRC 它大约为 4MB，如果您正在处理大文件并将文件内容存储在消息中，您可能很容易遇到。

于 2009-10-23T05:30:20.557 回答