Методы маршрутизации трафика к источнику

Область применения: ✔️ Front Door Standard ✔️ Front Door Premium ✔️ Front Door (классическая версия)

Важный

Azure Front Door (classic) будет прекращён 31 марта 2027 года. Чтобы избежать нарушений работы служб, важно перенести профили Azure Front Door (классический) на уровень Azure Front Door standard или Premium к марту 2027 года. Для получения дополнительной информации, см. прекращение обслуживания Azure Front Door (classic).

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

Примечание

В этой статье термин Origin относится к серверной части, а термин группа источников относится к пулу серверов в конфигурации Azure Front Door (классической версии).

Четыре метода маршрутизации трафика:

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

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

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

• Привязка сессии: Гарантирует, что запросы от одного и того же конечного пользователя отправляются к одному и тому же источнику, настраивая привязку сессии для ваших фронтенд-хостов или доменов.

Примечание

В уровнях Azure Front Door Standard и Premium, Имя конечной точки называется Frontend host в Azure Front Door (classic).

Все конфигурации Front Door включают мониторинг работоспособности бэкенда и автоматическое глобальное переключение при отказе. См. раздел Мониторинг бекенда Front Door для получения дополнительной информации. Azure Front Door может использовать один метод маршрутизации или объединить несколько методов для создания оптимальной топологии маршрутизации на основе потребностей приложения.

Примечание

С помощью обработчика правил Front Door можно настроить правила для переопределения конфигураций маршрутов на уровнях Azure Front Door standard и Premium или переопределить внутренний пул в Azure Front Door (классическая версия) для запроса. Группа исходных данных или пул серверов, установленные механизмом правил, переопределят процесс маршрутизации, описанный в этой статье.

Общий поток решений

Следующая диаграмма иллюстрирует общий поток принятия решений.

Этапы принятия решения:

1. Доступные источники: Выберите все источники, которые включены и находятся в хорошем состоянии (200 OK) по результатам проверки работоспособности.
   • Пример: Если имеется шесть источников A, B, C, D, E и F, и C является неисправным, а E отключен, то доступные источники - это A, B, D и F.
2. Приоритет: Выберите наиболее приоритетные источники из доступных.
   • Пример: Если источники A, B и D имеют приоритет 1, а источник F — приоритет 2, то выбранными источниками будут A, B и D.
3. Сигнал задержки (на основе пробы работоспособности): Выберите источники в допустимом диапазоне задержки из среды Front Door, в которой поступил запрос. Это основано на настройке чувствительности к задержке группы источников и задержке ближайших источников.
   • Пример: если задержка до источника A составляет 15 мс, до B — 30 мс, а до D — 60 мс, и чувствительность к задержке установлена на 30 мс, выбор падает на источники A и B, так как D превышает порог в 30 мс.
4. Веса: Распределяйте трафик между конечными выбранными источниками на основе указанных коэффициентов веса.
   • Пример: Если у источника А вес 3, а у источника B вес 7, то трафик распределяется 3/10 на А и 7/10 на B.

Если прилипание к сеансу включено, первый запрос в сеансе следует ранее описанному потоку. Последующие запросы отправляются на источник, выбранный в первом запросе.

Маршрутизация трафика на основе минимальной задержки

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

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

Примечание

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

Дополнительные сведения см. в статье об архитектуре маршрутизации Azure Front Door.

Приоритезированная маршрутизация трафика

Для обеспечения высокой доступности организации часто разворачивают резервные службы, которые берут на себя работу в случае отказа основного сервиса. Эта конфигурация известна как активный/резервный или активный/пассивный вариант развертывания. Метод маршрутизации трафика Priority в Azure Front Door позволяет эффективно реализовать этот шаблон резервного переключения.

По умолчанию Azure Front Door направляет трафик к источникам с наивысшим приоритетом (с наименьшим значением приоритета). Если эти основные источники станут недоступны, трафик будет направляться на вторичные источники (следующее наименьшее значение приоритета). Этот процесс продолжается с третичными источниками, если как первичные, так и вторичные источники недоступны. Зондирования состояния проверяют доступность источников на основе их сконфигурированного состояния и здоровья.

Настройка приоритетов для источников

В каждой исходной точке вашей группы источников Azure Front Door есть свойство Priority, которое может быть установлено в значение от 1 до 5. Низкие значения означают более высокий приоритет. Несколько источников могут иметь одинаковое значение приоритета.

Метод маршрутизации трафика с учетом веса

Примечание

Для клиентов с очень низким показателем RPS (запросы в секунду) из-за того, как расположены узлы POP и устройства AFD, мы не можем гарантировать, что клиентские настройки весов будут строго соблюдаться, и балансировка нагрузки может казаться несбалансированной.

Метод маршрутизации трафика с использованием веса позволяет распределять трафик на основе предопределённых весов.

В этом методе вы назначаете вес каждому источнику в вашей группе источников Azure Front Door. Вес является целым числом от 1 до 1000 с значением по умолчанию 50.

Трафик распределяется среди доступных источников с использованием механизма цикла на основе указанных весовых коэффициентов, при условии, что источники соответствуют допустимой чувствительности к задержке. Если чувствительность к задержке установлена на 0 миллисекунд, веса применяются только в том случае, если два источника имеют одинаковую сетевую задержку.

Взвешенный метод поддерживает несколько сценариев:

• Постепенное обновление приложения: перенаправьте процент трафика в новый источник и постепенно увеличивайте его с течением времени.
• Миграция приложений в Azure: создайте группу источников как с Azure, так и с внешними источниками. Настройте веса, чтобы предпочесть новые источники, постепенно увеличивая их долю трафика, пока они не обрабатывают большую часть трафика, а затем отключите и удалите менее предпочтительные источники.
• Масштабирование облаков для дополнительной емкости: расширение локальных сред в облако путем добавления или включения дополнительных источников и указания распределения трафика.

Сходство сеансов

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

Azure Front Door использует привязку сеанса, основанную на cookies, где управляемые cookies с SHA256 от URL источника используются в качестве идентификатора. Это направляет последующий трафик из пользовательской сессии к тому же источнику.

Сохранение сеанса может быть включено на уровне группы источников в планах Azure Front Door Standard и Premium, а также на уровне фронтенд-хоста в Azure Front Door (классический) для каждого настроенного домена или поддомена. После включения Azure Front Door добавляет файлы cookie с именем ASLBSA и ASLBSACORS в сеанс пользователя. Эти cookies помогают идентифицировать разных пользователей, даже если они используют один и тот же IP-адрес, что позволяет равномернее распределять трафик между источниками.

Срок действия cookie совпадает с пользовательской сессией, так как Front Door в настоящее время поддерживает только сессионные cookies.

Примечание

Сходство сеансов поддерживается с помощью файла cookie сеанса браузера на уровне домена. Поддомены в одном и том же универсальном домене могут использовать общую согласованность сеансов, если браузер пользователя отправляет запросы для одного и того же исходного ресурса.

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

Устойчивость сессии будет установлена в следующих случаях, выходящих за рамки стандартных некэшируемых сценариев:

• Ответ включает заголовок Cache-Control с no-store.
• Ответ содержит допустимый Authorization заголовок.
• Ответ — это код состояния HTTP 302.

Следующие шаги

• Узнайте, как создать Azure Front Door.
• Узнайте как работает Azure Front Door.