我正处于 .NET 服务的规划阶段，该服务不断处理传入的消息，其中涉及各种转换、数据库插入和更新等。作为一个整体，该服务庞大而复杂，但它执行的各个任务体积小、简单且定义明确。
出于这个原因，并且为了便于将来扩展，我想将服务拆分为几个较小的服务，这些服务基本上执行部分处理，然后再将其传递给链中的下一个服务。
为了实现这一点，我需要某种中间消息传递系统，它将消息从一个服务传递到另一个服务。我希望以这样一种方式发生这种情况，即如果链中的链接崩溃或短暂脱机，则消息将开始排队并在目的地恢复联机后得到处理。
我一直使用消息队列来处理这类事情，但最近才知道 SQL Service Broker 似乎做了类似的事情。 SQLSB 是否是这种情况下可行的替代方案，如果是，我是否会看到使用它而不是标准消息队列来获得任何性能优势？
谢谢
【问题讨论】：
标签： msmq message-queue messaging service-broker broker
我最近对这两种方法的体验（从 Sql Server Service Broker 开始）导致我哭泣着要从 SQL Server 中获取消息。这个问题是准政治的，但您可能想考虑一下：我组织中的 SQL 服务器由专门的 DBA 管理，而应用程序服务器（即 NServiceBus 等消息传递）由开发人员和网络团队管理。对数据库服务器的任何更改都需要 DBA 进行痛苦的性能分析，并且担心我们可能会因我们的队列引擎位于同一空间中而降低标准 SQL 职责。
SSSB 非常难以管理（与消息传递中间件不同），但不同之处在于我更允许在消息传递世界中搞砸一些事情（可能发生的最糟糕的情况是某处堆积了一堆消息并填满了日志） ) 并且我无法承受 SQL 世界中的任何错误，客户事务数据存在并且对业务至关重要（包括来自遗留系统的数据）。我真的不想再收到那些“意外的数据库增长”或“等待时间警报”或“为什么我的临时数据库不断增长”的电子邮件。
我了解到应用服务器很便宜。只需添加消息处理程序，添加机器......很容易。几乎没有许可证费用。使用 SQL Server 则完全相反。现在在我看来，使用 Service Broker 进行消息传递就像使用昂贵的汽车犁土豆地一样。对于其他事情来说，这要好得多。
【讨论】：
如果这些步骤中的大多数从数据库状态开始并以数据库更新结束，那么将消息存储与数据存储合并就很有意义：
此外，还有一些重要的性能考虑，因为让您的消息存储与数据存储相同意味着您不需要对每个消息交互进行两阶段提交。使用单独的消息存储需要您在分布式事务中注册消息存储和数据存储（即使在同一台机器上），这需要两阶段提交，并且比单独的数据库事务的单阶段提交慢得多。
此外，使用数据库中的消息存储而不是外部存储具有可查询性等优点（在消息队列上运行 SELECT）。
现在，如果我们将抽象术语“数据库中的消息存储”翻译为 Service Broker 并将“非数据库消息存储”翻译为 MSMQ，您就会明白为什么 SSB 会在 MSMQ 周围随时运行循环。
【讨论】：
在我看来，您可能喜欢服务总线架构。这将为您提供您正在寻找的协调和容错。我最熟悉和偏爱 NServiceBus，但还有其他的，包括 Mass Transit 和 Rhino Service Bus。
【讨论】：