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

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

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

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

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

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

Решение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

Ниже приведен простой пример файла конфигурации для сервера, на котором 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:

• Экземпляр Шлюз приложений, обеспечивающий маршрутизацию регионального уровня 7.
• Экземпляр Azure Front Door, который обеспечивает глобальную маршрутизацию уровня 7.

Связанные ресурсы

• Схема отдельных серверных частей для каждого интерфейса
• Схема агрегирования на шлюзе
• Схема разгрузки шлюза