NServiceBus网关http://docs.particular.net/nservicebus/gateway/似乎是一种使用NServiceBus基础架构实现内部 webhook的方法。
我们需要进一步使用此概念向任何第三方订阅者开放少数事件，该订阅者可以在我们的系统中注册webhook网址。
我们计划创建两个初始窗口服务
1）WebHookBatchService，可以作为订阅者添加到感兴趣的特定消息中。
<UnicastBusConfig>
<MessageEndpointMappings>
.......
<add Messages="MyMessages.MyImportantMessage, MyMessages" Endpoint="WebHookBatchService.Queue"/>
.......
</MessageEndpointMappings>
</UnicastBusConfig>
2）WebHookProcessService - 实际处理WebHookBatchService发送的1条消息。
一旦在WebHookBatchService.Queue上收到消息，我们的WebHookBatchService将查找特定租户+消息类型的所有订阅者，并且foreach将单个消息发送到WebHookProcessService的WebHookProcessService.Queue（我们可以将nservicebus loadbalancer的实例设置为桥接批处理和实际处理器）可能使用http://restsharp.org/实际处理实际消息。
今天有没有现成的开源项目？
既然我们无法控制订阅者的持久性，我们应该如何管理错误？
http://wiki.shopify.com/WebHook
如果完全相同的webhook连续19次失败，则会删除webhook。
它没有提到webhook中的任何延迟..人们在重试逻辑中遇到标准延迟的经历了什么？
以下是其他一些想法：
提案0：MaxRetries =“1”。每晚清除WebHookProcessService.ErrorQueue。 （没有重试 - 如果第一次失败则保证消息丢失）
提案1： 异常捕获的MaxRetries =“1”发送包含将通过http传递的消息的xml版本的电子邮件 每晚清除WebHookProcessService.ErrorQueue。 - 我发现潜在的垃圾邮件问题。
提案2：nservicebus MaxRetries立即重试。所以我需要创建（1小时 - 24小时）桶队列并使用RetrySchedulerService，尽管当服务端点开始工作时，当他们以非DateCreated有序方式同时获取25条消息时，我认为这很难维护和混淆订阅者
挖掘创意......
答案 0 :(得分：1)
网关通常用于通过HTTP进行物理站点之间的通信。由于您正在向世界公开端点以接受回调，因此我认为您可以使用内置的WCF托管并通过防火墙将您的端点暴露给第三方。你的其他设置听起来很合适。
至于错误，你是正确的，NSB会立即重试，但是如果你使用网络回叫，这可能会让你遇到小的打嗝。您需要确定如何处理错误队列，我们只需构建一个新的端点来处理错误队列，并使用逻辑来确定重试，延迟等。实现此目的的一个好方法是使用Saga，其中包括超时经理这使您可以在工作流程中重试指定的次数，尝试其他通信，记录所有内容，并最终通知可以联系第三方的人，让他们知道有什么东西被破坏。