我一直在进行SQL Server服务代理（Service Broker）的研发，以替换当前的消息传递方案MSMQ。 我想知道与以下标准相比，SQL Server服务代理的缺点。
SQL Server服务代理需要更多的编程工作来实现与MSMQ相同的功能。
SQL Server服务代理的错误信息不够详细，可能需要花费更多的时间进行故障排查。
对于大量的消息处理，MSMQ通常比SQL Server服务代理更快，并且可以更好地处理较大的消息。
SQL Server服务代理在处理大量消息时可能会出现性能问题，在这种情况下，MSMQ可能是更好的选择。
我在当前项目中使用了Service Broker，在此之前，我曾经非常成功地使用过由 MassTransit 管理的 MSMQ。一开始我对使用Service Broker持怀疑态度，但我必须承认它表现得非常出色。
如果你正在使用发布/订阅模式，那么每次都应该使用消息队列（虽然如果项目允许，我会使用RabbitMQ代替MSMQ），但是当你只想处理一堆数据并将其持久化到Sql Server时，Service Broker是一个很好的解决方案：它非常“接近金属”，这是一个巨大的优势。
开发
Service Broker需要大量样板代码，这很麻烦，但除非你计划有很多不同的队列，否则还是可以管理的。在Visual Studio中的Sql Server项目可以减轻部署的痛苦。
故障排除
Service Broker是一个黑盒子——消息进去了，通常也会出来，但如果它们没有出来，那么故障排除可能会有问题，你只能查询系统视图，有时你根本找不到出了什么问题。这很烦人，但MSMQ也有同样的问题。 性能 对于我们的使用情况，Service Broker的性能非常优秀（请参见下面的评论部分进行讨论）。我们每天处理的消息量超过10万条，SLA负载下每小时超过3万条，并且我们的消息大小很大。在重负载测试期间，我估计我们每小时处理接近10万条消息。为了获得最佳性能，我建议您使用类似于这个1的对话池，因为创建服务代理对话可能是一项昂贵的操作。
您还需要使用Remus Rusanu详细介绍的错误处理程序。(如果您确实使用服务代理，最好在开始之前阅读Remus在该主题上撰写的所有内容，因为您最终会阅读它！)
可扩展性
如果需要，您可以使用多台服务器进行扩展，尽管我们没有必要这样做，并且从您提到的负载大小来看，您也不需要这样做。
I don't think I have really managed to answer your question, as I haven't highlighted enough disadvantages of Service Broker queues. I would say the impenetrable nature of its internal workings is the thing that most annoys me - when it works, it works very well, but when it stops working it can be very hard to figure out why. Also, if you have a lot of messages in a queue, using
ALTER QUEUE takes a very long time to complete.