Функция Azure: ограничение количества сообщений параллельной служебной шины

ProgramBox

Функция Azure: ограничение количества сообщений параллельной служебной шины

Post author:admin
Запись опубликована:27 ноября, 2022
Post category:Вопросы по программированию

#azure #azure-functions #azureservicebus

#azure #azure-функции #azureservicebus

Вопрос:

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

Я думаю, что параметр MaxConcurrentSessions в host.json может мне помочь, я мог бы ограничить его примерно 20 сообщениями одновременно. Я мог бы также посмотреть на «Принудительное ограничение масштабирования» в приложении функции, но я предполагаю, что это не обязательно ограничит количество сообщений, обрабатываемых за один раз. Будет ли MaxConcurrentSessions лучшим вариантом для выбора или есть другие соображения?

Другим подходом (возможно, в дополнение к вышесказанному) было бы «приостановить» или запретить функции принимать какие-либо дополнительные сообщения в течение определенного периода времени после того, как я достигну предела API. Кто-нибудь знает, можно ли программно приостановить выполнение функции Azure в режиме реального времени или запретить ей принимать дополнительные сообщения?

1. Мое предложение maxConcurrentCalls использовать механизм retry. Повторная попытка может работать с кодом состояния http 429. Теперь либо сообщение может быть отправлено в запрос, либо время, возвращаемое http-запросом, может быть ожидаемо в вашей программе перед повторной попыткой http-запроса. Вы можете использовать Polly для повторной попытки.

2. Спасибо. Да, у меня есть механизм повторных попыток. Я вижу значения «повторить попытку» более 10 минут, что может быть проблемой, поскольку мы находимся в плане потребления, и время ожидания функции истекает через 10 минут

3. В этом случае вы можете повторно поставить сообщение в очередь служебной шины с ScheduledEnqueueTime помощью as DateTime.UtcNow.AddMinutes(retryAfter);

4. Проблема в том, что мне нужно, чтобы сообщения обрабатывались в том порядке, в котором они были обработаны (для каждого идентификатора сеанса). Если я снова поставлю его в очередь, он отправится в конец очереди

Ответ №1:

Я думаю, что параметр MaxConcurrentSessions в host.json может мне помочь, я мог бы ограничить его примерно 20 сообщениями одновременно. Я мог бы также посмотреть на «Принудительное ограничение масштабирования» в приложении функции, но я предполагаю, что это не обязательно ограничит количество сообщений, обрабатываемых за один раз. Будет ли MaxConcurrentSessions лучшим вариантом для выбора или есть другие соображения?

Вы можете использовать MaxConcurrentCalls для ограничения максимального количества одновременных вызовов обратного вызова, которые должна инициировать перекачка сообщений. По умолчанию среда выполнения функций обрабатывает несколько сообщений одновременно. Если вы установите значение 1, одновременно будет обрабатываться только одно сообщение очереди или темы.

Структура выглядит следующим образом:

 {
    "version": "2.0",
    "extensions": {
        "serviceBus": {
            "prefetchCount": 100,
            "messageHandlerOptions": {
                "autoComplete": true,
                "maxConcurrentCalls": 1,
                "maxAutoRenewDuration": "00:05:00"
            },
            "sessionHandlerOptions": {
                "autoComplete": true,
                "messageWaitTimeout": "00:00:30",
                "maxAutoRenewDuration": "00:55:00",
                "maxConcurrentSessions": 1
            }
        }
    }
}

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

Ответ №2:

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

Я бы также предложил рассмотреть атрибут Singleton как способ управления параллелизмом масштабирования (см. Документы Microsoft). Это обеспечит контроль над параллелизмом вплоть до функционального уровня. В документах также обсуждается ваш сценарий его использования с MaxConcurrentSessions / Calls.

Метки: Функция Azure: ограничение количества сообщений параллельной служебной шины