卤面HTTP网关和MSMQ健康状况

Question

比方说，我们有一个HTTP网关站服务

与HTTP网关入站服务服务器节点

我认为情况

• 客户端节点，在MSMQ本身停止从客户端节点上的某种原因。在目前的实现中，Rebus HTTP网关将捕获异常。

  你觉得这个想法不仅仅是捕获，MessageQueueException异常也可以发送到服务器节点并放在错误队列中？ （错误队列的名称可以从头文件中获取）

  因此，如果没有额外的基础架构服务器就会知道客户端有问题，所以有人可能会作出反应。

  UPDATE：

  我猜的答案描述的问题将得到提升。我应该更深入地解释我的情况:)对不起。这里是：

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

  事实上，服务器本身对客户端的健康没有兴趣，但我虽然不是在客户端创建单独的警报服务，而是使用 HTTP网关 HTTP网关代码，但它可以完成这项工作， HTTP网关的双方运行。

  如果客户端根本无法访问服务器，该怎么办？

  由于MSMQ会死我想过使用过程中的独立的持久性队列对象一样，http://ayende.com/blog/4540/building-a-managed-persistent-transactional-queue （只是一个示例实现，我不知道它有什么样的许可证） 对总的例外客户端直到服务器可达。

  客户端多久会通知发生了错误的服务器？

  我不知道那一部分 - 我想一次每5分钟，但万一是什么样子就没有安排的时间，就像在当前的实现（虽然它可能与消息同步的预定时间（真）循环）？也许它可能只是由配置设置？

  我想了解关于错误处理一致的策略，通常包括普通的旧NLOG登录

  由于客户端节点将在NAT标准的监测技术背后的互联网将无法正常工作。我想过使用队列作为NLog传输，但是由于MSMQ会死机，所以无法工作。

  我也想过使用HTTP作为NLog传输，但在服务器端它需要队列（不是真的，但我想将它存储在队列中），所以我们回到了sbus和HTTP网关......那种的NLog传输实际上是HTTP网关的克隆。

  UPDATE2： HTTP作为NLOG运输（由运输我的意思是目标），还需要客户端队列就像我在描述“如果客户无法到达服务器呢？”部分。这将是嵌入到NLog中的HTTP网关的克隆。疯狂:)

  所有的事情是，客户端是不可靠的，所以我想拥有服务器端的客户端的所有信息，并在那里登录。

  UPDATE3

  替代解决方案可以创建单独的服务，然而这将是HTTP网关（例如OutboundAlertService）的一部分。然后三个目标将会实现：

  • 共享发送循环代码
  • 无需额外的服务器基础设施
  • 上OutboundService没有负面影响
  （无添加过程中的队列它的复杂性）

  它不需要OutboundService的异常，而是它会自己检查MSMQ。

  
  另一种替代解决方案是简单地使用非MSMQ队列作为NLog目标，但这是丑陋的矫枉过正。

Answer 1

关于你的情况，我最初的想法是，它不应该是服务器的问题，客户端有问题，所以我可能不会在客户端发生故障时向服务器发送消息。

正如我所看到的那样，这种方法会带来多种问题/障碍/挑战，例如，如果客户端根本无法访问服务器怎么办？客户多久会通知发生错误的服务器？

当然，我不知道你的设置的细节，所以很难给出具体的建议，但总的来说，我喜欢有一个一致的策略来处理错误，通常涉及旧的NLog日志记录和配置WARN和ERROR级别去Windows事件日志。

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

我希望我说的东西，你可以用:)

UPDATE

想着它多一些之后，我想我开始明白你的问题，我认为我如果客户端让另一端的HTTP侦听程序知道它有问题，那么另一端的HTTP侦听程序可能会（可能？）将该日志记录为错误。

另一种选择是另一端的HTTP侦听器可能有一个事件，ReceivedClientError或其他东西，可以附加到，然后在给定的情况下做任何正确的事情。

就你而言，你可能会在错误队列中放置一条消息。我只是避免把任何东西放在错误队列中作为一个通用的解决方案，因为我认为它混淆了错误队列的目的 - 错误队列中的“东西”不是一个消息，因此它不会是可重试的等等。