EventGrid против EventHub

Question

Я работаю над приложением Service Fabric и хочу опубликовать несколько событий из этого приложения и подписаться или обработать эти события публикации в другом приложении.

Я попробовал концепцию EventGrid и заметил, что при публикации и обработке событий возникает задержка.Итак, теперь я ищу другие альтернативы, такие как EventHub или Queues и т. Д.

Если кто-то уже использовал EventGrid, EventHud или Queues и т. Д., Пожалуйста, предложите, какой из них даст больше производительности, когда мы имеем делос большим количеством событий.

Подход к проектированию

Мы перенесли таблицы из службы SQL в Service Fabric.В SQL Service есть представление, и мы планируем реализовать его как службу в сервисной структуре.

Логика реализации приведена ниже.

1. В таблице 1 реализована служба, и мы публикуемсобытие для каждой операции CRUD в EventGrid / EventHud.
2. В таблице 2 реализован сервис, и мы публикуем событие для каждой операции CRUD в EventGrid / EventHud.
3. Мы создали сервис представления, в котором он прослушиваетк событиям, когда любое событие отправляется в EventGrid / EventHud, оно выполнит необходимые вычисления и сохранит их в ViewService (это фоновое задание)

Мы ищем службу обмена сообщениями, которая обеспечивает более высокую производительность.

Answer 1

Можете ли вы описать своего издателя, подписчика и т. Д. И показать свои показатели использования таблицы событий Azure?

Вы можете использовать фрагменты экрана портала по теме (издатель) и подписке (подписчик).

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

Сторона издателя:

Абонентская сторона:

Метрики на портале:

Как видите, время обработки пункта назначения доставки составляет ~ 1 мс. Время задержки на стороне издателя (настраиваемая тема) составляет 2-4 мс.

Обратите внимание, что AEG представляет собой PUSH-> PUSH-ACK или PUSH-> PULL-ACK , в котором происходит событие со слабо дециклированной моделью Pub / Sub вместо модели Event Hub, основанной на Механизм PUSH-> PULL , другими словами, концентратор событий должен содержать приемник и приемник для извлечения события из раздела.

Answer 2

Вы видели это сравнение и это ?

В любом случае, можете ли вы уточнить ваши требования с точки зрения пропускной способности и производительности?Это зависит от множества факторов, включая, но не ограничиваясь этим, размер сообщения и количество сообщений.

Используя и сетку событий, и концентратор событий, я бы сказал, что концентратор событий работает очень хорошо для многих сообщений вво-вторых, скажем, потоки данных от iot-устройств, но производительность нисходящей обработки может быть узким местом.Вы должны обрабатывать их очень быстро, чтобы получать новые события.Кроме того, существуют разделы и группы потребителей, которые могут помочь сбалансировать нагрузку и иметь разные процессоры для одних и тех же данных, но с разным представлением о потоке данных.(Быстрый процессор для оперативного отображения данных датчика и более медленный для хранения данных для последующего анализа)

Если вы говорите о нескольких событиях, генерируемых приложением, которое запускает другие приложения, чтобы начать выполнять какую-то работуна основе этих событий Event Grid хорошо подходит.Я не испытывал особой задержки при получении этих событий.

Но суть, я думаю, что все сервисы (Event Grid, Event Hub, Service Bus и т. Д.) Поддерживают разные варианты использования, и это должно быть вашей первой точкой принятия решения.