不使用 MSMQ 的 NServiceBus 替代品答案

【问题标题】：Alternatives to NServiceBus that doesn't use MSMQ不使用 MSMQ 的 NServiceBus 替代品
【发布时间】：2010-12-01 14:46:04
【问题描述】：

我认为标题总结了一切......我们有一个 .NET 2.0 系统试图实现分布式发布/订阅模型。我遇到了 NServiceBus、RhinoBus 和 MassTransit。不幸的是，这些都是基于 MSMQ 的。我的任务是找出使用不同消息传递替代方案的 pub/sub 替代方案......

寻求 MSMQ 替代方案的唯一原因是克服消息大小限制。由于每条消息的限制，我们的企业应用消息可能会被截断......

非常感谢任何指导

【问题讨论】：

【解决方案1】：

NServiceBus 有一个Roadmap，表示他们打算提供更可插拔的传输以允许替代 MSMQ。

MassTransit 还表示他们的目标是支持替代方案。

不幸的是，这些都还没有。

【讨论】：

【解决方案2】：

我为此使用了几个数据库表。

【讨论】：

当然可以。我使用数据库表作为持久队列以避免必须使用 MSMQ。即使有多个读者和作者，它也能很好地工作。数据库事务提供并发控制。它们还在系统崩溃的情况下提供持久性。
我必须同意。我们从一家主要零售商那里取出了一个 BizTalk 实现，并用我认为是三个 SQL Server 表来替换它。更简单更便宜。显然，他们并没有使用 BizTalk 的所有功能。

【解决方案3】：

如果您有预算，您可以随时使用 Biztalk。

如果您想做一些更有趣的事情，您可以使用 Microsoft Azure 服务总线http://www.microsoft.com/azure/servicebus.mspx

您可以使用 SQL 服务代理 http://msdn.microsoft.com/en-us/library/ms345108(SQL.90).aspx 。不确定是否有计划停止这种功能。

或者，如果您想要最简单的方法，请使用 sql 表 :)

【讨论】：

您的建议似乎很激进； NServiceBus 被宣传为在服务器之间同步和/或加载 InProc 缓存的平台。查看 Udi Dahan 的博客。 Azure 和 BizTalk 是系统间消息传递平台；又名 EDI 和前者往返于 Microsoft ... :) MSMQ 不是可扩展且可靠的企业解决方案。它非常适合小型数据包移动，但不适用于企业级数据。从影响操作系统的主磁盘碎片、操作系统锁定到消息截断，挑战各不相同。 SQLCE 是一种选择，但已被证明是 InProc 活动的性能瓶颈。
是的，我同意这有点激进，只是为了让您了解所有选项。如果您正在查看 SQLCE，您是否正在研究移动设备？如果是这样，请查看 Microsoft Sync Framework msdn.microsoft.com/en-us/sync/default.aspx
@G33kKahuna：“MSMQ 不是一个可扩展且可靠的企业解决方案”——您为什么这么认为？你能指出我正确的方向吗？表明它的极限是什么？我目前正在评估 MSMQ 是否适合某个项目，如果了解更多信息会很好。
G33kKahuna - NServiceBus 不仅如此。请参阅 NServiceBus.com 站点。我不同意 MSMQ 不能像我所做的那样进行扩展，而且它非常可靠（取决于您放置在其下的 IO 的可靠性）。
你能回答stackoverflow.com/questions/9483286/…吗？

【解决方案4】：

如果您对“经纪人”类型的方法感到满意，我目前正在查看http://wso2.com/products/enterprise-service-bus/ ??

【讨论】：

【解决方案5】：

嘿，老问题，但值得一提的是，NServiceBus 现在正在支持 ActiveMQ（作为一种替代方案）与其他正在开发中的。也有人说要实现“数据总线”来克服消息大小限制，但我不知道它的状态。

基础设施已经到位，可以插入不同的传输，我记得看到过关于使用 Sql Server Service Broker 的讨论，但我不知道这是否超出了最初的讨论范围。

【讨论】：

【解决方案6】：

我目前正在开发基于开源 WCF 的服务总线。你可以在这里找到它：http://rockbus.codeplex.com/。它支持动态（@run-time）订阅、订阅存储库（数据库）、可插入传输、基于 XPath 的基于内容的路由、基于 wcf 协议的事务交付、循环交付、可插入订阅评估等。看看吧！

【讨论】：

【解决方案7】：

老问题，但值得提供一个最新的答案。对于那些开发企业级应用程序的人来说，Windows Azure 服务总线自问世以来确实取得了长足的进步，对于任何对实现发布/订阅模型感兴趣的人来说，它都值得仔细研究。以下是 Windows Azure 服务总线的一些亮点...

包括一个Windows Azure Tools SDK for .Net，它可以让任何 .Net 语言的开发变得非常容易。
Explorer Tool 是一个 GUI 界面，可以轻松管理和测试您的队列。一个版本直接内置在 Visual Studio 中，另一个版本是独立应用程序。
包含三种消息传递模型
- 中继 - 旨在在本地应用程序和云应用程序之间进行通信
- Pub/Sub - 在 Azure 中称为“主题”，它提供消息传递的发布/订阅模型。
- 代理消息传递 - 发送方和接收方不必同时在线的解耦消息传递。
支持事务行为（保证消息传递）
最重要的是，微软看到了云计算的未来，所以这只会变得更好。
该技术的最大缺点是 Windows Azure 是为大型企业环境设计的，因此非常昂贵。

这是一个很好的网站，提供了有关Windows Azure Service Bus 最新功能的更多详细信息

顺便说一句：我与 Micrsoft 没有任何关系。我刚从使用 NServiceBus 的背景中走出来，发现转换到 Windows Azure 服务总线非常容易，因为模型相似。

【讨论】：