logo标签列表

nServiceBus、Mass Transit、Rhino Service Bus等之间的比较？

msmqnservicebusservicebusmasstransitrhino-esb
105

我正在快速尝试使用消息传递系统来处理流程良好的文件，这些文件采用了良好的解耦工作流系统。

使用上述框架的优缺点是什么？相比使用手动编写的MSMQ系统和带有WCF绑定和/或非MSMQ解决方案，使用它们的优势是什么？

4个回答
73

我建议避免使用手写解决方案，因为需要正确处理许多相当困难的问题，比如如何处理事务、异常如何导致回滚、如何停止无限回滚（毒消息）、如何与长时间运行的工作流程集成，以便状态管理边界对齐等等。

你可能需要一些持久化/事务性消息基础设施，如果不使用 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 的作者。

25
Rhino Service Bus非常依赖于Castle。如果您不熟悉或不习惯将Castle作为应用程序架构的核心部分，您可能会遇到一些困难。而NServiceBus和Mass Transit则更加容器无关。NServiceBus带有一个“应用程序服务器”，它处理托管您的代码以及在将系统从开发环境过渡到测试环境和生产环境时更改活动基础设施实现（例如内存中、MSMQ和DB）。它还提供了用于消息处理逻辑和长时间运行进程的单元测试工具。我认为MassTransit没有这些功能。 - Udi Dahan
35
值得注意的是，Udi是NServiceBus的作者，因此他的观点可能有些偏见。 :) 话虽如此，我完全同意他的观点，并赞成出于同样的原因使用NServiceBus。 - skb
8
@skb: 同意！Udi，在回答nservicebus的问题时，你应该真的给一些免责声明，特别是像这样的问题！ - andy
14
我仍在适应一件事实，那就是如今有人开始发现NServiceBus，而这些人并不知道它是由我创建的。 - Udi Dahan
5
@UdiDahan：nServiceBus如何是“开源”的？仅仅发布源代码而没有授权使用它对于开源精神并没有任何帮助，因为开源的本质是共享。我完全支持你赚钱出售软件的权利（我也是这样做的），但我认为如果你不将解决方案（2.0版后）标榜为开源，那么更加准确。 - Eric J.
显示剩余4条评论
52

NServiceBus是一个很好的产品，但要注意许可证问题。它有改变许可政策的倾向，根据作者的意愿。例如，可以查看旧版的许可信息。

在项目开发过程中可能会发现需要为NServiceBus支付大量费用。

免费版本也有性能限制。

MassTransit绝对免费开源，没有限制，并且是根据Apache 2.0许可证发布。

我没有使用Rhino Service Bus。

1
实际上，我们将提供一个新的许可证版本3.1，允许您在多台机器上免费运行它（尽管吞吐量较低）。 - Udi Dahan
12
MassTransit 是你的选择。它是免费的，没有许可限制。如果你可以不使用流程设计工具并且能够自行编写代码，那么它是无与伦比的选择。它还可以运行在 RabbitMQ 之上，而 MSMQ 则有社区 Azure 插件。MassTransit + RabbitMQ 已经被证明是一个稳定的环境，并且可以让你快速启动消费者/生产者。 - Bigtoe
3
另外，考虑使用EasyNetQ（RabbitMQ的简单封装）。我很惊讶UDI在讨论中没有更多地提出建议，给出好的nServiceBus替代方案。我的意思是，在早期阶段帮助消息传递初学者。有许多简单且免费的方法可供选择，只要易于使用且最好免费即可（免费试用、免费实施，以及以后免费更改）。一旦您的业务发展壮大，您会发展自己的关注点清单；此时，选择更成熟的产品将变得更加容易，并且易于成本验证，例如nServiceBus。 - snowcode
从MassTransit 4.0开始，不再支持MSMQ（http://masstransit-project.com/MassTransit/）。 - MyGGaN
25

关于Rhino和NServiceBus的最新情况更新：

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

InfoQ询问Ayende：您以前为.NET编写过一个服务总线，即Rhino Service Bus。现在，Rhino Service Bus的用户是否应该重新考虑并转移到NServiceBus上？

Ayende回答：我建立Rhino Service Bus是在2008年左右，主要是因为当时我对其他服务总线的状态不满意，但那已经是4年前的事了。在此期间，我认为NServiceBus在成为易于使用的产品上取得了很大进展，并且具有更好的开箱即用的开发体验。如果我今天重新开始使用服务总线，我强烈怀疑我会自己构建。

9
使用MSMQ的潜在缺点是消息大小的限制。据我所知，它大约是4MB，如果您处理大文件并将文件内容存储在消息中，则很容易达到此限制。
7
有趣的是，大多数基于云的队列甚至不支持100KB的有效载荷，所以这将需要许多应用在未来考虑到。 - Udi Dahan
33
在《企业集成模式》（Woolf，Hohpe）中，Claim Check模式专门解决了这个问题。仅在消息中保留对大型有效载荷的引用，从而使消息保持较小。大型消息大小可能会对消息系统的吞吐量造成严重影响。 - Chris Patterson
4
这并不是NServiceBus的问题，因为它具有数据总线的概念，可以透明地解决大小限制的问题。 - Khalid Abuhakmeh
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接