Rest 用ServiceStack实现Webhook

我目前正在开发一个REST服务，它允许控制和监视一些物理设备

相应的RESTAPI很大程度上基于您可以在以下文章中找到的原则和思想：“”

受监视和控制的设备可以生成客户端必须能够订阅的一些事件。我的想法是使用

因此，每当发生事件时，我的服务都会对每个订阅者进行RESTAPI回调，以便通知它

我现在的问题是：

使用ServiceStack（版本3.9.71）实现此场景的正确方法是什么

“我的服务”必须能够对订阅进行排队，并将事件分派给订阅服务器。它还必须处理客户端关闭或无法访问的情况，并可能重试发送通知

---

我是否必须从头开始实现所有功能（例如，使用ServiceStack托管），或者是否已经有了更进一步的功能？我在谷歌上到处搜索，但没有取得多大成功。

我相信你是从错误的方向找到了解决方案。您完全可以使用ServiceStack进行Web钩子调用——最好使用JSON

您真正应该研究的是消息队列，因为它们展示了实现Web钩子调用所需的所有特性（持久性、消息清除策略、消息过滤、传递策略、路由策略、队列标准）

事件的工作流将跟进到调用Web钩子的点：

系统中发生事件；为了确保调用Web钩子，您必须持久地将事件排队以进行处理（通过服务总线，如RabbitMq、MassTransit、NServiceBus等）。让我们调用目标队列eventsque

然后，应用程序将连接到EventsQueue并通过以下方式处理消息：

找出谁订阅了这个特别的活动

对于每个订阅者，将包含事件数据和订阅者详细信息（例如回调URL）副本的新消息排入WebHookQueue，并具有初始生存时间（消息有效期为多长）

然后，应用程序将连接到WebHookQueue，并通过回调来处理消息

因此，现在您有了一个基本的通知系统，它应该确保消息至少传递一次

我会采取一些不同的方法：

• 创建不同的重试级别队列（例如WebHookRetryQueue=WebHookQueue的死信队列，WebHookRetryL1Queue=TTL 5分钟，WebHookRetryL2Queue=TTL 15分钟）。诀窍是将这些重试级别队列的死信队列设置为WebHookQueue，并让消息排队等待到期（这意味着一旦消息在重试级别队列中过期，它将重新排队进入WebHookQueue）
• 然后，您需要跟踪WebHookRetryQueue中消息的当前重试级别，然后将消息排队到相应的重试级别队列中-在TTL过期后，将消息插回WebHookQueue中

工作流示例：最大重试次数为2次的WebHookQueue，TTL:1天

示例消息：{'event_type'：'Email_Reply'，'callback_url'：'…'，'Reply_level'：0，'queued_at'：'2013-09-25T22:00:00Z'，数据：'json encoded'}

消息->WebHookQueue（失败）->WebHookRetryQueue（失败）->WebHookRetryQueue（增加回复级别=1+排队）->WebHookRetryVL1Queue（5分钟到期）->WebHookQueue（失败）->WebHookRetryQueue（失败）->WebHookRetryQueue（增加回复级别=2+排队）->WebHookRetryVL2Queue（15分钟到期）->WebHookQueue（失败）->WebHookQueue（失败）->WebHookRetryQueue（丢弃消息）

---

编辑

由于消息级别TTL；没有必要创建不同的重试级别队列，这对于功能较差的消息队列可能是必需的

---

如果您必须实现这样一个队列，使其能够使单个消息过期（而不是通过清除策略），或者提前安排消息，并选择重新调度/过期，那么您很可能必须选择基于数据库的队列

（可以轻松移植到其他数据库，如MySql/Postgresql/Mongodb/Couchbase等）

希望您发现这些信息很有用。

是一个新的框架，可以轻松地将Webhook添加到您的服务中，无论您想使用什么体系结构模式。 您只需构建自己的插件