nServiceBus,大众运输,Rhino服务总线还是其他?


104

只是快速了解可能使用消息传递系统来处理工作流程系统中良好分离的文件。

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

Answers:


71

我建议您不要采用手动解决方案,因为需要正确解决一堆有些困难的事情,例如如何处理事务,异常如何导致回滚,如何不断停止回滚(有毒消息),如何与长期运行的工作流集成在一起,以便使状态管理边界对齐等等。

您可能会需要某种持久的/事务性消息传递基础结构,因此,如果不使用MSMQ,您将只能在Microsoft平台上使用Service Broker或ActiveMQ之类的其他替代方法。MSMQ的优点是已经在所有Windows机器上安装了该服务,而Service Pack则没有。

在NServiceBus,Mass Transit和Rhino Service Bus之间进行选择时-这个Stackoverflow答案比较NServiceBus和MassTransit将是一个不错的起点。

在我们的3.1版本中,我们引入了NSB Studio-一组Visual Studio集成的建模工具,使您可以在更高的抽象级别上对系统进行建模,并自动为您完成NServiceBus的许多配置和初始化。我要说的是,这确实使扩展规模有利于NServiceBus。

希望能有所帮助。

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


25
犀牛服务巴士非常以城堡为中心。如果您不熟悉/不喜欢Castle作为应用程序体系结构的核心部分,则可能会有一些困难。NServiceBus和Mass Transit或与容器无关。NServiceBus带有一个“应用程序服务器”,该服务器可以处理代码的托管以及在将系统从开发人员过渡到测试人员到生产人员时更改活动的基础结构实现(例如内存,MSMQ和DB)。它还带有用于消息处理逻辑和长期运行过程的单元测试工具。我不相信MassTransit有这些。
Udi Dahan

35
可能值得注意的是,Udi是NServiceBus的作者,因此他的观点可能在这里有些偏颇。:)话虽如此,我完全同意,并出于与他相同的理由主张使用NServiceBus。
skb

8
@skb:同意!乌迪,在回答nservicebus问题时,您真的应该提供某种免责声明,尤其是这样的问题!
andy

14
我仍然习惯于人们正在发现不知道我创建了NServiceBus的事实
Udi Dahan 2010年

5
@UdiDahan:nServiceBus如何“开源”?未经许可就发布源代码以使用它并没有实现共享的开源精神。我完全支持您获得以销售软件为生的权利(我也这样做),但是我认为如果您不将解决方案(2.0版后)宣传为开源软件,它将更加准确。
埃里克·J

52

NServiceBus是一个很好的产品,但是要注意许可问题。正如作者希望的那样,它倾向于更改其许可政策。以旧许可证信息为例

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

免费版也有性能限制。

MassTransit是绝对免费的开源软件,没有任何限制,并且已获得Apache 2.0许可。

我没有使用Rhino服务总线


1
实际上,我们将提供版本3.1的新许可证,该许可证可让您免费在多台计算机上运行(尽管吞吐量较低)。
乌迪·达罕

11
MassTransit是您的男人。免费; 没有许可限制。如果没有流程设计师就可以做,并且可以自己动手做,那么您将无可匹敌。它也可以放在RabbitMQ之上,MSMQ具有社区Azure插件。MassTranit + RabbitMQ已被证明是一个出色的稳定环境,可以非常迅速地使您的消费者/生产者投入使用。
Bigtoe 2012年

3
还要考虑EasyNetQ(围绕RabbitMQ的简单包装器)。令人惊讶的UDI不会在讨论中提供更多建议,包括4个不错的选择2 nServiceBus?我的意思是说。在早期阶段帮助人们进行消息传递旅程。有很多好的简单(免费)方法2入门;只要简单易用且理想情况下免费,您使用的内容并不重要;(可以免费玩游戏,可以自由实现,也可以稍后自由更改)。一旦您成长了,就会开发自己的关注点列表;到那时,更简单的产品将是一个容易决定的事情,而且价格合理,例如nservicebus。
snowcode 2015年

从MassTransit 4.0版本开始,不再支持MSMQ(masstransit-project.com/MassTransit
MyGGaN

25

Rhino vs NServicebus状态的更新:

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

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

Ayende:我在2008年左右制造了Rhino Service Bus。之所以制造它,主要是因为我对当时其他服务总线的状态不满意。构建服务总线时,我有不同的担忧和方向,但这是4年前。在那段时间里,我认为NServiceBus在成为易于使用的产品和更好的开箱即用开发故事方面取得了长足的进步。如果我今天开始使用服务巴士,我强烈怀疑自己会自己建造。


9

基于MSMQ的任何潜在缺点都是对最大邮件大小的限制。IIRC大约为4MB,如果您要处理大文件并将文件内容存储在消息中,则可能会很容易碰到。


7
有趣的是,大多数基于云的队列甚至不支持100KB的有效负载,因此将来许多应用程序都需要考虑这一点。
Udi Dahan

32
在企业集成模式(Woolf,Hohpe)中,“索赔检查”模式专门解决了此问题。对大有效负载的引用仅保留在消息中,从而使消息较小。大型消息可能会对消息传递系统的吞吐量造成严重破坏。
克里斯·帕特森

4
对于NServiceBus而言,这不是问题,因为NServiceBus具有数据总线的概念,可以透明地解决大小限制。
哈立德·阿布哈克(2012年
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.