SQL Service Broker 作为 .net 的通用企业消息总线

Question

我需要用于发布者/订阅者功能的企业服务总线/消息队列解决方案。我知道存在很多... MSMQ、MS 系列、RabbitMQ、NServiceBus 等等等等...

我的一个要求是，在共享托管解决方案中，我可以保证存在的唯一依赖项是 SQL 2005 及更高版本...这将我直接引向 SQL Service Broker。

如果听起来我想将 ESB 功能硬塞到 SSB 中……我想我是……

我的问题是：有没有人知道位于 SQL Service Broker 之上并且已经提供大部分管道的 .NET API 或框架？

如果我使用纯 ADO.net，我可以通过调用存储过程将项目添加到队列中，但是：

1. 根据对话的性质，我会在每条消息中进行一次对话吗？
2. 如果是这样，我会丢失顺序消息处理吗？
3. 如何接收消息（我知道 t-SQL 中的接收语法），我是否在消息循环中重复调用存储过程来尝试 从队列中获取消息？
4. 或者我会一直等待吗？保持连接打开并永远执行存储过程？
5. SQL Service Broker 不支持独白对话，但我读到它们可以实现...

正是这些问题让我希望存在一个已经管理所有这些的 .net 解决方案。

Answer 1

曾尝试打包 WCF Transport Channel for SQL Server Service Broker，但是，afaik，是废弃软件。

但是NServiceBus 支持 Service Broker 作为传输方式，请参阅 Using NServiceBus and ServiceBroker.net 并且有 github 项目，例如 A simple wrapper API for SQL Service Broker and an ITransport plugin for NServiceBus。虽然不完全是主流，但确实存在一些支持和社区努力。

作为 ESB，我认为由于缺乏真正的 pub-sub 和广播，您会遇到问题。 SQL Server 2012 能够向多个目标发送消息，请参阅 How to Multicast messages with SQL Server Service Broker，但您仍然需要从头开始实施 pub-sub 基础结构（发布主题、订阅者等）。 MySpace 做到了这一点并且是一项重大的努力，请参阅Scale out SQL Server by using Reliable Messaging。我的观察涉及到 SSB 的低级直接使用，我从未使用过 NServiceBus，所以我无法判断它在 SSB 上抽象/公开单播/广播/多播/pub-sub 的效果如何。

至于你的具体问题，我推荐阅读Writing Service Broker Procedures和Reusing Conversations。