В поисках идеального сервиса Azure для честной обработки данных в Producer - схема потребителя

Question

Я пытаюсь справиться с ситуацией, показанной на следующем рисунке.

У нас есть несколько клиентов = производителей (также 1 клиент = 1 до N производителей). Нам нужно обрабатывать данные от каждого производителя справедливо (= отдельный вариант будет лучшим вариантом), потому что может случиться так, что один производитель отправит нам огромное количество данных, и если для всех производителей будет только одна очередь, то остальные производители будет заблокирован. Поэтому мы должны гарантировать, что ни один производитель не будет заблокирован и справедливо обслужен потребителями.

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

Проблема в том, что количество производителей будет динамически расти с увеличением количества клиентов, поэтому нам необходимо динамически создавать очереди и потребителей.

Более того, нам нужно справиться с другими трудностями с данными от производителей. Нам необходимо убедиться, что более старые данные от источника A будут обработаны раньше, чем более новые данные от того же производителя A. (Примечание: производители независимы друг от друга, поэтому более новые данные от производителя B могут быть обработаны до более старых данных от производителя A.)

Согласно моим исследованиям, не будет проблем с использованием хранилища Azure Queue в качестве Queue (это не проблема для динамического создания очередей с помощью queue.CreateIfNotExists();). НО я не знаю, что использовать в качестве правильного потребителя. Я знаю, что существует множество служб Azure, например: функция Azure, веб-работа Azure, концентратор событий Azure и т. Д.

Мой вопрос: Каков наилучший вариант для этого варианта использования в качестве потребителей?

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

Заранее спасибо за любые советы!

Answer 1

Это интересный вариант использования, но, на мой взгляд, функции будут вашим лучшим выбором для потребителя.Я бы инкапсулировал бизнес-логику в отдельный файл, поэтому все отдельные функции имеют привязку очереди и вызов этого отдельного файла:

File 1:
public static Task DoStuff(string myQueueItem, ILogger log)
{
    //tranforms here

}

File 2 - n:

[FunctionName("ConsumerA")]
public static void QueueTrigger(
    [QueueTrigger("myqueue-items")] string myQueueItem,
    ILogger log)
{
    await DoStuff(myQueueItem, log);

}

Наряду с созданием / удалением очереди вы можете используйте API управления для создания и удаления функций.Каждый раз, когда вы создаете его, вы настраиваете имя и имя очереди так, чтобы она привязывалась к новой очереди.

Вы можете несколько управлять параллельной обработкой, изменяя свойство "maxOutstandingRequests" в файле host.json файл.В плане потребления максимальное количество запросов будет приходиться на каждый экземпляр приложения. Если для вас установлено значение, равное единице, а хост масштабируется до трех экземпляров, то три сообщения будут обрабатываться одновременно. Масштабирование немного отличается , если вы используете стандартный план обслуживания приложений, но все же это можно сделать динамически.Такое динамическое масштабирование пользовательских экземпляров, вероятно, будет полезно при несовместимых объемах данных - большие объемные дампы данных будут обрабатываться быстрее, но вам не придется располагать ресурсами, когда все тихо.

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