Реализация WebHooks с помощью ServiceStack

В настоящее время я работаю над сервисом REST, позволяющим контролировать и контролировать некоторые физические устройства.

Соответствующий REST API в значительной степени основан на принципах и идеях, которые вы можете найти в следующей статье: "Управление и мониторинг устройств с помощью REST".

Отслеживаемые и контролируемые устройства могут генерировать некоторые события, на которые клиенты должны иметь возможность подписаться. Моя идея состояла в том, чтобы реализовать эту часть с помощью RESTful WebHooks.

Поэтому всякий раз, когда возникает событие, мой сервис выполняет обратный вызов REST API для каждого подписчика, чтобы уведомить его.

Мой вопрос, теперь:

Как правильно реализовать этот сценарий с помощью ServiceStack (версия 3.9.71)?

Моя служба должна иметь возможность ставить подписки в очередь и отправлять события подписчикам. Он также должен иметь дело с ситуациями, когда клиенты не работают или недоступны, и потенциально повторять отправку уведомлений.

Должен ли я реализовывать все с нуля (используя, например, ServiceStack, размещенный RedisMqServer) или уже есть что-то, что идет дальше в моем направлении? Я гуглил без особого успеха.


rest webhooks redismqserver
person David Brabant    schedule 23.08.2013    source источник

Ответы (2)


arrow_upward
5
arrow_downward

Я считаю, что вы подходите к решению не с того конца. Вы определенно можете использовать ServiceStack для выполнения вызовов Web Hook — предпочтительно в JSON.

Что вам действительно следует изучить, так это очереди сообщений, поскольку они демонстрируют все характеристики, которые вам потребуются для реализации вызовов веб-перехватчиков (долговечность, политики очистки сообщений, фильтрация сообщений, политики доставки, политики маршрутизации, критерии постановки в очередь).

Подробнее о свойствах очередей сообщений в Википедии

Рабочий процесс, после которого событие будет выполняться до момента вызова веб-хука:

  1. В системе происходит событие; чтобы обеспечить вызов веб-перехватчика, вы должны поставить событие в очередь для обработки (через служебную шину, такую ​​как RabbitMq, MassTransit, NServiceBus и т. д.). Назовем целевую очередь EventsQueue.
  2. The application would then connect to the EventsQueue and process the messages by:
    1. Finding out who has subscribed to this particular event
    2. Для каждого подписчика поставьте в очередь новое сообщение, содержащее копию данных о событии и сведения о подписчике (например, URL-адрес обратного вызова), в WebHookQueue с начальным временем жизни (как долго сообщение действительно для)
  3. Затем приложение подключалось к WebHookQueue и обрабатывало сообщения, выполняя обратные вызовы.

Итак, теперь у вас есть базовая система уведомлений, которая должна гарантировать, что сообщение будет доставлено хотя бы один раз.

Вот отличная статья, в которой подробно рассказывается, как использовать TTL (время жизни) для повторной отправки сообщений через определенные промежутки времени

Я бы выбрал несколько иной подход:

  • Создайте разные очереди повторных попыток (например, WebHookRetryQueue = WebHookQueue очередь недоставленных сообщений, WebHookRetryLvl1Queue = TTL 5 минут, WebHookRetryLvl2Queue< /em> = TTL 15 минут). Хитрость заключается в том, чтобы установить для очереди недоставленных сообщений этих очередей уровня повтора значение WebHookQueue и оставить сообщения в очереди на истечение срока действия (это означает, что после истечения срока действия сообщения в очереди уровня повтора, он ставится в очередь обратно в WebHookQueue).
  • Затем вам нужно будет отслеживать текущий уровень повторной попытки для сообщений в WebHookRetryQueue, а затем поставить сообщение в очередь соответствующего уровня повторной попытки — после истечения срока жизни TTL получает вставлен обратно в WebHookQueue.

Пример рабочего процесса: WebHookQueue с максимальным числом повторных попыток: 2, срок жизни: 1 день

Пример сообщения: {'event_type': 'Email_Reply', 'callback_url': '...', 'reply_level': 0, 'queued_at': '2013-09-25T22:00:00Z' , данные: 'закодировано json'}

Сообщение -> WebHookQueue (сбой) -> WebHookQueue (сбой) -> WebHookRetryQueue (вкл. response_level = 1 + enqueue) -> WebHookRetryLvl1Queue (срок действия 5 минут) -> WebHookQueue (сбой) -> WebHookQueue (сбой) -> WebHookRetryQueue ( incr.reply_level=2 + enqueue) -> WebHookRetryLvl2Queue (срок действия 15 минут) -> WebHookQueue (сбой) -> WebHookQueue (сбой) -> WebHookRetryQueue (удалить сообщение)

Изменить

Нажмите здесь, чтобы просмотреть простой пример использования WebHookQueue и WebHookRetryQueue с использованием сообщения TTL уровня RabbitMQ. Из-за TTL уровня сообщения; нет необходимости создавать разные очереди повторных попыток, что может быть необходимо для менее популярных очередей сообщений.

Если бы вам пришлось реализовать такую ​​очередь с возможностью истечения срока действия отдельных сообщений (не с помощью политик очистки) или заранее запланировать сообщения с возможностью перепланирования/истечения срока действия, вам, скорее всего, пришлось бы выбрать очередь на основе базы данных.

Вот отличная статья на CodeProject о создании таких высокопроизводительная очередь для MSSQL Server (с усилием переносимая на другие базы данных, такие как MySql/Postgresql/Mongodb/Couchbase и т. д.)

Надеюсь, вы нашли эту информацию полезной.

person Shelakel    schedule 25.09.2013

arrow_upward
2
arrow_downward

ServiceStack.Webhooks — это новая платформа для простого добавления веб-перехватчиков в ваши службы независимо от архитектурного шаблона. вы хотите использовать. Вы можете просто создать свой собственный плагин.

person Jezz Santos    schedule 11.03.2017