当我参加 Microsoft 的 SQL Server 2008 演示文稿时，他们快速浏览了一下我们正在使用的功能。原来，整个报告厅里，只有我公司在使用Service Broker。这让我很惊讶，因为我认为会有更多的人使用它。
我对 SB 的经验是，它的工作做得很好，但管理起来非常困难，而且很难获得概览。
那么，您是否考虑过使用 Service Broker？如果不是，为什么不呢？你改用 MSMQ 了吗？SQL Server 2008 中是否有任何内容可以让您考虑使用 Service Broker。
在 SQL 2005 发布几个月后，我一直在使用 SQL Service Broker。我们在这里不间断地使用它，每天通过它发送数十万条消息。
我们使用它来将数据从临时表加载到生产表，这样加载临时表的服务就不必等待数据实际处理，它可以返回并获取更多数据来加载。
我们使用它来排队从文件系统中删除文件。（当行被删除时，文件也需要被删除。）
在以前的公司，我用它来打印贷款文件和发送给客户的支票。
我什至使用 Service Broker 进行从 OLTP 数据库到 OLAP 数据库的 ETL 以进行实时报告。
大多数人（尤其是 DBA）不喜欢 Service Broker，因为它没有任何 UI。如果您想使用服务代理或查看它在做什么，您必须实际编写和运行一些 T/SQL。
我在 2005 年使用 SB 大约两年了，其中一个实现每天处理数十万条消息。我想说最大的挑战不是架构，而是理解所涉及的所有细微差别。微软的文档很差，很少有实际的例子。Remus Rusanu 的博客在处理对话重用和激活存储过程调整等方面确实很有帮助。我发现尽可能多地重用对话框（并处理与之相关的所有相关锁定）以及将多个接收到的消息作为一组而不是一次处理一个是非常重要的。
监控 SB 可能会很痛苦。您基本上依靠一堆系统视图来告诉您发生了什么。孤立的消息是一种痛苦。有很多小陷阱可以，嗯，getcha。
除了问题，也没有那么多，我认为它确实比我预期的要好。由于 SB 已集成到数据库中，因此没有单独的消息队列可以在数据库之外进行备份。这一切在事务上都是一致的。性能很好。这是一个很好的解决方案。
我会再次使用它并将继续使用它。
在我现在的公司，我们对 SB 的使用与其他海报的使用有些不同。我们在SQL2005中主要使用SB作为管理工具。例如，我们使用它来管理对存在于大量其他不可变数据库中的一小组可变表的更新。所有消息都在同一实例上运行的服务之间，消息量非常低。
我对 SB 的经验是，正确设置可能有点“繁琐”，而且正如您在问题中提到的那样，由于没有单一的监控工具，因此很难对 SB 的状态进行概述。
尽管如此，我们发现它作为一种以可追溯和可靠的方式自动化大量数据库管理任务的方式非常有价值。
我最近考虑在一个项目中使用 Service Broker，但是是的，我决定改用 MSMQ。
我们的架构由许多（集群）服务器组成，每个服务器都需要将信息可靠地写入单个 SQL 实例。
据我了解，SB 仅适用于 SQL 到 SQL 的通信，因此我们需要在每个集群框上都有一个 SQL 实例。我们觉得这有点不必要，因此使用 MSMQ
老实说，我想不出我会使用 SB 的场景——我有兴趣更多地了解你的场景，看看我是否遗漏了一些重要的东西。
Service Broker 可用于需要在分布式架构中完成自动化的各种情况。此类应用程序从各种设备接收事件并需要可靠地完成处理。来自设备（检测）或传感器的事件用于处理自动化逻辑。在多个数据库或应用程序之间进行数据交换。
我希望SB的实施可以更加安全可靠