Реализация архитектуры транзакционных исходящих событий в Azure

#azure #event-driven-design

#azure #дизайн, управляемый событиями

Вопрос:

У меня есть большое сообщение, отправленное в службу rest, оно может быть 100 КБ или 50 МБ. Мне нужно обработать его асинхронно, и похоже, что шаблон транзакционных исходящих событий подходит для моих нужд.

По сути, моя служба будет передавать данные в базу данных вместе с записью события в одной транзакции. Процесс будет опрашивать события и отправлять событие в очередь сообщений. Событие содержит ссылку на данные в БД, обычно через какой-либо уникальный идентификатор. Потребитель очереди запрашивает данные из базы данных, выполняет все, что ему нужно, а затем удаляет запись события из базы данных.

Этот шаблон хорошо документирован. Здесь и здесь приведены два места.

У меня есть разумное понимание того, как можно реализовать это на месте, в среде .net / sql server, с которой мы знакомы. Как это будет выглядеть в Azure? существуют ли другие способы, которыми я могу выполнять переходную запись в базу данных и очередь, для которых не требуется шаблон исходящих сообщений, или следуя шаблону исходящих сообщений, каким будет механизм, который опрашивает события в БД, и что будет предоставлять службу очереди?

Ответ №1:

Обычно, если вы хотите использовать шаблон транзакционных исходящих событий в Azure, вы можете использовать приложение логики или функцию Azure для получения событий в БД и отправки их в очередь. Это было бы здорово, если бы вы использовали канал изменений cosmos, чтобы ваша архитектура также была реактивной и хорошо работала при меньшем потреблении ресурсов.

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