Как Azure Function App Scale для миллионов одновременных пользовательских запросов

Question

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

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

Поскольку для URI приложения функции назначен только один IP-адрес, как Azureобеспечивает горизонтальное масштабирование в этом случае (условие экстремальной пиковой нагрузки)?

Использует ли он какой-то внутренний балансировщик нагрузки, а затем создает новую временную виртуальную машину (для распределения нагрузки и) для запуска экземпляра приложения функции в условиях нагрузки (когда определенное количество одновременных пользователей / подключение пытаетсяполучить доступ к функции URI)?

Но даже в этом случае не будут исчерпаны внутренние IP-адреса для экземпляров виртуальных машин, которые сбалансированы с помощью внутреннего балансировщика нагрузки?Должна существовать пороговая точка, когда в плане обслуживания приложения будет исчерпан пул внутреннего IP-адреса для назначения масштабируемых виртуальных машин.

И снова, как можно запустить неограниченное веб-приложение, мобильное приложение API наПлан обслуживания приложения Azure с учетом этого сценария без исчерпания внутреннего пула IP-адресов?

Answer 1

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

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

Внутренняя архитектура службы приложений состоит из - Front End - Семислойного балансировщика нагрузки Web Worker - Файловых серверов веб-серверов - Для хранения содержимого приложения

Чтобы ответить на следующие вопросы -

В. Поскольку для URI приложения функции назначен только один IP-адрес, как Azure обеспечивает горизонтальное масштабирование в этом случае (условие экстремальной пиковой нагрузки)?

Q.Использует ли он какой-то внутренний балансировщик нагрузки, а затем создает новую временную виртуальную машину (чтобы распределить нагрузку и) для запуска экземпляра приложения функции в условиях нагрузки (когда определенное число одновременных пользователей / соединений пытается получить доступ к URI функции)?

A: Он не создает новую временную виртуальную машину, а использует веб-работников, которые являются предварительно подготовленными виртуальными машинами, работающими с общей нагрузкой.Front end - это многоуровневый балансировщик нагрузки, отвечающий за распределение трафика в случае горизонтального масштабирования.

Но даже в этом случае он не исчерпает внутренние IP-адреса для экземпляров виртуальных машин, которые сбалансированы с внутренней нагрузкой.балансировщик нагрузки?Должна существовать пороговая точка, когда в плане обслуживания приложения будет исчерпан пул внутреннего IP-адреса для назначения масштабируемых виртуальных машин.

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