Несколько типов событий в теме Azure EventGrid

Каковы лучшие практики в отношении тем и событий Azure EventGrid?

Не стоит ли публиковать разные типы событий в одной теме Azure EventGrid? например несколько разных событий домена

Когда нам нужны разные темы? Единая общая тема для всего приложения? Одна тема для каждого типа совокупного корня? Одна тема для каждого типа события?

Любые предложения приветствуются, поскольку нет четких ответов

Часть 2.

Что, если я хочу интегрироваться с различными приложениями Azure Logic? если несколько приложений логики будут реагировать на одну и ту же тему, украдут ли они сообщения друг у друга? Создает ли каждое приложение логики какую-то невидимую подписку?

Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
Как установить LAMP Stack - Security 5/5 на виртуальную машину Azure Linux VM
В предыдущей статье мы завершили установку базы данных, для тех, кто не знает.
Как установить LAMP Stack 1/2 на Azure Linux VM
Как установить LAMP Stack 1/2 на Azure Linux VM
В дополнение к нашему предыдущему сообщению о намерении Azure прекратить поддержку Azure Database для MySQL в качестве единого сервера после 16...
1
0
713
2

Ответы 2

Сетка событий Azure (AEG) не является общей моделью Pub / Sub. Эта модель основана на источнике событий, где каждый источник события (topicType) обрабатывает собственный интерес.

Подписчик подписывается на интерес к источнику события (теме) с помощью подписки. Обратите внимание, что AEG позволяет подписаться только на одну тему в подписке. Существует ограничение на 500 подписок на тему.

Другими словами, если один и тот же подписчик проявляет несколько интересов к источнику события (теме), эта модель требует создания нескольких подписок (по одной на тему) для каждого подписчика. Фильтрация интересов возможна только в рамках одной темы.

Источник событий в AEG может быть расширен настраиваемыми темами (максимум 100 на подписку Azure).

Основываясь на вышеизложенном, я рекомендую для настраиваемых тем использовать ту же модель, что и встроенная для источников событий Azure (topicTypes) с несколькими типами событий, которые можно упростить при непрерывном развертывании в средах.

К Части 2: AEG не использует «невидимую» подписку как часть интеграции. Каждая подписка, созданная на тему, видна и доступна, например, с помощью REST API

Обновлять:

Azure Event Grid недавно выпустила (предварительная версия - версия 2018-09-15-preview) новую функцию, которая может быть полезна для вашего решения с помощью Домен события и Темы домена, подробнее здесь.

Вы можете использовать обновленный инструмент Тестер сетки событий Azure для тестирования всех новых функций предварительной версии, которые еще не реализованы в пользовательском интерфейсе портала Azure.

Нет, неплохо публиковать разные типы событий в одной теме Azure EventGrid: если события связаны с одним и тем же ресурсом, имеет смысл публиковать их в одной теме EventGrid. На примере HR-приложения вы можете опубликовать события EmployeeAdded и EmployeeRemoved по одной и той же теме «сотрудник».

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

Что касается вопроса о приложениях логики, если вы создаете несколько приложений логики, которые обрабатывают события из одной и той же темы, каждое из них создает подписку на события по той же теме, а Сетка событий доставляет события по этой теме в каждый подписок на события. Таким образом, каждое приложение логики будет получать одно и то же событие по отдельности и может обрабатывать его независимо от других приложений.

Другие вопросы по теме