Примечание.
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
В планах "Потребление", "Гибкое использование" и "Премиум" функции Azure масштабируют ресурсы, добавляя дополнительные экземпляры на основе числа событий, которые запускают функцию.
Способ масштабирования приложения-функции зависит от плана размещения:
План потребления. Каждый экземпляр узла Функций в плане потребления ограничен, как правило, 1,5 ГБ памяти и одним ЦП. Экземпляр узла поддерживает всё функциональное приложение. Таким образом, все функции в приложении функции, которые совместно используют ресурсы в одном экземпляре, масштабируются одновременно. Когда приложения-функции используют тот же план потребления, они по-прежнему масштабируются независимо.
План потребления Flex: План использует детерминированную стратегию масштабирования для каждой функции. Каждая функция масштабируется независимо, за исключением функций HTTP, BLOB-объектов и устойчивых функций, которые масштабируются в собственных группах. Дополнительные сведения см. в статье о масштабировании для каждой функции. Затем эти экземпляры масштабируются на основе одновременности запросов.
План "Премиум": конкретный размер плана Premium определяет доступную память и ЦП для всех приложений этого плана в этом экземпляре. План масштабирует экземпляры на основе масштабируемости приложений, а приложения, соответственно, масштабируются в рамках плана по мере необходимости.
Файлы кода функции хранятся в файловых ресурсах Azure в основной учетной записи хранения службы "Функции Azure". При удалении основной учетной записи хранения приложения-функции файлы кода функции удаляются и не могут быть восстановлены.
Масштабирование среды выполнения
"Функции Azure" используют компонент, называемый контроллером масштабирования, чтобы отслеживать скорость событий и определять, нужно ли масштабировать вверх или вниз. Контроллер масштабирования использует эвристику для каждого типа триггеров. Например, при использовании триггера хранилища очередей Azure используется целевое масштабирование.
Единицей масштабирования для Функций Azure является приложение-функция. При масштабировании приложения-функции выделяются дополнительные ресурсы для выполнения нескольких экземпляров хоста Azure Functions. И наоборот, когда потребность в вычислительных ресурсах уменьшается, контроллер масштабирования удаляет экземпляры серверов функций. Число экземпляров в конечном итоге уменьшается, когда функции не выполняются в приложении с функциями.
Холодный запуск
Если ваше приложение-функция простаивает в течение нескольких минут, платформа может принять решение уменьшить количество экземпляров, на которых выполняется ваше приложение, до нуля. В следующем запросе добавлена задержка масштабирования от нуля до единицы. Эта задержка называется холодным запуском. Количество зависимостей, необходимых функциональному приложению, способно влиять на время холодного запуска. Холодный запуск является более серьезной проблемой для синхронных операций, таких как триггеры HTTP, которые должны возвращать ответ. Если холодные запуски влияют на ваши функции, рассмотрите возможность использования другого плана, кроме "Consumption". Другие планы предлагают следующие стратегии для смягчения или устранения проблем холодного старта:
План "Премиум": поддерживает как предварительно подготовленные экземпляры, так и всегда готовые экземпляры с минимальным количеством экземпляров.
План потребления Flex: поддерживает необязательное количество всегда готовых экземпляров, которые можно определить на основе масштабирования каждого экземпляра.
Выделенный план: сам план не масштабируется динамически, но вы можете непрерывно запускать приложение при включении параметра Always on .
Понимание поведения при масштабировании
Масштабирование может отличаться в зависимости от нескольких факторов, а приложения масштабируются по-разному в зависимости от выбранных триггеров и языка. Следует учитывать следующие особенности поведения масштабирования:
- Максимальные экземпляры: приложение-функция масштабируется только до максимально допустимого числа, определённого планом. Однако один экземпляр может обрабатывать несколько сообщений или запросов одновременно. При необходимости можно указать меньшее значение для регулирования масштаба.
- Частота выделения нового экземпляра. Для триггеров HTTP новые экземпляры выделяются не чаще одного раза в секунду. Для триггеров, отличных от HTTP, новые экземпляры выделяются не чаще, чем каждые 30 секунд. Масштабирование выполняется быстрее при работе в плане категории "Премиум".
- Масштабирование на основе целевого объекта: Масштабирование на основе целевого объекта обеспечивает быструю и интуитивно понятную модель масштабирования для клиентов. В настоящее время этот метод масштабирования поддерживается для очередей и разделов служебной шины, очередей хранилища, Центров событий, Apache Kafka и расширений Azure Cosmos DB. Обязательно проверьте масштабирование на основе целевых объектов, чтобы понять их поведение масштабирования.
- Масштабирование для каждой функции: За некоторыми отметимыми исключениями, функции, работающие в рамках плана Flex Consumption, масштабируются на независимых экземплярах. Исключения включают триггеры HTTP и триггеры хранилища BLOB-объектов (Сетка событий). Каждый из этих типов триггеров масштабируется в виде группы в одних и тех же экземплярах. Аналогичным образом триггеры всех устойчивых функций также разделяют экземпляры и масштабируются вместе. Дополнительные сведения см. в разделе масштабирования для каждой функции.
- Максимально отслеживаемые триггеры: в настоящее время контроллер масштабирования может отслеживать только до 100 триггеров для принятия решений о масштабировании. Если у приложения более 100 триггеров на основе событий, решение о масштабировании принимается только на основе первых 100 триггеров, которые выполняются. Дополнительные сведения см. в рекомендациях и шаблонах для масштабируемых приложений.
Ограничение горизонтального масштабирования
Возможно, вы решите ограничить максимальное количество экземпляров, которые приложение может использовать для горизонтального масштабирования. Это ограничение наиболее распространено в случаях, когда подчиненный компонент, например база данных, имеет ограниченную пропускную способность. Максимальные ограничения масштабирования при выполнении различных планов размещения см. в разделе "Ограничения масштабирования".
План потребления Flex
По умолчанию приложения, работающие в плане потребления Flex, имеют ограничение общих 100 экземпляров. В настоящее время наименьшее максимальное число экземпляров равно 40, а наибольшее поддерживаемое значение числа экземпляров — 1000. При использовании команды az functionapp create для создания приложения функции в плане Flex Consumption используйте параметр --maximum-instance-count, чтобы задать эту максимальную численность экземпляров вашего приложения.
Хотя можно изменить максимальное количество экземпляров приложений Flex Consumption до 1000, квота на приложения будет достигнута ранее этого числа. Просмотрите квоты на использование памяти для региональной подписки для получения более подробной информации.
В этом примере создается приложение с ограничением на максимальное количество экземпляров 200.
az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200
В этом примере команда az functionapp scale config set используется для изменения максимального количества экземпляров для существующего приложения на 150:
az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150
Планы потребления и уровня "Премиум"
В плане Consumption или Elastic Premium можно указать меньшее максимальное ограничение для приложения, изменив значение functionAppScaleLimit параметра конфигурации сайта. Для параметра functionAppScaleLimit можно задать неограниченное значение (0 или null) или значение от 1 до максимального значения для приложения.
az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>
Поведение при сжатии ресурсов
Масштабирование на основе событий автоматически уменьшает емкость при снижении спроса на функции. Это сокращение достигается путем освобождения экземпляров от их текущих выполнений функций, а затем удаления этих экземпляров. Это поведение регистрируется в режиме стока. Льготный период для выполняемых в настоящее время функций может продлиться до 10 минут для приложений плана потребления и до 60 минут для приложений плана Flex Consumption и Premium. Масштабирование на основе событий и такое поведение не применимы к приложениям плана "Выделенный".
К поведению масштабирования применяются следующие рекомендации:
- Для приложений, работающих в Windows в плане потребления, только приложения, созданные после мая 2021 года, по умолчанию поддерживают режим очистки.
- Чтобы включить корректное завершение работы функций с помощью триггера Служебной шины, используйте расширение Служебной шины версии 4.2.0 или более поздней.
Масштабирование для каждой функции
Применяется только к плану потребления Flex.
План потребления Flex является уникальным в том, что он реализует поведение масштабирования для каждой функции. При масштабировании по функциям, за исключением триггеров HTTP, триггеров BLOB (Сетка событий) и Durable функции, все остальные типы триггеров в вашем приложении масштабирутся на независимых экземплярах. Триггеры HTTP в вашем приложении масштабируются все вместе как группа на одних и тех же экземплярах, как и все триггеры Blob (Event Grid), а также все триггеры Durable Functions, которые имеют собственные совместные экземпляры.
Рассмотрим приложение-функцию, размещенное планом потребления Flex, которое имеет следующие функции:
| function1 | function2 | function3 | функция4 | функция5 | функция6 | function7 |
|---|---|---|---|---|---|---|
| Триггер HTTP | Триггер HTTP | Триггер оркестрации (устойчивый) | Триггер действия (устойчивый) | Триггер служебной шины | Триггер Service Bus | Триггер Центров событий |
В этом примере:
- Две триггерные функции HTTP (
function1иfunction2) выполняются вместе на своих экземплярах и масштабируются вместе в соответствии с параметрами параллелизма HTTP. - Две долговечные функции (
function3иfunction4) работают вместе на своих экземплярах и масштабируются вместе на основе настроенных дросселей параллелизма. - Активируемая функция
function5Service Bus выполняется самостоятельно и масштабируется независимо в соответствии с целевыми правилами масштабирования для очередей и тем службы. - Активируемая функция
function6служебной шины выполняется самостоятельно и масштабируется независимо в соответствии с правилами масштабирования для очередей и тем служебной шины. - Триггер Центров событий (
function7) выполняется в собственных экземплярах и независимо масштабируется в соответствии с правилами масштабирования для Центров событий на целевой основе.
Рекомендации и шаблоны для масштабируемых приложений
В приложении-функции существует множество аспектов, влияющих на качество его масштабирования, в том числе конфигурация узла, занимаемая память среды выполнения и эффективность использования ресурсов. Дополнительные сведения см. в разделе Рекомендации по масштабируемости. Вам также следует учитывать поведение подключений при масштабировании приложения-функции. См. дополнительные сведения об управлении подключениями в службе "Функции Azure".
Если у приложения более 100 функций, использующих триггеры на основе событий, рассмотрите возможность разбиения приложения в одно или несколько приложений, где каждое приложение имеет менее 100 функций на основе событий.
Дополнительные сведения о масштабировании в Python и Node.js см. в разделе "Масштабирование и производительность" руководства разработчика по Python для функций Azure и разделе "Масштабирование и параллелизм" руководства разработчика по Функциям Azure для Node.js.
Следующие шаги
Дополнительные сведения см. в следующих разделах: