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

Question

Каковы рекомендации по темам и событиям Azure EventGrid?

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

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

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

Part2.

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

Обновление:

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

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