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

Область применения: ✔️ 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 (Classic) для запроса. Группа источников или внутренний пул, заданный обработчиком правил, переопределяет процесс маршрутизации, описанный в этой статье.

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

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

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

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 не может гарантировать, что настроенные веса строго соблюдаются, и балансировка нагрузки может казаться перекошенной.

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

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

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

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

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

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

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

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

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

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

Примечание

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

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

Сходство сеансов устанавливается в следующих случаях за пределами стандартных не кэшируемых сценариев:

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

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

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