如何在两端扩展NServiceBus?

时间:2015-08-06 15:17:58

标签: .net msmq nservicebus

我试着了解NServiceBus如何在各种情况下扩展,但我没有找到足够的信息。

通常,在pub / sub场景中,与发送/接收场景相比,扩展NServiceBus(和底层传输)似乎不同。此外,消息发射系统是按比例缩放还是吸收"似乎有所不同。系统按比例缩小。

考虑使用MSMQ作为传输层和NServiceBus的设置,假设我们将使用队列MyQueue作为从发射系统到吸收系统的通信通道(通过发送/接收或发布/分)。如何在以下方案中展开横向扩展设置?我试过在下面提出一些答案,但我不确定。

  • 发射系统未缩放;吸收系统未缩放:这是一个简单的设置,两端有一个端点,接收器有一个单独的队列。

    两个系统的订阅存储:MSMQ

  • 发射系统未缩放;吸收系统缩放:吸收系统中的单个节点,即端点,被提升" as Distributor和许多工作节点从该单个分发节点获取消息。

    如果吸收系统订阅收到,它会有所不同吗?

    分销商也可以扩大规模吗?

    documentation建议使用单独的队列名称,但如果发送/发布系统应该关心天气接收系统是否已扩展,那么它是不是很麻烦?从发件人的角度来看,我认为接收者的横向扩展应该是透明的。

    两个系统的订阅存储:MSMQ? 的位置存储了哪些订阅?在经销商处?

  • 发射系统缩放;吸收系统未缩放:发射系统中的多个节点可以发送到未缩放的吸收系统,就像上面的未缩放/未缩放场景一样。但是,发射系统中的多个节点不能(或不应该)发布到同一个吸收系统?或者是什么?如何处理来自多个节点的发布

    两个系统的订阅存储:MSMQ?

  • 发射系统缩放;吸收系统缩放:这只是发送/接收和发布/订阅模式的上述两种情况的组合吗?

    两个系统的订阅存储:MSMQ?

简而言之,对于以上四种情况的推荐NServiceBus设置的概述可能会很好。

2 个答案:

答案 0 :(得分:7)

首先,重要的是要意识到,如果要扩展MSMQ传输,NServiceBus中的分发器组件仅相关。其他支持的传输是代理并使用竞争的使用者模式来实现同样的结果。

其次,您需要了解 NServiceBus区分逻辑自治组件/端点及其物理部署。发送,发布或订阅时,仅使用端点的LOGICAL地址。逻辑地址通常与物理地址相同,但并非必须如此。服务只能有一个逻辑端点地址,但可以有多个物理部署。

在非缩放场景中,它是一回事。假设ServiceAServiceB已部署到计算机Machine1ServiceA的逻辑端点地址和物理地址为ServiceA@Machine1。 ServiceB的逻辑地址和物理地址为ServiceB@Machine1

在缩小的情况下,这会有所不同。假设您将ServiceAServiceB实际部署到Machine1Machine2。您还将ServiceAServiceB的两个分销商部署到第三台计算机MachineXServiceA现在有一个逻辑端点地址ServiceA@MachineX,但有两个物理地址:ServiceA@Machine1ServiceA@Machine2ServiceB还有一个逻辑端点地址ServiceB@MachineX和两个物理地址:ServiceB@Machine1ServiceB@Machine2

进入分销商。这是一个简单的负载均衡器。它接收来自服务逻辑端点的传入消息,并将它们转发给其中一个物理端点/工作者。它将以循环方式执行此操作以分配负载。

使这项工作的诀窍始终是在发送,订阅或发布内容时使用您要访问的组件的逻辑端点地址。切勿直接使用各个端点部署的物理地址。

让我们来看一个简单的发送。 ServiceA想要发送一些内容到ServiceBServiceA上的Machine1之一的物理端点将创建一条消息,并将其放入ServiceBServiceB@MachineX的逻辑地址中。该消息包含发件人的物理和逻辑端点地址。 ServiceB MachineX上的发布商会收到邮件并将其发送给ServiceB@Machine1ServiceB@Machine2。而已。这就是经销商所做的一切。

订阅的工作方式相同。ServiceA想订阅ServiceB个活动之一。 ServiceA的一个物理端点将订阅消息发送到ServiceBServiceB@MachineX的逻辑端点地址。该邮件基本上包含以下“ServiceA想要订阅event XXX”。分发者会收集订阅消息并将其移交给ServiceB@Machine1ServiceB@Machine2。幸运工作者查看消息并存储逻辑ServiceA想要订阅event XXX的事实。请注意,它存储逻辑端点地址,而不是发送订阅消息的ServiceA物理部署的端点地址。 订阅存储属于逻辑ServiceB端点,并在其所有物理部署之间共享。这排除了MSMQ作为存储。支持的商店是NHibernate或RavenDB。(对于具有原生发布/子支持的传输,有点不同,但这不是重点。)

发布类似。 ServiceB想要发布XXX eventServiceB的一个物理部署查看订阅数据库以查找event XXX的订阅。它看到ServiceA@MachineX处的逻辑端点地址对该事件感兴趣。然后它将事件放在该队列上。 ServiceA上的MachineX分发者收到邮件并将其分发给其中一名工作人员。

分发服务器本身无法扩展,但如果您没有高度可用,则会成为单点故障。 The recommendation is to use a Windows Failover Cluster代表经销商及其MSMQ。

还有MasterNode的概念。将其视为Distributor和Worker在同一物理过程中运行,以优化托管Windows故障转移群集的计算机上的资源使用情况。以上所有内容仍然适用于MasterNode。

答案 1 :(得分:1)

您可以将Worker节点添加到任何NServiceBus端点。必须做出的选择是主节点是否也处理消息。根据您的情况,您可以选择其中之一。分发服务器角色用于主节点未处理消息但充当调度程序的方案中。

使用Send vs. Publish的主要区别在于对Subscription存储的依赖性。发布时,您需要外部存储机制,并且必须在每次发布时查询此存储,并且有新订户。这有与之相关的开销。发布时,您应该通过主节点订阅,它将根据上述配置确定是否处理消息。

扩展发布商时,主人和工作人员都会与订阅存储通话并以循环方式执行发布。主节点知道工人是否正忙,负载将相应地分配。

如果正在交换的消息对其他端点不感兴趣,您可以考虑坚持使用点对点通信(发送)来消除与发布相关的开销。