1

我们目前正在分销商/工人模型中设置 nServiceBus，我想知道这对我们来说是否真的值得。

在我们最初的测试实验室中，我有 2 个集群分销商和一个工人（更多工人在生产中）。我想知道的是，利用我们的高可用性 SQL Server 进行存储并重建服务器以全部处理工作而不是拥有专门的分销商和工作人员是否同样有效。我们所有的消息都通过一个简单的 .Net Web API 服务进入总线。我可以将该服务与端点 dll 一起安装在每个盒子上，并让它们都与 SQL 服务器对话，该服务器具有足够的能力来处理负载。我们有一个负载均衡器可用于将消息分发给处理程序。

与分销商模式相比，采用这种方法会有哪些缺点？

我担心的是大卫·博伊克关于 nServiceBus 的书（顺便说一句很棒的书）中的一句话……

“对于已经使用 SQL Server 的团队中的小型项目来说，将 SQL Server 用作传输工具可能是一个不错的选择”

小项目部分是我担心的。这绝不是一个小项目，随着我们将更多系统重构为消息驱动，它将有大量消息流过这一层。

有没有人在比较 SQL Server 和分销商的道路上走同样的路，你从哪里出来的？

谢谢

4

1 回答 1

2

我在书中提到的引用是指有时您有一个相当小的解决方案，所有这些都在一个 SQL Server 数据库中，并且您想在边缘引入一些消息传递。SQL Server 传输可以轻松地做到这一点，而无需增加大量额外的开销和移动部件。如果您将所有内容都保存在一个数据库中，您甚至可以放弃分布式事务协调器。它对于与您通过数据库触发器监视更改的遗留系统集成也非常有用。

但是，请记住（如果有下一版，我一定会对此进行更详细的介绍）SQL Server 传输使用代理模式，也就是说，所有通信都必须通过 SQL Server，所以它成为故障的中心点和中心瓶颈。另一方面，默认的 MSMQ 传输遵循总线架构风格，这意味着它是完全分散的。每个端点都可以完全独立运行，至少在您引入其他依赖项之前是这样。

Andreas对新的传输进行了基准测试，发现在 V4 上 MSMQ 能够大约每秒 6000 次发送和每秒 2300 次接收，而 SqlServer 与此相当，但在 MSMQ 上大约是每台服务器（每台服务器都有自己的吞吐量)，SQL Server 传输将成为您可实现的总吞吐量，period以及您添加的任何端点都必须共享它。

当然，代理式传输（4.0 中的其他新传输也是代理）确实比 MSMQ 有一些优势。最大的是不需要使用 Distributor 来横向扩展。在代理中，“队列”是集中的，因此您可以在竞争消费者模式中简单地启动指向同一输入队列的其他端点。

当然，与所有事情一样，您的里程可能会有所不同，但是如果您正在计划一个雄心勃勃的系统，那么 SQL Server 传输可能不适合您，因为您有时会陷入困境，您唯一的选择就是扩展您的 SQL Server 实例。

于 2013-10-07T19:21:50.223 回答