#azure #azure-functions #azure-eventhub #event-driven
Вопрос:
Возможно ли создать концентратор событий Azure с несколькими прослушивателями в одном приложении? То, что я ищу, — это вызвать событие в одном концентраторе и заставить две функции Azure прослушивать его, чтобы они оба могли выполнять задачу на основе одного и того же события.
Я реализовал это в данный момент с помощью «Групп потребителей», но это кажется неправильным, так как я чувствую, что это следует использовать, когда у вас есть несколько приложений, считывающих события.
Есть ли лучший механизм для этого, или я смотрю на это неправильно?
Спасибо
Ответ №1:
Да, это возможно. Общий ответ на наилучший подход к этому — «это зависит от вашего приложения». В описываемом вами сценарии вам потребуется использовать две отдельные группы потребителей из-за того, как работают привязки функций Azure.
Внутренне привязки функций используют обработчик событий, который попытается сотрудничать с другими процессорами, работающими против группы потребителей, для совместного выполнения работы и предотвращения чтения двух экземпляров из одного раздела. Такое же сотрудничество имело бы место, если бы вы также размещали один из типов обработчиков событий в своем приложении.
Для других типов потребителей, доступных в SDK концентраторов событий, работа с одной и той же группой потребителей не является проблемой, если у вас меньше задокументированных квот. (на момент написания статьи это составляло 5 потребителей на группу)
Комментарии:
1. Идя по пути группы потребителей, это потенциально может иметь серьезные финансовые последствия? В стандартной модели ценообразования вы ограничены 20 группами потребителей, но это на уровне пространства имен. Поэтому, если бы у меня была новая Группа потребителей для каждого события, для которого требовался второй слушатель, то у меня быстро закончились бы Группы потребителей. Кажется странным, что я был бы так ограничен чем-то, что должно быть моделью подписки на публикацию.
2. Безусловно; если вы расширяетесь до нескольких потребителей, я бы рекомендовал рассмотреть другие модели или варианты. На ум приходит избегание привязок и использование клиента-потребителя в функции, запускаемой HTTP, вызываемой сеткой событий. Тот же базовый подход сработал бы, если бы одна функция прослушивала концентратор событий, а затем вызывала другие функции, запускаемые HTTP. В зависимости от масштаба, возможно, также стоит рассмотреть Служебную шину с Разделами/подписками или шаблон проверки утверждений с использованием хранилища больших двоичных объектов с триггером сетки событий. Каждый, конечно, имеет свои дополнительные сложности и компромиссы.
3. Насколько я читал, у вас есть 20 групп потребителей на концентратор событий, а не на пространство имен в стандартной цене: там указано «Количество групп потребителей на концентратор событий» — см. docs.microsoft.com/en-us/azure/event-hubs/event-hubs-quotas
4. Вы правы. Прошу прощения, это моя ошибка.