nServiceBus vs Mass Transit vs Rhino Service Bus vs other？

Question

nServiceBus vs Mass Transit vs Rhino Service Bus vs other？

mwj*_*son 103 msmq masstransit nservicebus servicebus rhino-esb

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

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

Answer 1

我建议远离手工解决方案,因为有一些有点困难的东西需要得到恰到好处 - 比如如何处理事务,异常如何导致回滚,如何停止无休止地回滚(有毒消息),如何与长期运行的工作流程集成,以便状态管理边界排队等等.

您可能需要某种持久/事务性消息传递基础结构,因此不使用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的作者.

值得注意的是,Udi是NServiceBus的作者,因此他的观点可能有点偏颇.:)话虽如此,我完全同意,并且会提倡使用NServiceBus,原因与他所做的相同. (35认同)
Rhino Service Bus非常以Castle为中心.如果您不熟悉/不熟悉Castle作为应用程序架构的核心部分,那么您可能会遇到一些困难.NServiceBus和Mass Transit或更多容器不可知.NServiceBus带有一个"应用程序服务器",可以处理托管代码以及在将系统从开发转换为测试到生产时更改活动基础结构实现(如内存,MSMQ和数据库).它还带有用于消息处理逻辑和长时间运行过程的单元测试工具.我不相信MassTransit有这些. (25认同)
我仍然习惯于人们现在发现NServiceBus,他们不知道我创造了它 (14认同)
@skb:同意了!Udi,你应该在回答nservicebus问题时给出某种免责声明,尤其是像这样的问题! (8认同)
@UdiDahan:nServiceBus如何"开源"？在没有许可证的情况下发布源代码来使用它对于开源的精神没有任何作用,这就是共享.我完全支持你以销售软件为生的权利(我做同样的事情),但我认为如果你没有把解决方案(2.0后)作为开源来宣传,那就更准确了. (5认同)

Answer 2

Ale*_*sev 52

NServiceBus是一个很好的产品,但要注意许可问题.根据作者的意愿,它倾向于改变许可政策.请查看旧许可证信息.

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

免费版也有性能限制.

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

我没有使用过Rhino Service Bus.

MassTransit是你的男人.免费; 没有许可限制.如果你可以在没有流程设计师的情况下做到并且可以自己动手,那么你就无法击败它.它也可以位于RabbitMQ之上,MSMQ具有社区Azure插件.MassTranit + RabbitMQ已经证明自己是一个非常好的稳定环境,并且可以让您的消费者/生产者快速启动并运行. (11认同)
还要考虑EasyNetQ(围绕rabbitMQ的简单包装)惊讶的UDI在讨论中没有更多的权重与建议4良好的替代方案2 nServiceBus？我的意思是说.帮助民众在早期阶段的短信旅程.有许多好的简单(免费)方式2入门; 只要它容易且理想地免费,并不重要.(免费游戏,免费实施,以及随后自由改变)一旦你成长,你将开发你自己的关注列表; 在这一点上,一个更成熟的产品是一个简单的决定,简单的成本,例如nservicebus. (3认同)

Answer 3

Cip*_*anu 25

Rhino与NServicebus状态的更新:

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

InfoQ to Ayende: 您之前已经为.NET编写过服务总线,即Rhino Service Bus.Rhino Service Bus的用户现在应该重新考虑并转移到NServiceBus吗？

Ayende:我在2008年左右建造了Rhino Service Bus.我建造它主要是因为我对当时其他服务总线的状态不满意.在构建我的服务总线时,我有不同的顾虑和方向,但那是4年前.在那个时候,我认为NServiceBus在成为一个更容易使用的产品和拥有更好的开箱即用开发故事方面取得了很大进展.如果我今天开始使用服务总线,我强烈怀疑我是否会建立自己的服务.

Answer 4

qui*_*dry 9

任何基于MSMQ的潜在con是对最大消息大小的限制.IIRC大约4MB,如果您处理大文件并将文件内容存储在消息中,您可能很容易遇到这种情况.

在企业集成模式(Woolf,Hohpe)中,Claim Check模式专门解决了这个问题.对大型有效负载的引用仅保留在消息中,使消息保持较小.大的邮件大小会对邮件系统的吞吐量造成严重破坏. (32认同)
有趣的是,大多数基于云的队列甚至不支持100KB的有效载荷,因此未来很多应用都需要考虑这一点. (7认同)
这不是NServiceBus的问题,因为它们具有数据总线的概念,它可以透明地解决大小限制. (4认同)

归档时间：	16 年，8 月前
查看次数：	27604 次
最近记录：	7 年，5 月前