Функция Azure-дросселирование запуска служебной шины

В настоящее время я оцениваю использование служебной Шины и функции azure для запуска некоторой работы, которую необходимо выполнить с помощью нисходящего вызова api. Все это довольно стандартно, за исключением того, что у меня нет хорошей обработки того, что происходит, когда нисходящая система перегружена и/или возвращает заголовки в дроссель (т. е. максимальное число вызовов в минуту/и т. д.). Мы, кажется, не имеем никакого динамического контроля над принудительным дросселированием триггера очереди.

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

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

Вариант 1:

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

• Queue1-полная скорость или максимальная скорость. Если мы начинаем получать ограничение скорости, установите значение кэша. Если задано значение кэша, то не обрабатывайте сообщение, а клонируйте его и поместите в queue2
• Queue2-ниже на максимальное число параллелизма / предварительной выборки. Тот же процесс, что и выше, но толчок в queue3.
• Queue3-наименьшее значение на максимальное число параллелизма / предварительной выборки. Мы просто медленно обрабатываем их.

В основном очередь 1 становится контроллером для queue2 и queue3, когда нисходящий поток система насыщена.

Вариант 2:

Мы можем клонировать сообщение и запрашивать его в будущем и продолжать делать это, пока все они не станут процессами. Сохраняет одну очередь и просто запрашивает, пока мы не обработаем ее.

Вариант 3:

Предполагая, что у нас есть свой собственный план приложения, который посвящен вместо потребления, я думаю, что мы можем Thread.Sleep функции, если они приближаются к ограничению скорости или вниз и продолжают повторять попытки. Это, вероятно, может быть ... расчет максимального параллелизма, экземпляров и ограничений скорости. Я бы не рассматривал это в плане потребления, поскольку спальные места могут резко увеличить расходы.

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

Править: Я хотел бы добавить, что я закачал 1 миллион сообщений в очередь служебной шины, которая была запланирована во время отправки. Я наблюдал за функцией лазури (план потребления) масштаб, чтобы ударить около 1500 в секунду, чтобы обеспечить хорошую метрику. Я еще не знаю, как будут действовать посвященные.

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

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