使用 ServiceStack 实现 WebHook [英] Implementing WebHooks with ServiceStack

问题描述

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

I'm currently working on a REST service allowing to control and monitor some physical devices.

相应的 REST API 主要基于您可以在以下文章中找到的原理和想法:使用 REST 控制和监控设备".

The corresponding REST API is largely based on principles and ideas you can find in the following article: "Controlling and Monitoring Devices with REST".

被监控和控制的设备可以生成一些客户端必须能够订阅的事件.我的想法是使用 RESTful WebHooks 实现该部分.

The monitored and controlled devices can generate some events to which clients must be able to subscribe. My idea was to implement that part using RESTful WebHooks.

因此，每当发生事件时，我的服务都会向每个订阅者发出 REST API 回调以通知它.

So whenever an event arises, my service makes a REST API callback to each subscriber in order to notify it.

我的问题，现在:

使用 ServiceStack(版本 3.9.71)实现此场景的正确方法是什么?

What would be a proper way to implement this scenario using ServiceStack (version 3.9.71)?

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

My service must be able to queue subscriptions and dispatch events to subscribers. It must also deal with situations where clients are down or unreachable, and potentially retry sending notifications.

我是否必须从头开始实现所有内容(例如，使用托管的 ServiceStack RedisMqServer) 还是已经有一些东西朝着我的方向走得更远?我已经用谷歌搜索了，但没有取得多大成功.

Do I have to implement everything from scratch (using, for example, a ServiceStack hosted RedisMqServer) or is there already something that goes further in my direction? I've googled around without much success.

推荐答案

我相信您是从错误的一端接近解决方案的.您绝对可以使用 ServiceStack 进行 Web Hook 调用 - 最好使用 JSON.

I believe you are approaching the solution from the wrong end. You could definitely use ServiceStack to make the Web Hook calls - preferably in JSON.

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

What you really should be looking into is Message Queues, as they exhibit all the characteristics you would require to implement Web Hook calls (durability, message purging policies, message filtering, delivering policies, routing policies, queuing criteria)

在维基百科上阅读有关消息队列属性的更多信息

事件在调用 Web Hook 之前的工作流程:

The workflow an event would follow up to the point where a Web Hook is called:

1. 系统中发生了一个事件；为确保调用 Web Hook，您必须持久地将事件排入队列以进行处理(通过 RabbitMq、MassTransit、NServiceBus 等服务总线).让我们调用目标队列 EventsQueue
2. 然后应用程序将连接到 EventsQueue 并通过以下方式处理消息:

1. An event occurs in the system; to ensure a Web Hook will be called, you have to durably enqueue the event for processing (via a Service Bus such as RabbitMq, MassTransit, NServiceBus etc.). Let's call the target queue EventsQueue
2. The application would then connect to the EventsQueue and process the messages by:

1. 找出谁订阅了此特定事件
2. 对于每个订阅者，将包含事件数据副本和订阅者详细信息(例如回调 URL)的新消息加入到具有初始生存时间 (消息的有效期有多长)

1. Finding out who has subscribed to this particular event
2. For every subscriber enqueue a new message containing a copy of the event data and subscriber details (ex. callback URL) to a WebHookQueue with an initial Time To Live (how long the message is valid for)

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

The application would then connect to the WebHookQueue and process the messages by making callbacks.

所以现在你有一个基本的通知系统，它应该确保消息至少被传递一次.

So now you have a basic notification system that should ensure a message gets delivered at least once.

这是一篇很棒的文章，详细介绍了如何使用 TTL(生存时间)每隔一段时间重试消息

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

I would take a somewhat different approach:

• 创建不同的重试级别队列(例如 WebHookRetryQueue = WebHookQueue 的死信队列，WebHookRetryLvl1Queue = TTL 5 分钟，WebHookRetryLvl2Queue = TTL 15 分钟).诀窍是将这些重试级别队列的死信队列设置为 WebHookQueue 并让消息排队过期(意味着一旦消息在重试级别队列中过期，它重新排入WebHookQueue).
• 然后，您需要跟踪 WebHookRetryQueue 中消息的当前重试级别，然后将消息排入适当的重试级别队列 - 之后是 TTL过期，被插入回 WebHookQueue.

• Create different retry level queues (ex. WebHookRetryQueue = WebHookQueue's dead-letter queue, WebHookRetryLvl1Queue = TTL 5 minutes, WebHookRetryLvl2Queue = TTL 15 minutes). The trick is to set these retry level queues' dead-letter queue to the WebHookQueue and to leave messages enqueued to expire (meaning once a message expires in a retry level queue, it's enqueued back into the WebHookQueue).
• You would then need to keep track of the current retry level on the messages in the WebHookRetryQueue and then enqueue the message on the appropriate retry level queue - whereafter the TTL expires, gets inserted back into the WebHookQueue.

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

Example Workflow: WebHookQueue with Max Retries: 2, TTL: 1 day

示例消息:{'event_type':'Email_Reply'，'callback_url':'...'，'reply_level':0，'queued_at':'2013-09-25T22:00:00Z', 数据: 'json 编码'}

Example message: {'event_type': 'Email_Reply', 'callback_url': '...', 'reply_level': 0, 'queued_at': '2013-09-25T22:00:00Z', data: 'json encoded'}

Message -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (incr. reply_level=1 + enqueue) -> WebHookRetryLvl1Queue (5 mins-expire) -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (incr. reply_level=2 + enqueue) -> WebHookRetryLvl2Queue (15 mins-expire) -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (drop message)

Message -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (incr. reply_level=1 + enqueue) -> WebHookRetryLvl1Queue (5 mins-expire) -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (incr. reply_level=2 + enqueue) -> WebHookRetryLvl2Queue (15 mins-expire) -> WebHookQueue (fail) -> WebHookQueue (fail) -> WebHookRetryQueue (drop message)

编辑

单击此处查看使用 WebHookQueue 和 WebHookRetryQueue 使用 RabbitMQ 的消息级 TTL. 由于消息级 TTL；没有必要创建不同的重试级别队列 - 这对于功能较少的消息队列可能是必要的.

Click here to look at simple example using a WebHookQueue and a WebHookRetryQueue using message level TTL's of RabbitMQ. Due to the message level TTL's; it's not necessary to create different Retry Level queues - which might be necessary for less featured message queues.

如果您必须实现这样的队列，使其能够使单个消息过期(而不是通过清除策略)或提前安排消息并选择重新安排/过期 - 您很可能不得不选择基于数据库的排队.

If you had to implement such a queue with the ability to expire individual messages (not via purging policies) or schedule messages ahead of time with the option to reschedule/expire - you would most likely have had to opt for Database based queuing.

这是一篇关于 CodeProject 的精彩文章为MSSQL Server构建如此高性能的队列(可移植到MySql/Postgresql/Mongodb/Couchbase等其他数据库，努力)

Here's a great article on CodeProject on building such a high performance queue for MSSQL Server (portable to other databases such as MySql/Postgresql/Mongodb/Couchbase etc. with effort)

希望您发现此信息有用.

Hope you found this information useful.

这篇关于使用 ServiceStack 实现 WebHook的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！