假设我们有
我考虑了MSMQ本身因某种原因在客户端节点上停止的情况。在当前的实现中，Rebus HTTP网关将捕获异常。
您如何看待这个问题，而不仅仅是捕获，MessageQueueException异常也可以发送到服务器节点并放入错误队列？ （可以从标题中收集错误队列的名称）
因此，如果没有额外的基础架构服务器，就会知道客户端存在问题，因此有人可以做出反应。
更新
我猜测答案中描述的问题会被提出来。我应该更深入地解释我的情景:)抱歉。这是：
我将以InboundService能够同时执行的方式修改HTTP网关 - 发送和接收消息。因此，OutboundService将是唯一一个发起连接的人（定期例如每5分钟一次），以便从服务器获取新消息并将其消息发送到服务器。这是因为客户端节点不被视为服务器，而是作为NAT后面的许多客户端之一。
事实上，服务器本身对客户端健康不感兴趣，但我认为不是在客户端创建单独的警报服务，而是使用 HTTP网关 HTTP网关代码，HTTP网关可以自己做到这一点在HTTP网关的业务中，双方都在运行。
如果客户端根本无法访问服务器怎么办？
由于MSMQ已经死了，我想过使用像http://ayende.com/blog/4540/building-a-managed-persistent-transactional-queue那样的进程内独立持久队列对象 （只是一个示例实现，我不确定它有什么样的许可证） 在客户端汇总异常，直到服务器可达。
客户端多久会通知服务器发生错误？
我不确定那部分 - 我认为它可能与消息同步的预定时间有关，例如每5分钟一次，但是如果没有预定时间就像当前实现一样（while（true）循环） ）？也许它可能只是由config设置？
我喜欢有一个关于处理错误的一致策略，这通常涉及普通的旧NLog日志记录
由于客户端节点将在Internet后面，NAT标准监控技术将无法正常工作。我想过使用队列作为NLog传输，但由于MSMQ已经死了，所以不行。
我还考虑过使用HTTP作为NLog传输，但是在服务器端它需要队列（不是真的，但我想将它存储在队列中）所以我们回到sbus和HTTP网关...那种NLog传输将是HTTP网关的事实上的克隆。
UPDATE2： HTTP作为NLog传输（通过传输我的意思是目标）也需要客户端队列，就像我在“如果客户端根本无法访问服务器怎么办？”中所描述的那样。部分。它将是嵌入NLog的HTTP网关的克隆。疯狂：）
所有的事情都是客户端不可靠所以我想在服务器端获取有关客户端的所有信息并将其记录在那里。
UPDATE3
替代解决方案可能是创建单独的服务，但是它将是HTTP网关的一部分（例如OutboundAlertService）。然后将实现三个目标：
它不会从OutboundService中获取异常，而是会自行检查MSMQ。
然而，其他替代解决方案只是使用除MSMQ队列之外的其他解决方案作为NLog目标，但那是丑陋的过度杀伤。
答案 0 :(得分：2)
关于您的场景，我最初的想法是客户端出现问题永远不应该是服务器的问题，因此当客户端发生故障时，我可能不会向服务器发送消息。
在我看来，这种方法会有多个问题/障碍/挑战，例如，如果客户端根本无法访问服务器怎么办？客户端多久会通知服务器发生错误？
当然我不知道你的设置的细节，所以很难给出具体的建议，但总的来说我喜欢有一个关于处理错误的一致策略，这通常涉及普通的旧NLog日志记录和配置WARN和ERROR级别去Windows事件日志。
这允许设置各种工具（例如Service Center Operations Manager或类似工具）来监视所有计算机的事件日志，以便在出现问题时引发错误标记。
我希望我说过你可以使用的东西：）
<强>更新
在考虑了一些之后，我想我已经开始理解你的问题了，我认为我更喜欢一个解决方案，其中客户端让另一端的HTTP监听器知道它有问题，然后另一端的HTTP侦听器可能（可能？）将其记录为错误。
另一种选择是，另一端的HTTP侦听器可以有一个事件，ReceivedClientError或其他东西，一个人可以附加，然后在给定的情况下做任何正确的事情。
在您的情况下，您可能会在错误队列中放入一条消息。我只是避免把任何东西放在错误队列中作为一般解决方案，因为我认为它混淆了错误队列的目的 - 错误队列中的“东西”不会是一条消息，因此它不会被重试等等