9

我目前正在设计一个最终希望迁移到 Windows Azure 的应用程序。然而，在短期内，它将在我自己托管的服务器上运行。

该应用程序涉及许多独立的 Web 应用程序——其中一些本质上是接收数据的 WCF 服务，而另一些则是供用户管理数据的站点。此外，需要有一个在后台运行的工作服务，它将以各种方式处理数据。

我非常热衷于为此使用解耦架构。理想情况下，我希望组件（即 Web 应用程序和工作服务）尽可能少地相互了解。似乎在这里使用消息队列将是最好的解决方案 - Web 应用程序可以将带有工作单元的消息排入队列，并且工作服务可以将它们挑选出来并根据需要进行处理。

但是，我想为此制定一套好的技术，记住我最终将迁移到 Azure，并希望在迁移到云时尽量减少我需要做的返工量. Azure 有一个内置的队列组件，看起来非常适合我的需求。我想做的是自己创造一些东西，它会尽可能地模仿这一点。

看起来有几个选项（我在 Windows 上使用 .NET，带有 SQL Server 2005 后端）——到目前为止我发现的选项是：

  • MSMQ
  • SQL Server 服务代理
  • 使用数据库表和一些存储过程滚动我自己

我想知道是否有人对此有任何建议 - 或者是否有人做过类似的事情并对要做/避免的事情提出建议。我意识到每种情况都是不同的，但在这种情况下，我认为我的排队要求非常通用，所以我很想听听其他人对最佳方式的想法。

提前致谢，

约翰

4

3 回答 3

18

如果您想到了 Azure，也许您应该直接从 Azure 开始，因为 API 和语义在 Azure 队列和任何 MSMQ 或 SSB 之间存在显着差异。

MSMQ 与 SSB 的 3048 米快速比较（我将把自定义表作为队列放在比较之外，因为它真的取决于你如何实现它......）

  • 部署：MSMQ 是一个 Windows 组件，SSB 是一个 SQL 组件。SSB 需要一个 SQL 实例来存储任何消息，因此断开连接的客户端需要访问一个实例（可以是 Express）。MSMQ 需要在客户端上部署 MSMQ（操作系统的一部分，但可选安装）。
  • 可编程性：MSMQ 提供了一个成熟的、受支持的 WCF 通道。SSB 在http://ssbwcf.codeplex.com仅提供一个实验性 WCF 通道
  • 性能：在事务模式下，SSB 将明显快于 MSMQ。如果让 MSMQ 在非事务模式下运行（尽力而为、无序、交付），MSMQ 会更快
  • 可查询性：SSB 队列可以被SELECTE -ed uppon（查看任何消息，完整的 SQL JOIN/WHERE/ORDER/GROUP 权力），MSMQ 队列可以被窥视（仅下一条消息）
  • 可恢复性：SSB 队列集成在数据库中，因此它们与数据库一起备份和恢复，与应用程序状态保持一致状态。MSMQ 队列在 NT 文件备份子系统中进行备份，因此为了保持备份同步（一致），队列和数据库必须暂停。
  • 事务（因为每个入队/出队总是伴随着数据库更新）：SSB 完全集成在 SQL 中，因此出队和入队是本地事务操作。MSMQ 是一个单独的 TM（事务管理器），因此 queue/dequeue 必须是分布式事务操作才能在事务中注册 SQL 和 MSMQ。
  • 管理和监控：两者都一样糟糕。什么工具都没有。
  • 相关消息处理：SSB 可以通过内置的对话组锁定阻止并发线程对相关消息的处理。
  • 事件驱动：SSB 有激活来启动存储过程，MSMQ 使用Windows 激活服务。相似的。由于 WAITFOR(RECEIVE) 和 MAX_QUEUE_READERS 的交互方式，SSB 虽然具有自我负载平衡能力。
  • 可用性：SSB 搭载 SQL Server 高可用性故事，它可以在集群环境或数据库镜像环境中工作。MSMQ 仅涉及 Windows 群集故事。作为 HA 解决方案，数据库镜像比集群便宜得多。

另外我要补充一点，SSB 和 MSMQ 在它们提供的原语级别上有很大的不同：SSB 原语是一个对话，而 MSMQ 原语是一个消息。想想 TCP 与 UDP 语义。

于 2009-08-27T00:27:24.600 回答
10

选择一个适合您或更适合您的环境的队列后端。@Remus 对 MSMQ 和 SSB 进行了很好的比较。MSMQ 将更容易实现，但有一些明显的限制，而 SSB 将感觉非常沉重，因为它位于频谱的另一端。

随心所欲
为了最大限度地减少应用程序的返工，将队列访问抽象为一个接口，然后为您最终决定使用的队列传输提供一个实现。当需要迁移到 Azure 或其他队列传输时，您只需提供接口的新实现。

您可以控制您希望如何与队列交互的语义，以从您的应用程序中提供一致的可用 API。

一个粗略的想法可能是：

interface IQueuedTransport
{
  void SendMessage(XmlDocument);
  XmlDocument ReceiveMessage();
}

public class MSMQTransport : IQueuedTransport {}
public class AzureQueueTransport : IQueuedTransport {}

您可能没有构建满足您需求的所有排队运输。如果您使用 Xml，请传递 xml。如果您在字节数组中工作，请传递字节数组。:)

祝你好运！
Z

于 2009-08-27T01:13:51.663 回答
0

使用 Win32邮槽。它们在单个服务器上是可靠的，易于实施，并且不需要任何额外的软件。

于 2011-03-02T23:28:16.200 回答