Существует множество способов и технологических вариантов, которые следует учитывать при реализации API, управляемого событиями. Например, мы рассмотрели, как создавать API, управляемые событиями, используя эти 3 хорошо известных шаблона: CQRS, Шлюз API а также Бессерверный в предыдущем сообщении в блоге. В этом посте подробно рассказывается создание управляемых событиями API с использованием Webhook и API Gateway, мы понимаем роль каждого в этом решении. Во-первых, давайте обратим внимание на первоначальную постановку задачи без установленного веб-перехватчика.


Нужен вебхук

Приложения-потребители ожидают получать информацию о любом изменении состояния конкретной записи или записей.

Примеры:

  • Обновление или добавление клиентов в CRM-системе вызывает событие.
  • Курсы обмена валюты из приложения для обмена иностранной валюты информируют пользователей об изменении валюты.
  • Новая запись в блоге пользователя уведомляет подписчиков.
  • Создание нового заказа в приложении для онлайн-покупок информирует другую службу в системе.
  • Служба оркестратора хочет получать уведомления, когда служба A завершает задачу и когда передать задачу службе B в конвейере приема данных и т. д.

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

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

опрос для изменений против вебхука


Что такое вебхук?

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

Веб-перехватчики обычно используются для уведомления клиентов о событиях в режиме реального времени по мере их возникновения. Обычно они принимают форму конечных точек HTTP POST, которые можно запрашивать с телом JSON, и они полностью управляются потребителем событий. Производитель событий, например сервер API, может отправлять уведомления о событиях в веб-перехватчик, когда происходит что-то интересное.


Веб-перехватчик и шлюз API в архитектуре, управляемой событиями

Используя Webhook и API Gateway, вы можете создать управляемый событиями API, который можно отделить от основного кода приложения. Позволяет вам вызывать внешние системы, которые подписались через веб-перехватчики, в полной изоляции от кода вашего приложения.

Веб-перехватчик с API-шлюзом

Как вы можете видеть на предыдущей архитектурной схеме, есть два основных потока.


Процесс подписки

Процесс подписки на первый поток.png

В первом потоке слева пользователи API могут подписаться на API, зарегистрировав URL-адрес веб-перехватчика в качестве обратного вызова. Приложение-потребитель подписывается на изменения в ресурсе, выполняя вызов POST (с URL-адресом обратного вызова в теле) к конечной точке API подписки на ресурсы (например, /{resource}/subscribe), доступный в шлюзе API. Как только шлюз API получает вызов, он направляет запрос в службу подписки, которая затем добавляет сведения о подписчике в базу данных.

Также можно отписаться от API. В этом сценарии задачи шлюза API сначала идентифицируют неизвестные сообщения, поэтому убедитесь, что запрос всегда аутентифицирован, а учетные данные действительны. 2xx response сразу же в качестве подтверждения или если запрос не может быть аутентифицирован или возникла ошибка при передаче полезной нагрузки в промежуточную систему, возвращается ошибка. Затем он также передает запрос ответственной службе на основе пути, предоставленного потребителем.


Процесс обратного вызова

второй поток обратного вызова process.png

Во втором потоке справа мы доставляем события потребителям API асинхронно через компонент обратного вызова и шлюз API. Служба прослушивателя событий запрашивает базу данных по мере того, как подписчики сопоставляются с конкретными обработанными событиями. Затем служба прослушивателя событий создает команды обратного вызова и публикует их в концентраторе событий, чтобы служба обратного вызова могла выполнять все вызовы API (и при необходимости повторять попытки) через шлюз API.

Там API Gateway играет не только роль обратного прокси, но и может конвертировать внутренние вызовы из одного формата в другой. Например, служба обратного вызова использует другой AMQP (Advanced Message Queuing Protocol), протокол обмена сообщениями, но API должен сделать вызов REST к конечной точке обратного вызова потребителя, в этом шлюзе шлюз API, такой как Апач APISIX может помочь. Он может получить запрос REST, затем преобразовать его в нужный формат и направить в службу, получить ответ и вернуть его клиенту в формате REST, используя свой разные плагины.

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

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


Резюме

Как мы поняли из поста, Webhook пытается отделить такие проблемы, как подтверждение сообщения и обработка сообщений в API, и не выполняется синхронная бизнес-логика. Однако приведенный выше архитектурный пример, который мы обсуждали, может быть сложным для реализации шаблоном, учитывая, что он имеет много движущихся частей, а API не знает о том, что конечная точка потребляющего приложения запущена и работает, но это можно улучшить. В дополнение к этому веб-перехватчики вынуждают потребителя событий устанавливать общедоступную конечную точку HTTP для получения недостаточно безопасных событий. Мы можем защитить его должным образом, включив какой-либо механизм аутентификации (базовая аутентификация, JWT или другие способы) с возможностями шлюза API.


Связанные ресурсы

➔ Создание сервисов API, управляемых событиями, с использованием CQRS, API Gateway и Serverless.

Шлюз API.


Рекомендуемый контент 💁

➔ Посмотрите видеоурок:

➔ Читайте сообщения в блоге:


Сообщество⤵️

🙋 Присоединяйтесь к сообществу Apache APISIX
🐦 Следуйте за нами на Twitter
📝 Найдите нас в Slack
📧 Напишите нам с вашими вопросами.