nservicebus + webhooks +错误 +MaxRetries
功能描述
NServiceBus 网关，http://docs.pspecial.net/nservicebus/gateway/ ，似乎是使用 NServiceBus 基础设施实现内部 webhook 的一种方法。
我们需要进一步深化这个概念，向有权在我们的系统中注册 Webhook URL 的任何第三方订阅者开放少数事件。
回顾
我们计划创建两个初始窗口服务
1) WebHookBatchService，可以将其添加为感兴趣的特定消息的订阅者。
<UnicastBusConfig>
<MessageEndpointMappings>
.......
<add Messages="MyMessages.MyImportantMessage, MyMessages" Endpoint="WebHookBatchService.Queue"/>
.......
</MessageEndpointMappings>
</UnicastBusConfig>
2) WebHookProcessService - 实际上处理由 WebHookBatchService 发送的 1 条消息。
一旦在 WebHookBatchService.Queue 上收到消息，我们的 WebHookBatchService 将查找特定租户 + 消息类型的所有订阅者，并 foreach 将各个消息发送到 WebHookProcessService.Queue（我们可以创建 nservicebus 负载均衡器的实例来桥接批处理）和实际处理器）来实际处理真实消息，可能使用 http://restsharp.org/。
问题
目前是否有任何现有的开源项目可以做到这一点？
既然我们无法控制订阅者的持久性，我们应该如何管理错误？
http://wiki.shopify.com/WebHook
如果同一个 Webhook 连续 19 次失败，该 Webhook 将被删除。
它没有提到 webhook 中的任何延迟。人们在重试逻辑中的标准延迟方面经历了什么？
以下是一些其他想法：
提案 0：MaxRetries="1"。每晚清除 WebHookProcessService.ErrorQueue。 （不重试 - 如果第一次失败，保证消息丢失）
提案 1： MaxRetries="1" 捕获异常时发送包含 xml 版本消息的电子邮件，该消息将通过 http 传递。
每晚清除 WebHookProcessService.ErrorQueue。 -- 我发现潜在的垃圾邮件问题。
提案2：nservicebus MaxRetries立即重试，无延迟。因此，我需要创建（1小时 - 24小时）存储桶队列并使用 RetrySchedulerService，尽管我认为这很难维护，并且当订阅者在服务端点开始工作时以非 DateCreated 有序方式一次性收到 25 条消息时，他们会感到困惑。
挖掘想法...
Feature Description
The NServiceBus gateway, http://docs.particular.net/nservicebus/gateway/, seems to be a way to achieve an internal webhook using the NServiceBus infrastructure.
We need to go further with this concept to open up a few event to any 3rd party subscriber that has access to register a webhook url in our system.
Review
We plan to create two initial window services
1) WebHookBatchService, that can be added as a subscriber to specific messages of interest.
<UnicastBusConfig>
<MessageEndpointMappings>
.......
<add Messages="MyMessages.MyImportantMessage, MyMessages" Endpoint="WebHookBatchService.Queue"/>
.......
</MessageEndpointMappings>
</UnicastBusConfig>
2) WebHookProcessService - actually processes 1 message sent by the WebHookBatchService.
Once messages are received on the WebHookBatchService.Queue our WebHookBatchService will look up all the subscribers for the specific tenant + message type and foreach send individual messages to WebHookProcessService.Queue for the WebHookProcessService (which we can make an instance of nservicebus loadbalancer to bridge the batch and actual processor) to actually process the real messages probably using http://restsharp.org/.
Questions
Are there any existing open source projects that do this today?
Now since we have no control of the durability of the subscribers how should we manage errors?
http://wiki.shopify.com/WebHook
A webhook will be deleted if there are 19 consecutive failures for the exact same webhook.
It doesn't mention any delays in the webhook.. What have people experienced with standard delay in retry logic?
Here are some other thoughts:
proposal 0: MaxRetries="1". Purge WebHookProcessService.ErrorQueue nightly. (no retry - guaranteed message loss if it fails the first time)
proposal 1:
MaxRetries="1" on exception catch send email containing xml version of the message that would have been delivered over http.
Purge WebHookProcessService.ErrorQueue nightly.
-- I see potential a spam issues.
proposal 2: The nservicebus MaxRetries retries right away without delay. So i would need to create (1hr - 24hr) bucket queues and use a RetrySchedulerService although I see this as difficult to maintain and confusing for subscribers when they all at once get 25 messages in a non DateCreated ordered fashion when there service endpoint begins to work.
Digging for ideas...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
网关通常用于通过 HTTP 在物理站点之间进行通信。由于您向世界公开端点以接受回调，因此我认为您可以仅使用内置 WCF 托管并通过防火墙向第三方公开您的端点。你的其余设置听起来对我来说很合适。
至于错误，你是对的，NSB 会立即重试，但如果你使用网络回调，这可能会在出现小问题的情况下帮助你。您需要确定如何处理错误队列，我们只需构建一个新端点来处理错误队列，并使用逻辑来确定重试、延迟等。实现此目的的一个好方法是使用 Saga，其中包括超时管理器。这使得您可以重试指定次数、尝试另一次通信、记录所有内容，并最终通知可以联系第 3 方的人员，让他们知道东西已损坏。
The Gateway is typically used for communication between physical sites over HTTP. Since you are exposing an endpoint to the world to accept callbacks, I'm thinking you could just use the built-in WCF hosting and expose your endpoint through the firewall to 3rd parties. The rest of your setup sounds appropriate to me.
As for errors, you are correct, NSB retries immediately, but if you using web call backs this may get you by in the cases there are small hiccups. You will need to determine how you want to process the error queues, we just build in a new endpoint to process the error queues with logic to determine the retries, delay etc. A nice way to accomplish this is to use a Saga, which includes a Timeout manager. This enables a workflow where you can retry a specified number of times, try another communication, log everything, and ultimately notify someone who can contact the 3rd party to let them know there stuff is busted.