进程间消息传递 - MSMQ，Service Broker，？

Question

我正处于.NET服务的规划阶段，它不断处理传入的消息，涉及各种转换，数据库插入和更新等。整体而言，服务庞大而复杂，但它执行的各项任务小，简单，定义明确。

由于这个原因，并且为了以后允许轻松扩展，我想将服务拆分为几个较小的服务，这些服务基本上执行部分处理，然后将其传递到链中的下一个服务。

为了实现这一点，我需要一种将消息从一个服务传递到另一个服务的中间消息传递系统。我希望这种情况发生，如果链中的链接崩溃或短暂脱机，消息将开始排队并在目标重新​​联机后进行处理。

我总是使用消息队列来处理这类事情，但最近已经知道SQL Service Broker似乎做了类似的事情。 SQLSB是否适用于此方案，如果是这样，我会通过使用它而不是标准消息队列来看到任何性能优势吗？

由于

Answer 1

听起来像你可能是在服务总线架构之后。这将为您提供您正在寻找的协调和容错。我最熟悉和偏爱NServiceBus，但还有其他包括Mass Transit和Rhino Service Bus。

Answer 2

如果大多数这些步骤从数据库状态启动并最终在数据库更新中结束，那么将消息存储与数据存储合并非常有意义：

• 要备份/恢复的单个产品
• 一致的状态备份
• 单一高可用性/灾难恢复性解决方案（数据库镜像，群集，日志传送等）
• 数据库规模存储（IO功能，大小和容量限制等，根据数据库产品特性，而不是消息存储产品的限制）。
• 用于调整，排查和管理的单个产品

此外，还有一些严重的性能考虑因素，因为让您的消息存储与数据存储相同意味着您不需要对每个消息交互进行两阶段提交。使用单独的消息存储要求您将消息存储库和数据存储库注册到分布式事务中（即使它位于同一台计算机上），这需要两阶段提交，并且比单独的数据库事务单阶段提交慢得多。

此外，在数据库中使用消息存储而不是外部消息存储具有可查询性等优点（在消息队列上运行SELECT）。

现在，如果我们将数据库中的抽象术语'消息存储库转换为Service Broker而将'非数据库消息存储'转换为MSMQ，您可以看到我的观点，为什么SSB将在MSMQ周围运行圈。

Answer 3

我最近使用这两种方法的经验（从Sql Server Service Broker开始）使我陷入了这样的境地，即我从SQL服务器中获取消息。问题是准政治问题，但您可能需要考虑它：我的组织中的SQL服务器由专业DBA管理，而应用程序服务器（即NServiceBus之类的消息传递）由开发人员和网络团队管理。对数据库服务器的任何更改都需要DBA进行痛苦的性能分析，并且担心我们可能会因为位于同一空间的排队引擎而失去标准的SQL职责。

SSSB很难管理（与消息传递中间件不同），但不同之处在于我更容易在消息传递世界中搞砸一些事情（可能发生的最糟糕的事情是某些消息堆积在某处并且日志填满我无法承受SQL世界中的任何错误，客户交易数据存在并且对业务至关重要（包括遗留系统的数据）。我真的不想让那些“意外的数据库增长”或“等待时间提醒”或“为什么我的临时数据库不断增长而不再结束”电子邮件。

我了解到应用程序服务器很便宜。只需添加消息处理程序，添加机器......简单。几乎没有许可证费用。使用SQL服务器正好相反。在我看来，使用Service Broker进行消息传递就像使用昂贵的汽车来耕种马铃薯田。对其他事情来说要好得多。