Схема разгрузки шлюза

Перенесение общих или специализированных функций служб на прокси-сервер шлюза. Эта схема позволяет упростить разработку приложений, перемещая общие функции служб (например, использование SSL-сертификатов) из разных частей приложения в шлюз.

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

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

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

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

Решение

Выгрузите некоторые функции в шлюз, особенно перекрестные проблемы, такие как управление сертификатами, проверка подлинности, завершение SSL, мониторинг, перевод протокола или регулирование.

На следующей схеме показан шлюз, который завершает входящие SSL-подключения. Он запрашивает данные от имени исходного запрашивающего сервера от любого вышестоящего http-сервера шлюза.

Такая схема предоставляет следующие преимущества:

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

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

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

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

• Убедитесь, что шлюз имеет высокую доступность и устойчивость к сбоям. Избегайте отдельных точек сбоя, выполняя несколько экземпляров шлюза.
• Обеспечьте для шлюза достаточную емкость и возможность масштабирования в соответствии с потребностями приложений и конечных точек. Убедитесь, что шлюз не станет узким местом для приложения и его можно масштабировать до необходимого уровня.
• Переносите только те компоненты, которые используются во всех частях приложения, такие как функции обеспечения безопасности и (или) передачи данных.
• Бизнес-логика никогда не должна быть загружена в шлюз.
• Чтобы отслеживать транзакции, рекомендуем внедрить идентификаторы корреляции для ведения журнала.

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

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

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

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

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

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

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

Пример

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

upstream iis {
        server  10.3.0.10    max_fails=3    fail_timeout=15s;
        server  10.3.0.20    max_fails=3    fail_timeout=15s;
        server  10.3.0.30    max_fails=3    fail_timeout=15s;
}

server {
        listen 443;
        ssl on;
        ssl_certificate /etc/nginx/ssl/domain.cer;
        ssl_certificate_key /etc/nginx/ssl/domain.key;

        location / {
                set $targ iis;
                proxy_pass http://$targ;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header Host $host;
        }
}

В Azure это достигается путем настройки SSL-терминации в Шлюзе приложений.

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

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