当前设置
我们有一个用户界面(超过1个UI,但这不相关),我们有2个负载均衡的应用服务器。这样的UI将与别名对话,后面是2个负载均衡器应用服务器。 应用服务器也是自托管NServiceBus端点。处理当前请求的应用服务器(可能是App Server 1或App Server 2)能够使用自托管的NServiceBus执行以下操作:
"应用服务器"当前App.Config
因此,每个应用服务器的App.Config都有类似的内容
<UnicastBusConfig ForwardReceivedMessagesTo="audit">
<MessageEndpointMappings>
<add Assembly="Messages" Type="PublisherCommand" Endpoint="Publisher" />
<add Assembly="Messages" Type=" Worker1Command" Endpoint="Worker1" />
<add Assembly="Messages" Type=" Worker2Command" Endpoint="Worker2" />
<!-- This one is sent locally only -->
<add Assembly=" Messages" Type="RunCalculationCommand" Endpoint="Dealing" />
</MessageEndpointMappings>
</UnicastBusConfig>
&#13;
“发布商”当前App.Config
目前“发布者”App.Config
<UnicastBusConfig ForwardReceivedMessagesTo="audit">
<MessageEndpointMappings>
</MessageEndpointMappings>
</UnicastBusConfig>
&#13;
“工人”当前的App.Config
目前工作者App.Configs目前只需订阅另一个端点“Publisher”,他们的配置文件如下所示:
<UnicastBusConfig ForwardReceivedMessagesTo="audit">
<MessageEndpointMappings>
<add Assembly="Messages" Type="SomeEvent" Endpoint="Publisher" />
</MessageEndpointMappings>
</UnicastBusConfig>
&#13;
现在向工作人员发送的所有其他消息都直接来自其中一个应用服务器,如上面App.Config中针对应用服务器所示。
这一切都正常。
我们只有一点失败,如果“辅助服务盒”死亡,我们就会被塞满。
所以我们想知道我们是否可以使用多个“辅助服务盒(每个都有一个Publishers / Worker1 / Worker2)”。理想情况下,它们将完全按照上述方式工作,如上图所示。如果“辅助服务箱1”可用,则使用,否则我们使用“辅助服务箱2”
我已经阅读了有关分销商(但未使用它)的信息,如果我说的正确,我们可以在AppServer本身使用,我们将每个AppServer视为分销商和工人(对于我们需要执行SendLocal命令(RunCalculationCommand)我们需要运行的情况。)
如果“辅助服务盒”必须使用每个包含端点的分销商:
所以我们最终会得到这样的结论:
有人可以帮助我知道我是否正在考虑这种方式,或者我是否离开了。
基本上我想知道的是:
答案 0 :(得分:5)
分销商在这里是一个很好的方法,但它的代价是增加了基础设施的复杂性。为避免引入另一个单点故障,分发服务器及其队列必须在Windows故障转移Cluser上运行。这意味着必须将MSMQ和DTC配置为群集服务。这可以是非常有趣的..:D
我已将您称为“worker”的内容重命名为端点,从Worker1到Endpoint1,将Worker2重命名为Endpoint2。这是因为当您介绍经销商时,“工人”被非常明确地定义为特定的东西。正在从分发者接收消息的机器上的实际物理端点是工作者。因此,Endpoint1 @ ServicesMachine01,Endpoint2 @ ServicesMachine02等都是工作人员。工人从经销商处获得工作。
在第一个场景中,您会看到应用服务器从负载均衡器获取请求并将其发送给 分发服务器上的Endpoint1 @ Cluster01或Endpoint2 @ Cluster01队列,具体取决于命令。该 然后,分配器在该队列中找到一个准备工作的消息,并将命令发送给它。 因此,对于WorkerCommand1,EITHER Endpoint1 @ ServicesBox01或Endpoint1 @ ServicesBox02最终得到 来自经销商的命令并正常处理。
在情景二中它几乎是一样的。 PublishCommand被发送到Endpoint3 @ Cluster01。它 选择一个准备好的Endpoint3,在本例中为Endpoint3 @ ServicesBox02,并为其提供命令。 ServiceBox02处理消息并将SomeEvent发布到Endpoint01 @ Cluster01和 Endpoint02 @ Cluster01。这些由经销商接收,在这种情况下发送给 Endpoint1 @ ServiceBox01和Endpoint2 @ ServiceBoxN。
注意消息总是通过分发器和Cluster01上的队列流动。这是 MSMQ的实际负载平衡。
配置app server 更改以确保命令通过群集。
<UnicastBusConfig ForwardReceivedMessagesTo="audit">
<MessageEndpointMappings>
<add Assembly="Messages" Type="PublisherCommand" Endpoint="Endpoint3@Cluster01" />
<add Assembly="Messages" Type="Worker1Command" Endpoint="Endpoint1@Cluster01" />
<add Assembly="Messages" Type="Worker2Command" Endpoint="Endpoint2@Cluster01" />
<!-- This one is sent locally only -->
<add Assembly=" Messages" Type="RunCalculationCommand" Endpoint="Dealing" />
</MessageEndpointMappings>
</UnicastBusConfig>
ServicesBox config 略有变化,以确保订阅也通过分发服务器。
<UnicastBusConfig ForwardReceivedMessagesTo="audit">
<MessageEndpointMappings>
<add Assembly="Messages" Type="SomeEvent" Endpoint="Endpoint3@Cluster01" />
</MessageEndpointMappings>
</UnicastBusConfig>
发布商配置无变化。不需要指向任何内容。订阅者将告诉它在哪里发布。