【发布时间】：2014-09-04 15:07:59
【问题描述】：
假设我们有
- 具有 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 网关的克隆。疯狂:)
所有的事情都是客户端不可靠，所以我想在服务器端拥有关于客户端的所有信息并在那里登录。
UPDATE3
另一种解决方案可能是创建单独的服务，但该服务将成为 HTTP 网关的一部分（例如 OutboundAlertService）。然后将实现三个目标：
- 共享发送循环代码
- 无需额外的服务器基础架构
- 对 OutboundService 没有负面影响（向其中添加进程内队列没有复杂性）
它不会接受来自 OutboundService 的异常，而是会定期检查 MSMQ。
然而，其他替代解决方案将简单地使用 MSMQ 队列以外的其他队列作为 NLog 目标，但这是丑陋的矫枉过正。
【问题讨论】：
标签： rebus