Передать HTTP-запрос из функции Azure через сетку событий

Question

Я начал продумывать прототип архитектуры для системы, которую я хочу построить на основе функций Azure и сетки событий.

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

На приведенной ниже диаграмме представлена ​​упрощенная версия архитектуры. Сетка событий будетКонечно, публиковать события и для других функций, но ради простоты…

Проблема, с которой я сейчас сталкиваюсь, заключается в том, что контекст исходного HTTP-запроса Webhook от внешнего поставщика теряется после того, как первая функциясрабатывает.Попытка отправить контекст как часть полезной нагрузки события в Event Grid выглядит как анти-шаблон, и, несмотря на это, я не могу заставить его работать (функция .done() где-то теряется в событии).Попытка просто использовать context.res = {} и context.done() в последней функции не будет отвечать на исходный HTTP-запрос поставщика.

Есть идеи здесь?Является ли вся архитектура одним большим анти-паттерном - будет ли он работать?Или я должен немедленно отправить HTTP-ответ в первой функции, вызванной запросом поставщика?

Спасибо!

Answer 1

Вы смешиваете два шаблона различий, таких как сообщения и события.Сетка событий Azure - это распределенная модель push-событий Pub / Sub, в которой подписчик подписывает интерес к источнику в свободной форме.

В вашем сценарии вы хотите использовать модель событий в обмене сообщениями.шаблон запроса-ответа в режиме синхронизации.Контекст обмена сообщениями запроса не может передаваться через модель событий Pub / Sub и обратно к анонимной конечной точке, такой как фактически точка для ответного сообщения.

Однако, есть несколько вариантов, как «логически» интегрировать этидва разных шаблона, ниже показаны некоторые из них:

1. с использованием запроса - replyTo шаблона обмена сообщениями, такого как полнодуплексный обмен данными, один для запроса идругой для replyTo.

2. с использованием запроса - ответа шаблона обмена сообщениями с состоянием опроса .По сути, ваша первая функция будет ожидать состояния подписчика, а затем вернется обратно к вызывающей стороне.В распределенной интернет-архитектуре мы можем использовать хранилище BLOB-объектов Azure для разделения состояния между частью синхронизации и частью обработки асинхронных событий.В вашем сценарии первый AF создаст этот большой объект аренды, затем запустит событие в AEG, а затем будет периодически опрашивать состояние в большом объекте аренды для завершения процесса агрегации (несколько подписчиков и т. Д.).

   Кроме того, для этого типа шаблона можно использовать Функция Azure Durable , чтобы упростить интеграцию с управляемой событиями моделью AEG.

В следующем фрагменте экрана показана диаграмма последовательности с использованием BLOB-объекта Azure Lease для совместного использования «состояния запроса» в распределенной модели.Обратите внимание, что этот шаблон псевдосинхронизации / асинхронности подходит для случаев, когда запрос-ответ обрабатывается в течение короткого времени, менее 60 секунд.

Дополнительные сведения об использовании объекта Lease Blob в функции Azure см. В моем ответе здесь .

.