假设我们有
- 具有 HTTP 网关出站服务的客户端节点
- 具有 HTTP 网关入站服务的服务器节点
我考虑了 MSMQ 本身由于某种原因在客户端节点上停止的情况。在当前实现中，Rebus HTTP 网关将捕获异常。
您如何看待 MessageQueueException 异常不仅可以捕获，还可以发送到服务器节点并放入错误队列的想法？（错误队列的名称可以从标题中收集）
因此，如果没有额外的基础设施，服务器就会知道客户端有问题，因此有人可以做出反应。
更新：
我猜答案中描述的问题会被提出。我应该更深入地解释我的情况:) 抱歉。这里是：
我将以 InboundService 能够同时执行的方式修改 HTTP 网关 - 发送和接收消息。因此，OutboundService 将是唯一一个发起连接（定期，例如每 5 分钟一次）以便从服务器获取新消息并将其消息发送到服务器的人。这是因为客户端节点不被视为服务器，而是被视为位于 NAT 后面的众多客户端之一。
实际上，服务器本身对客户端健康不感兴趣，但我虽然不是在客户端创建单独的警报服务来使用HTTP 网关HTTP 网关代码，而是 HTTP 网关 itelf 可以做到这一点，因为它完全符合 HTTP 网关的业务边跑。
如果客户端根本无法访问服务器怎么办？
由于 MSMQ 会死，我考虑过使用像http://ayende.com/blog/4540/building-a-managed-persistent-transactional-queue这样的进程内独立持久队列对象 （只是一个示例实现，我不确定它有什么样的许可证）在客户端聚合异常，直到服务器可以访问。
客户端多久通知一次发生错误的服务器？
我不确定那部分 - 我认为它可能与消息同步的预定时间有关，例如每 5 分钟一次，但是如果没有像当前实现中的预定时间（while(true) 循环）怎么办？也许它可以由配置设置？
我喜欢有一个关于处理错误的一致策略，这通常涉及普通的旧 NLog 日志记录
由于客户端节点将位于 Internet 后面，因此 NAT 标准监控技术将不起作用。我考虑过使用队列作为 NLog 传输，但由于 MSMQ 将死，它不会工作。
我还考虑过使用 HTTP 作为 NLog 传输，但在服务器端它需要队列（不是真的，但我想将它存储在队列中）所以我们回到 sbus 和 HTTP 网关......那种 NLog 传输将是 HTTP 网关的事实上的克隆。
UPDATE2： HTTP 作为 NLog 传输（我的意思是目标传输）也需要客户端队列，就像我在“如果客户端根本无法到达服务器怎么办？”中描述的那样。部分。它将是嵌入到 NLog 中的 HTTP 网关的克隆。疯狂:)
所有的事情是客户端是不可靠的，所以我想在服务器端拥有关于客户端的所有信息并在那里登录。
更新3
替代解决方案可能是创建单独的服务，但它是 HTTP 网关的一部分（例如 OutboundAlertService）。然后将实现三个目标：
- 共享发送循环代码
- 无需额外的服务器基础架构
- 对 OutboundService 没有负面影响（没有向其中添加进程内队列的复杂性）
它不会从 OutboundService 中获取异常，而是会定期检查 MSMQ 本身。
然而，其他替代解决方案将简单地使用 MSMQ 队列以外的其他队列作为 NLog 目标，但这是丑陋的矫枉过正。