我试着了解NServiceBus如何在各种情况下扩展,但我没有找到足够的信息。
通常,在pub / sub场景中,与发送/接收场景相比,扩展NServiceBus(和底层传输)似乎不同。此外,消息发射系统是按比例缩放还是吸收"似乎有所不同。系统按比例缩小。
考虑使用MSMQ作为传输层和NServiceBus的设置,假设我们将使用队列MyQueue
作为从发射系统到吸收系统的通信通道(通过发送/接收或发布/分)。如何在以下方案中展开横向扩展设置?我试过在下面提出一些答案,但我不确定。
发射系统未缩放;吸收系统未缩放:这是一个简单的设置,两端有一个端点,接收器有一个单独的队列。
两个系统的订阅存储:MSMQ
发射系统未缩放;吸收系统缩放:吸收系统中的单个节点,即端点,被提升" as Distributor和许多工作节点从该单个分发节点获取消息。
如果吸收系统订阅或收到,它会有所不同吗?
分销商也可以扩大规模吗?
documentation建议使用单独的队列名称,但如果发送/发布系统应该关心天气接收系统是否已扩展,那么它是不是很麻烦?从发件人的角度来看,我认为接收者的横向扩展应该是透明的。
两个系统的订阅存储:MSMQ? 的位置存储了哪些订阅?在经销商处?
发射系统缩放;吸收系统未缩放:发射系统中的多个节点可以发送到未缩放的吸收系统,就像上面的未缩放/未缩放场景一样。但是,发射系统中的多个节点不能(或不应该)发布到同一个吸收系统?或者是什么?如何处理来自多个节点的发布?
两个系统的订阅存储:MSMQ?
发射系统缩放;吸收系统缩放:这只是发送/接收和发布/订阅模式的上述两种情况的组合吗?
两个系统的订阅存储:MSMQ?
简而言之,对于以上四种情况的推荐NServiceBus设置的概述可能会很好。
答案 0 :(得分:7)
首先,重要的是要意识到,如果要扩展MSMQ传输,NServiceBus中的分发器组件仅相关。其他支持的传输是代理并使用竞争的使用者模式来实现同样的结果。
其次,您需要了解 NServiceBus区分逻辑自治组件/端点及其物理部署。发送,发布或订阅时,仅使用端点的LOGICAL地址。逻辑地址通常与物理地址相同,但并非必须如此。服务只能有一个逻辑端点地址,但可以有多个物理部署。
在非缩放场景中,它是一回事。假设ServiceA
和ServiceB
已部署到计算机Machine1
。 ServiceA
的逻辑端点地址和物理地址为ServiceA@Machine1
。 ServiceB的逻辑地址和物理地址为ServiceB@Machine1
。
在缩小的情况下,这会有所不同。假设您将ServiceA
和ServiceB
实际部署到Machine1
和Machine2
。您还将ServiceA
和ServiceB
的两个分销商部署到第三台计算机MachineX
。 ServiceA
现在有一个逻辑端点地址ServiceA@MachineX
,但有两个物理地址:ServiceA@Machine1
和ServiceA@Machine2
。 ServiceB
还有一个逻辑端点地址ServiceB@MachineX
和两个物理地址:ServiceB@Machine1
和ServiceB@Machine2
。
进入分销商。这是一个简单的负载均衡器。它接收来自服务逻辑端点的传入消息,并将它们转发给其中一个物理端点/工作者。它将以循环方式执行此操作以分配负载。
使这项工作的诀窍始终是在发送,订阅或发布内容时使用您要访问的组件的逻辑端点地址。切勿直接使用各个端点部署的物理地址。
让我们来看一个简单的发送。 ServiceA
想要发送一些内容到ServiceB
。 ServiceA
上的Machine1
之一的物理端点将创建一条消息,并将其放入ServiceB
,ServiceB@MachineX
的逻辑地址中。该消息包含发件人的物理和逻辑端点地址。 ServiceB
MachineX
上的发布商会收到邮件并将其发送给ServiceB@Machine1
或ServiceB@Machine2
。而已。这就是经销商所做的一切。
订阅的工作方式相同。说ServiceA
想订阅ServiceB
个活动之一。 ServiceA
的一个物理端点将订阅消息发送到ServiceB
,ServiceB@MachineX
的逻辑端点地址。该邮件基本上包含以下“ServiceA
想要订阅event XXX
”。分发者会收集订阅消息并将其移交给ServiceB@Machine1
或ServiceB@Machine2
。幸运工作者查看消息并存储逻辑ServiceA
想要订阅event XXX
的事实。请注意,它存储逻辑端点地址,而不是发送订阅消息的ServiceA
物理部署的端点地址。 订阅存储属于逻辑ServiceB
端点,并在其所有物理部署之间共享。这排除了MSMQ作为存储。支持的商店是NHibernate或RavenDB。(对于具有原生发布/子支持的传输,有点不同,但这不是重点。)
发布类似。 ServiceB
想要发布XXX event
。 ServiceB
的一个物理部署查看订阅数据库以查找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存储的依赖性。发布时,您需要外部存储机制,并且必须在每次发布时查询此存储,并且有新订户。这有与之相关的开销。发布时,您应该通过主节点订阅,它将根据上述配置确定是否处理消息。
扩展发布商时,主人和工作人员都会与订阅存储通话并以循环方式执行发布。主节点知道工人是否正忙,负载将相应地分配。
如果正在交换的消息对其他端点不感兴趣,您可以考虑坚持使用点对点通信(发送)来消除与发布相关的开销。