根据端点可用性重定向 NServiceBus 消息
Redirect NServiceBus message based on Endpoint availability
我是 NServiceBus 的新手，但目前使用它与 SQL 服务器传输在三台机器之间发送消息：一台属于名为 Server 的端点，两台属于名为 Server 的端点Agent。这按预期工作，发送到 Agent 端点的消息通过默认循环法分发到两台机器中的一台。
我现在想添加一个名为 PriorityAgent 的新端点，它具有不同的队列和另外两台机器。虽然所有端点都使用相同的消息类型，但我知道在发送每条消息之前应该在哪里处理它，所以通常我只需选择正确的目标端点，消息就会得到相应的处理。
但是，我需要在一个特殊情况下构建：如果 PriorityAgent 端点上的所有机器当前都已关闭，则通常应该发送到那里的消息应该发送到 Agent 端点，因此可以立即处理它们。另一方面，如果 Agent 端点上的所有机器当前都已关闭，则不应将任何 Agent 消息发送到 PriorityAgent，它们可以简单地等待 Agent 机器至 return.
我一直在研究实现这个的正确方法，但没有看到很多结果。我想这不是闻所未闻的情况，所以我的假设是我正在寻找错误的东西或以错误的方式思考这个问题。尽管如此，我还是想出了几个可能的解决方案：
单独跟踪 PriorityAgent 机器的心跳，并添加一个 mutator 或行为来将传出 PriorityAgent 消息的目的地更改为 Agent 端点，如果这些心跳停止.
给 PriorityAgent 消息一个短的过期时间，并以某种方式处理过期以将消息重定向到 Agent 端点。我不确定这是否真的可行。
这些解决方案之一是否在正确的轨道上，还是我完全偏离了基地？
我是 Dennis van der Stelt，在 NServiceBus 的制造商 Particular Software 工作。
据我了解，PriorityAgent 和 Agent 都已经扩展到多台机器上了吗？然后他们都根据竞争消费者模式工作。换句话说，两台机器都尝试从同一个队列中获取消息，只有一台机器会获胜并开始处理消息。
您还谈到了高可用性。所以当 PriorityAgent 宕机时，另一台机器会把它捡起来。这就是我不明白的。为什么故障转移到 Agent，在我看来这是一个逻辑上不同的端点？如果逻辑上不同，它如何处理 PriorityAgent 消息？如果它可以处理相同的消息，那么它在逻辑上似乎是相同的端点。那为什么要区分PriorityAgent和Agent呢？
除此之外，SQL 服务器具有各种功能（如 Always-On）以确保它不会（完全）宕机。当 SQL 服务器已经可以为您解决这个问题时，为什么要尝试使用自定义构建解决方案来解决困难的场景？
另一种情况可能是 PriorityAgent 应该处理优先案件。诸如首选客户或 high-value 客户之类的东西。这有时会在（例如）大量订单（读作：消息）进来时使用，但我们希望比普通客户更快地与 high-value 客户打交道。但由于收到的消息数量众多，high-value 客户最终也会和常客一起排在队列的后面。一种解决方案可能是发布这些消息，并让两个不同的端点（具有不同的队列）同时订阅此消息。两者都收到每条唯一的消息，但检查它是否是他们应该处理的消息。 Agent 将忽略 high-value 客户，PriorityAgent 将忽略普通客户。
这些是一些可用作标准消息传递模式的解决方案，或用于解决您的问题的基础设施解决方案。同样，我并不完全清楚你在找什么。如果您想继续讨论；也许您想发送电子邮件至 support@particular.net，我们可以在那里继续讨论。
你没有看到很多人这样做，因为它被认为是一种反模式。或者更确切地说，是两种反模式之一。
1) 您正在发送命令，在这种情况下，命令的接收者定义了合同。为什么要将 PriorityAgent 定义的命令发送到 Agent？那里不应该有耦合。一个命令属于一个逻辑 endpoint/queue.
2) 或者您正在发布由发布者定义的事件，PriorityAgent 和 Agent 都是订阅者。这两个订阅者应该是 100% 自治的并且不共享任何东西。检查这两个逻辑独立实体之间的 heartbeats/sharing 信息是一件坏事。为什么一开始就把它们分开呢？如果他们彼此认识 "dirty secrets," 他们应该是同一个人。
如果您主要担心 PriorityAgent 消息在托管它的机器出现故障时将无法处理，并且想使用托管 Agent 的机器作为备份，只需部署 PriorityAgent 还有。一台机器可以 运行 多个端点就好了。
这样您就可以利用额外的机器，但不必将相同的命令发送到不同的逻辑端点或通过一些反向通道将两个不同的逻辑端点耦合在一起。
我是 NServiceBus 的新手，但目前使用它与 SQL 服务器传输在三台机器之间发送消息：一台属于名为 Server 的端点，两台属于名为 Server 的端点Agent。这按预期工作，发送到 Agent 端点的消息通过默认循环法分发到两台机器中的一台。
我现在想添加一个名为 PriorityAgent 的新端点，它具有不同的队列和另外两台机器。虽然所有端点都使用相同的消息类型，但我知道在发送每条消息之前应该在哪里处理它，所以通常我只需选择正确的目标端点，消息就会得到相应的处理。
但是，我需要在一个特殊情况下构建：如果 PriorityAgent 端点上的所有机器当前都已关闭，则通常应该发送到那里的消息应该发送到 Agent 端点，因此可以立即处理它们。另一方面，如果 Agent 端点上的所有机器当前都已关闭，则不应将任何 Agent 消息发送到 PriorityAgent，它们可以简单地等待 Agent 机器至 return.
我一直在研究实现这个的正确方法，但没有看到很多结果。我想这不是闻所未闻的情况，所以我的假设是我正在寻找错误的东西或以错误的方式思考这个问题。尽管如此，我还是想出了几个可能的解决方案：
单独跟踪
PriorityAgent机器的心跳，并添加一个 mutator 或行为来将传出PriorityAgent消息的目的地更改为Agent端点，如果这些心跳停止.给
PriorityAgent消息一个短的过期时间，并以某种方式处理过期以将消息重定向到Agent端点。我不确定这是否真的可行。
这些解决方案之一是否在正确的轨道上，还是我完全偏离了基地？
我是 Dennis van der Stelt，在 NServiceBus 的制造商 Particular Software 工作。
据我了解，PriorityAgent 和 Agent 都已经扩展到多台机器上了吗？然后他们都根据竞争消费者模式工作。换句话说，两台机器都尝试从同一个队列中获取消息，只有一台机器会获胜并开始处理消息。
您还谈到了高可用性。所以当 PriorityAgent 宕机时，另一台机器会把它捡起来。这就是我不明白的。为什么故障转移到 Agent，在我看来这是一个逻辑上不同的端点？如果逻辑上不同，它如何处理 PriorityAgent 消息？如果它可以处理相同的消息，那么它在逻辑上似乎是相同的端点。那为什么要区分PriorityAgent和Agent呢？
除此之外，SQL 服务器具有各种功能（如 Always-On）以确保它不会（完全）宕机。当 SQL 服务器已经可以为您解决这个问题时，为什么要尝试使用自定义构建解决方案来解决困难的场景？
另一种情况可能是 PriorityAgent 应该处理优先案件。诸如首选客户或 high-value 客户之类的东西。这有时会在（例如）大量订单（读作：消息）进来时使用，但我们希望比普通客户更快地与 high-value 客户打交道。但由于收到的消息数量众多，high-value 客户最终也会和常客一起排在队列的后面。一种解决方案可能是发布这些消息，并让两个不同的端点（具有不同的队列）同时订阅此消息。两者都收到每条唯一的消息，但检查它是否是他们应该处理的消息。 Agent 将忽略 high-value 客户，PriorityAgent 将忽略普通客户。
这些是一些可用作标准消息传递模式的解决方案，或用于解决您的问题的基础设施解决方案。同样，我并不完全清楚你在找什么。如果您想继续讨论；也许您想发送电子邮件至 support@particular.net，我们可以在那里继续讨论。
你没有看到很多人这样做，因为它被认为是一种反模式。或者更确切地说，是两种反模式之一。
1) 您正在发送命令，在这种情况下，命令的接收者定义了合同。为什么要将 PriorityAgent 定义的命令发送到 Agent？那里不应该有耦合。一个命令属于一个逻辑 endpoint/queue.
2) 或者您正在发布由发布者定义的事件，PriorityAgent 和 Agent 都是订阅者。这两个订阅者应该是 100% 自治的并且不共享任何东西。检查这两个逻辑独立实体之间的 heartbeats/sharing 信息是一件坏事。为什么一开始就把它们分开呢？如果他们彼此认识 "dirty secrets," 他们应该是同一个人。
如果您主要担心 PriorityAgent 消息在托管它的机器出现故障时将无法处理，并且想使用托管 Agent 的机器作为备份，只需部署 PriorityAgent 还有。一台机器可以 运行 多个端点就好了。
这样您就可以利用额外的机器，但不必将相同的命令发送到不同的逻辑端点或通过一些反向通道将两个不同的逻辑端点耦合在一起。