Rebus HTTP网关和MSMQ运行状况

Question

假设我们有

• 具有HTTP网关出站服务的客户端节点
• 具有HTTP网关入站服务的服务器节点

我考虑MSMQ本身在客户端节点上由于某种原因停止的情况。在当前实现中，Rebus HTTP网关将捕获异常。

您如何看待MessageQueueExcpse异常也可以发送到服务器节点并放在错误队列中，而不仅仅是捕获？（错误队列的名称可以从标题中收集）

因此，在没有额外基础设施的情况下，服务器会知道客户端有问题，以便有人能够做出反应。

更新：

我猜答案中描述的问题会被提出。我应该更深入地解释我的情况：）抱歉。这是：

我将以InboundService能够同时发送和接收消息的方式修改HTTP网关。因此，OutboundService将是唯一一个发起连接的人（定期，例如每5分钟一次），以便从服务器获取新消息并将其消息发送到服务器。这是因为客户机节点不被视为服务器，而是NAT后面的许多客户机之一。

事实上，服务器本身对客户端的健康状况不感兴趣，但我认为，与其在客户端创建单独的警报服务，而不是使用HTTP网关的HTTP网关代码，HTTP网关本身可以做到这一点，因为它相当于HTTP网关的业务让双方都跑。

如果客户机根本无法到达服务器怎么办？

因为MSMQ会死，所以我考虑使用像这样的进程内独立持久队列对象http://ayende.com/blog/4540/building-a-managed-persistent-transactional-queue（只是一个示例实现，我不确定它有什么样的许可证）来聚合客户端的异常，直到服务器可达。

客户端多长时间通知服务器一次发生错误？

我不确定这一部分——我认为这可能与消息同步的计划时间有关，比如每5分钟一次，但万一没有计划时间，就像在当前实现中一样（while（true）loop）？也许可以通过配置来设置？

我喜欢有一个关于处理错误的一致策略，通常涉及普通的旧NLog日志记录

由于客户端节点将位于互联网背后，NAT标准监控技术将无法工作。我曾想过使用队列作为NLog传输，但由于MSMQ将失效，因此无法工作。

我还考虑过使用HTTP作为NLog传输，但在服务器端它需要队列（不是真的，但我想把它存储在队列中），所以我们回到SBU和HTTP网关。。。这种NLog传输实际上是HTTP网关的克隆。

更新2:HTTP作为NLog传输（我指的是目标传输）也需要客户端队列，如我在“如果客户端根本无法到达服务器怎么办？”部分它将是嵌入NLog的HTTP网关的克隆。疯狂：）

所有的问题是，客户端是不可靠的，所以我想在服务器端有关于客户端的所有信息，并将其登录到那里。

最新消息

替代的解决方案可以是创建单独的服务，但是它将是HTTP网关的一部分（例如HTTP网关）。服务）。那么三个目标将得到实现：

• 共享发送循环代码
• 无需额外的服务器架构体系
• 没有负面的影响，并没有增加进程内队列的复杂性

它不会接受来自外部服务的例外，而是会对MSMQ进行perodically检查。

然而，另一种替代解决方案是简单地使用MSMQ队列以外的其他队列作为NLog目标，但这是一种可怕的过度杀伤力。

Answer 1

关于你的场景，我最初的想法是，客户端有问题不应该是服务器的问题，所以当客户端失败时，我可能不会向服务器发送消息。

在我看来，这种方法会有很多问题/障碍/挑战，因为，例如，如果客户端根本无法访问服务器怎么办？客户端多久通知服务器一次错误？

当然，我不知道你的设置的细节，所以很难给出具体的建议，但总的来说，我希望在处理错误方面有一个一致的策略，这通常涉及普通的旧NLog日志记录，并将警告和错误级别配置为进入Windows事件日志。

这允许设置各种工具（例如Service Center Operations Manager或类似工具）来监视所有机器的事件日志，以便在出现错误时发出错误标志。

我希望我已经说了一些你可以使用的东西：）

更新

仔细考虑之后，我想我开始理解你的问题了，我想我更喜欢这样一种解决方案：客户端让另一端的HTTP侦听器知道它有问题，然后另一端的HTTP侦听器可以（也许？）将其记录为错误。

另一个选项是，另一端的HTTP监听器可以有一个事件，ReceivedClientError或其他东西，人们可以附加到该事件上，然后在给定的情况下做任何正确的事情。

在您的情况下，您可以将消息放入错误队列。我只是避免把任何东西放在错误队列中作为通用解决方案，因为我认为它混淆了错误队列的目的——错误队列中的“东西”不是消息，因此它不是可重试的等。