Схема маршрутизации шлюза

Шлюз приложений Azure

Маршрутизация запросов к нескольким службам или нескольким экземплярам служб с помощью одной конечной точки. Шаблон полезен при желании:

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

Контекст и проблема

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

  • Несколько разрозненных служб . Приложение электронной коммерции может предоставлять такие услуги , как поиск, отзывы, корзина, отзыв и журнал заказов. В каждой службе реализован отдельный API-интерфейс, с которым должны взаимодействовать клиенты. При этом каждый клиент должен иметь информацию обо всех конечных точках для подключения к этим службам. Если изменяется любой API, приходится обновлять все клиенты. Если вы разделяете одну службу на две или несколько служб, приходится изменять код в самой службе и во всех клиентах.
  • Несколько экземпляров одной и той же службы . Системе может потребоваться выполнение нескольких экземпляров одной службы в одном или разных регионах. Выполнение нескольких экземпляров можно выполнять для балансировки нагрузки или для удовлетворения требований к доступности. Каждый раз, когда экземпляр выполняется вверх или вниз по требованию, клиент должен обновляться.
  • Несколько версий одной и той же службы. В рамках стратегии развертывания новые версии службы можно развертывать вместе с существующими версиями. Это называется голубым зеленым развертыванием. В этих сценариях клиент должен обновляться при каждом изменении процента трафика, который направляется в новую версию и существующую конечную точку.

Решение

Установите шлюз перед набором приложений, служб и развертываний. Используйте маршрутизацию на уровне приложений (уровень 7) для передачи запросов в соответствующие экземпляры.

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

Несколько разрозненных служб

Схема шлюза, сидящего перед службой поиска, службой заказа, службой журнала заказов, службой корзины и службой проверки.

Шаблон маршрутизации шлюза полезен в этом сценарии, когда клиент использует несколько служб. Если служба консолидирована, разложена или заменена, клиент не обязательно требует обновления. Он может по-прежнему направлять запросы в шлюз, а изменения затронут только маршрутизацию.

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

Несколько экземпляров одной службы

Схема шлюза, сидящего перед службой поиска в регионе 1 и службой поиска в регионе 2.

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

Экземпляры служб можно развертывать в одном или нескольких регионах. Шаблон geode описывает, как многорегионное, активное развертывание может повысить задержку и повысить доступность службы.

Несколько версий одной службы

Схема шлюза, сидящего перед службой поиска версии 1 и службой поиска версии 1.1.

Этот шаблон можно использовать для развертываний, позволяя управлять развертыванием обновлений для пользователей. Когда вы развертываете новую версию службы, она может работать параллельно с предыдущей. С помощью маршрутизации вы можете предоставлять клиентам разные версии службы, позволяя гибко применять разные стратегии обновления: добавочное, параллельное или полное развертывание выпусков. Если после развертывания новой версии службы возникнут проблемы, вы сможете быстро отменить любые изменения с помощью маршрутизации, и эти изменения никак не затронут клиенты.

Проблемы и рекомендации

  • Служба шлюза может ввести одну точку сбоя. Убедитесь, что он правильно разработан для удовлетворения требований к доступности. Рассмотрите возможности устойчивости и отказоустойчивости в реализации.
  • Служба шлюза может привести к узким местам. Убедитесь, что шлюз достаточно производителен для планируемой нагрузки и что его будет легко масштабировать в соответствии с ожидаемым темпом роста.
  • Выполните нагрузочное тестирование шлюза, чтобы исключить возможность каскадных сбоев служб.
  • Маршрутизация шлюза выполняется на 7-м уровне. Для этого можно использовать IP-адреса, порты, заголовки запросов и (или) URL-адреса.
  • Службы шлюза могут быть глобальными или региональными. Azure Front Door — это глобальный шлюз, а Шлюз приложений Azure — региональный. Используйте глобальный шлюз, если для решения требуется развертывание служб с несколькими регионами. Рассмотрите возможность использования Шлюз приложений, если у вас есть региональная рабочая нагрузка, требующая детального управления балансировкой трафика. Например, необходимо сбалансировать трафик между виртуальными машинами.
  • Служба шлюза — это общедоступная конечная точка для служб, которые она находится перед. Рассмотрите возможность ограничения доступа к серверным службам общедоступной сети, делая службы доступными только через шлюз или через частную виртуальную сеть.

Когда следует использовать этот шаблон

Используйте этот шаблон в следующих случаях:

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

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

Проектирование рабочей нагрузки

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

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

- ИЗБЫТОЧНОСТЬ RE:05
- Мониторинг работоспособности RE:10
Операционное превосходство помогает обеспечить качество рабочей нагрузки через стандартизированные процессы и сплоченность команды. Маршрутизация шлюза позволяет отделить запросы от внутренних серверных служб, что, в свою очередь, позволяет серверным службам поддерживать расширенные модели развертывания, переходы платформы и единую точку управления для разрешения доменных имен и шифрования при передаче.

- Инструменты и процессы OE:04
- Рекомендации по безопасному развертыванию OE:11
Эффективность производительности помогает рабочей нагрузке эффективно соответствовать требованиям путем оптимизации масштабирования, данных, кода. Маршрутизация шлюза позволяет распределять трафик между узлами в системе для балансировки нагрузки.

- Pe:05 Масштабирование и секционирование

Как и любое решение по проектированию, рассмотрите любые компромиссы по целям других столпов, которые могут быть представлены с этим шаблоном.

Пример

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

server {
    listen 80;
    server_name domain.com;

    location /app1 {
        proxy_pass http://10.0.3.10:80;
    }

    location /app2 {
        proxy_pass http://10.0.3.20:80;
    }

    location /app3 {
        proxy_pass http://10.0.3.30:80;
    }
}

Для реализации шаблона маршрутизации шлюза можно использовать следующие службы Azure: