NServiceBus集群worker/Distributor使用

Question

当前设置

我们有一个 UI(远远超过 1 个 UI，但这不相关)，并且我们有 2 个负载平衡的应用服务器。这样的 UI 将与一个别名进行通信，该别名后面是 2 个负载均衡器应用服务器。应用程序服务器也是自托管 NServiceBus 端点。处理当前请求的应用服务器(可以是应用服务器 1 或应用服务器 2 )能够使用自托管 NServiceBus 执行以下操作:

• 在本地发送消息(这是一个可以在任何时间运行的计算)时间，谁触发它并不重要，它只是一个触发器进行计算)
• 在辅助设备上向发布者发送命令Service Box(发布者向 Worker 1 和 Worker 2 推送新事件)
• 直接在辅助服务箱上向工作人员 1 发送命令
• 直接在辅助服务盒上向工作人员 2 发送命令

“应用程序服务器”当前 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>

“发布者”当前的 App.Config

当前为“发布者”App.Config

<UnicastBusConfig ForwardReceivedMessagesTo="audit">
  <MessageEndpointMappings>
  </MessageEndpointMappings>
</UnicastBusConfig>

“Worker(s)”当前 App.Config

目前，worker App.Configs 只需订阅另一个端点“Publisher”，它们的配置文件如下所示:

<UnicastBusConfig ForwardReceivedMessagesTo="audit">
  <MessageEndpointMappings>
    <add Assembly="Messages" Type="SomeEvent" Endpoint="Publisher" />
  </MessageEndpointMappings>
</UnicastBusConfig>

现在发送给工作人员的所有其他消息都直接来自其中一个应用服务器，如上面应用服务器的 App.Config 所示。

一切正常。

问题是我们存在单点故障，如果“辅助服务盒”失效，我们就会被塞满。

所以我们想知道是否可以利用多个“辅助服务箱(每个都有一个 Publishers/Worker1/Worker2)”。理想情况下，它们的工作方式与上述完全一致，如上图所示。如果“辅助服务框 1”可用，则使用“辅助服务框 1”，否则我们使用“辅助服务框 2”

我已经阅读了有关分发器的内容(但没有使用它)，如果我正确的话，我们可以在应用程序服务器本身中使用它，我们将每个应用程序服务器视为分发器和工作人员(对于我们需要执行 SendLocal 命令(RunCalculationCommand)的情况，我们需要运行)。

“辅助服务盒”必须为每个包含的端点使用分发器:

所以我们最终可能会得到这样的结果:

有人可以帮助我知道我是否以正确的方式思考这个问题，或者我是否偏离了方向。

我想知道的是:

• 分销商的使用方法是否正确？
• 工作人员/发布者配置会是什么样子，他们必须以某种方式进行更改以指向发布者编号？正如我现在所说，应用程序服务器直接向工作程序发送消息，应用程序服务器配置具有工作程序端点地址，并且工作程序仅设置为指向发布者
• 应用程序服务器配置是什么样的？这会停止直接发送给发布者/工作人员吗？
• 发布商配置是什么样的？这应该指向经销商吗？

Answer 1

分发器在这里是一个很好的方法，但它的代价是增加了基础设施的复杂性。为了避免引入另一个单点故障，分发器及其队列必须在 Windows 故障转移群集上运行。这意味着 MSMQ 和 DTC 都必须配置为集群服务。这真是太有趣了..:D

我已将您所说的“worker”重命名为端点，从 Worker1 重命名为 Endpoint1，将 Worker2 重命名为 Endpoint2。这是因为当您介绍分销商时，“ worker ”被非常明确地定义为特定的事物。机器上从分发器接收消息的实际物理端点是工作线程。因此 Endpoint1@ServicesMachine01、Endpoint2@ServicesMachine02 等都是工作人员。 worker 从经销商处获得工作。

场景01

在第一个场景中，您会看到应用服务器从负载均衡器获取请求并将其发送到分发器上的 Endpoint1@Cluster01 或 Endpoint2@Cluster01 队列，具体取决于命令。这然后分发器在该队列中找到一个准备好接收消息的工作线程，并将命令发送给它。因此，对于 WorkerCommand1，Endpoint1@ServicesBox01 或 Endpoint1@ServicesBox02 最终会得到来自分发器的命令并正常处理。

场景02

在场景二中，情况几乎相同。 PublishCommand 发送到 Endpoint3@Cluster01。它选择一个准备好的 Endpoint3，在本例中为 Endpoint3@ServicesBox02，并为其提供命令。ServiceBox02 处理消息并将 SomeEvent 发布到 Endpoint01@Cluster01 并端点02@Cluster01。这些由经销商拾取并在本例中发送至端点1@ServiceBox01 和端点2@ServiceBoxN。

请注意消息如何始终流经 Cluster01 上的分发器和队列。这是MSMQ的实际负载均衡。

应用服务器配置发生更改，以确保命令通过集群。

<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 配置略有更改，以确保订阅也通过分销商进行。

<UnicastBusConfig ForwardReceivedMessagesTo="audit">
  <MessageEndpointMappings>
    <add Assembly="Messages" Type="SomeEvent" Endpoint="Endpoint3@Cluster01" />
  </MessageEndpointMappings>
</UnicastBusConfig>

发布者配置没有更改。它不需要指向任何内容。订阅者将告诉它在哪里发布。