0

我是 NServiceBus 的新手，但目前使用它与 SQL Server Transport 在三台机器之间发送消息：一台属于名为 的端点Server，两台属于名为 的端点Agent。这按预期工作，发送到Agent端点的消息通过默认循环分发到两台机器之一。

我现在想添加一个新的端点PriorityAgent，用一个不同的队列和两台额外的机器调用。虽然所有端点都使用相同的消息类型，但我知道每条消息在发送之前应该在哪里处理，所以通常我可以选择正确的目标端点，然后相应地处理消息。

但是，我需要构建一个特殊情况：如果PriorityAgent端点上的所有机器当前都关闭了，那么通常应该发送到那里的消息应该被发送到Agent端点，以便可以毫不拖延地处理它们。另一方面，如果Agent端点上的所有机器当前都已关闭，Agent则不应向 发送任何消息PriorityAgent，它们可以简单地等待Agent机器返回。

我一直在研究实现这一点的正确方法，但没有看到很多结果。我想这不是一个闻所未闻的场景，所以我的假设是我正在寻找错误的东西或以错误的方式思考这个问题。尽管如此，我还是想出了几个潜在的解决方案：

  1. 单独跟踪PriorityAgent机器的心跳，如果这些心跳停止，则添加一个修改器或行为以将传出PriorityAgent消息的目的地更改到Agent端点。

  2. 给PriorityAgent消息一个短暂的过期时间，并以某种方式处理过期时间以将消息重定向到Agent端点。我不确定这是否真的可行。

这些解决方案之一是在正确的轨道上，还是我完全不在基地？

4

2 回答 2

1

我是 Dennis van der Stelt，为 NServiceBus 的制造商 Particular Software 工作。

据我了解，两者PriorityAgent都Agent已经在多台机器上进行了扩展？然后他们都根据竞争消费者模式工作。换句话说，两台机器都试图从同一个队列中提取消息，其中只有一个会获胜并开始处理消息。

您还在谈论高可用性。因此，当PriorityAgent出现故障时，另一台机器会接起它。这就是我不明白的。为什么故障转移到Agent，在我看来，这似乎是一个逻辑上不同的端点？如果它在逻辑上不同，它如何处理PriorityAgent消息？如果它可以处理相同的消息，那么它在逻辑上似乎是相同的端点。那为什么要区分PriorityAgentandAgent呢？

除此之外，SQL Server 还具有各种功能（例如 Always-On），以确保它不会（完全）宕机。当 SQL Server 已经可以为您解决这个问题时，为什么还要尝试使用自定义构建解决方案来解决这个难题？

另一种情况可能是PriorityAgent应该处理优先案件。诸如首选客户或高价值客户之类的东西。这有时会在（例如）大量订单（阅读：消息）进来时使用，但我们希望比普通客户更快地与高价值客户打交道。但由于收到的消息量很大，高价值客户也将与普通客户一起排在队列的后面。一种解决方案可能是发布这些消息并让两个不同的端点（具有不同的队列）都订阅此消息。两者都接收每条唯一消息，但检查它是否是他们应该处理的消息。会Agent忽略高价值客户，PriorityAgent会忽略普通客户。

这些是一些可用作标准消息传递模式的解决方案，或用于解决您的问题的基础设施解决方案。同样，我并不完全清楚你在寻找什么。如果您想继续讨论；也许您想发送电子邮件至 support@particular.net，我们可以在那里继续讨论。

于 2017-01-20T07:43:34.237 回答
1

您没有看到很多人这样做，因为它被认为是一种反模式。或者更确切地说是两种反模式之一。

1）您正在发送命令，在这种情况下，命令的接收者定义合同。为什么要发送 to 定义的PriorityAgent命令Agent？那里不应该有耦合。命令属于一个逻辑端点/队列。

2) 或者您正在发布一个由发布者定义的事件，包括订阅者PriorityAgent和Agent订阅者。两个订阅者应该是 100% 自主的并且不共享任何内容。检查这两个逻辑独立实体之间的心跳/共享信息是一件坏事。那么为什么首先将它们分开呢？如果他们知道彼此的“肮脏秘密”，他们应该是同一件事。

如果您主要担心的是，PriorityAgent如果托管它的机器出现故障，消息将不会被处理，并且希望将托管的机器Agent用作备份，PriorityAgent那么也只需在那里部署即可。一台机器可以运行多个端点就好了。

这样您就可以利用额外的机器，但不必将相同的命令发送到不同的逻辑端点或通过某个反向通道将两个不同的逻辑端点耦合在一起。

于 2017-01-20T20:07:40.430 回答