我正在处理.NET服务的计划阶段，该服务持续处理传入的消息，这涉及到各种转换，数据库插入和更新等。整体而言，服务非常庞大且复杂，但它执行的各项任务是小，简单，明确。为了这个原因，并且为了在将来容易扩展，我想将服务拆分成几个较小的服务，这些服务基本上在执行部分处理之前将其传递给链中的下一个服务。进程间消息传递 - MSMQ，Service Broker，？
为了达到这个目标，我需要某种中介消息系统，将消息从一个服务传递到另一个服务。我希望这种情况发生的方式是，如果链中的链接崩溃或短暂脱机，则消息将开始排队并在目标恢复联机后进行处理。
我一直使用消息队列来处理这种类型的事情，但最近已经意识到SQL Service Broker似乎做了类似的事情。 SQLSB是否可以替代这种情况？如果是这样，我可以通过使用它而不是标准的消息队列来看到任何性能优势吗？
谢谢
如果大部分的步骤从数据库状态开始并在数据库中更新结束，然后用您的数据存储合并的消息存储使有很大的意义：
另外也有严重的性能方面的考虑，因为有你的邮件存储相同的数据存储意味着你不能做两阶段提交要求对每个消息的交互。使用单独的消息存储库要求您将消息存储库和数据存储库注册到分布式事务中（即使在同一台机器上），这需要两阶段提交，并且比仅执行数据库事务的单阶段提交慢得多。
另外在数据库中使用消息存储而不是外部消息存储具有诸如可查询性（在消息队列上运行SELECT）的优点。
现在，如果我们将数据库中的抽象术语“消息存储库”翻译为Service Broker和“非数据库消息存储库”作为MSMQ，那么您可以看到我的观点，为什么SSB将在任何时候围绕MSMQ运行圆圈。
这听起来像你可能是服务总线架构后。这将为您提供您正在寻找的协调和容错能力。我对NServiceBus最为熟悉和偏爱，但还有其他的包括公交和犀牛服务总线。
我最近使用这两种方法的经验（从Sql Server Service Broker开始）导致了我为了从SQL服务器获取消息而哭泣的情况。问题是准政治的，但您可能需要考虑：我的组织中的SQL服务器由开发人员和网络团队的专用DBA管理，而应用程序服务器（即消息像NServiceBus）。对数据库服务器的任何更改都需要DBA进行痛苦的性能分析，并且担心我们可能会因为排队引擎生活在同一空间而导致标准的SQL职责下降。
SSSB很难管理（与消息传递中间件不同），但不同之处在于，我更容易在消息传递世界中搞砸了一些东西（可能发生的最糟糕的是一些消息堆积在某处并记录日志），而且我无法承受SQL世界中的任何错误，因为客户交易数据存在并且对业务（包括来自传统系统的数据）至关重要。我真的不想让那些“意外的数据库增长”或“等待时间提醒”或“为什么我的临时数据库不再增长”电子邮件。
我了解到，应用程序服务器很便宜。只需添加消息处理程序，添加机器...很简单。几乎没有许可证费用。与SQL服务器完全相反。现在看来，使用Service Broker进行消息传递就像使用昂贵的汽车来耕种马铃薯田。对其他事情来说好多了。