Вопрос или проблема
У меня есть установка, в которой находятся два веб-приложения и несколько микросервисов. Веб-приложения имеют интерфейс Angular в браузере и обращаются к сервлетам/JSP для получения содержимого на стороне сервера. Сегодня у меня есть веб-сервер Apache, который размещает статический контент – JavaScript, изображения, CSS и выполняет обратное проксирование с веб-приложениями.
Я хочу ввести API-шлюз и предоставить дополнительные микросервисы, которые могут быть использованы этими веб-приложениями, а также пользователями b2b.
Теперь, какова лучшая практика для настройки API-шлюза?
- Должен ли API-шлюз быть основной точкой входа, которая затем маршрутизирует запросы к веб-приложениям или микросервисам? Если да, то где должен размещаться статический контент?
ИЛИ - Должны ли веб-приложения продолжать работать с Apache, а API-шлюз находиться на другом (под) домене, к которому могут получить доступ эти веб-приложения или b2b?
На начальном этапе я настроил API-шлюз как основную точку входа, а веб-приложение по-прежнему имеет сервер Apache. Я предполагаю, что это излишне для статического контента, и не уверен, какая практика является наилучшей.
Ответ или решение
Использование API-шлюза для веб-приложения
При интеграции API-шлюза в существующую архитектуру, состоящую из веб-приложений и микросервисов, важно учитывать несколько ключевых аспектов, чтобы достичь оптимальной работы и масштабируемости системы. Основные вопросы, которые требуют рассмотрения, касаются той роли, которую будет играть API-шлюз, и способа размещения статического контента.
1. Основная точка входа
Ваша идея о том, чтобы использовать API-шлюз в качестве основной точки входа, является общей практикой и предоставляет множество преимуществ:
-
Централизованная маршрутизация запросов: API-шлюз может направлять запросы от клиентов (веб-приложений и пользователей B2B) к соответствующим микросервисам или веб-приложениям. Это упрощает управление и безопасность, так как все запросы проходят через единый контрольный узел.
-
Упрощение клиентской архитектуры: Клиенты не должны знать, какова структура микросервисов. Для них API-шлюз предоставляет единый интерфейс доступа к различным сервисам.
-
Управление кэшированием и лимитами: API-шлюз может реализовать механизмы кэширования для уменьшения нагрузки на серверы и обеспечить ограничения по доступу к API.
Однако, если API-шлюз становится единственной точкой входа, важно подумать о том, как будет управляться статический контент, такой как JavaScript, CSS, изображения и так далее. Традиционно для этого используется веб-сервер (например, Apache), который может надежно обслуживать статические файлы.
2. Хостинг статического контента
При использовании API-шлюза в качестве основной точки входа, вы можете рассмотреть следующие варианты для размещения статического контента:
-
На том же сервере, где расположен API-шлюз: Если ваш API-шлюз поддерживает хостинг статического контента (например, Nginx или некоторые облачные решения), это может упростить архитектуру и улучшить производительность за счет уменьшения латентности. Однако такой подход требует дополнительных ресурсов и правильной настройки для обеспечения безопасности.
-
Отдельный веб-сервер (например, Apache): Один из наиболее популярных путей – это оставить веб-сервер (Apache) для обслуживания статического контента. В этом случае API-шлюз будет направлять запросы к веб-приложениям или микросервисам, а все статические файлы продолжат обслуживаться через ваш существующий сервер.
3. Совместное использование
Если ваша архитектура допускает использование API-шлюза и веб-сервера как двух отдельных сущностей, вы можете организовать следующую структуру:
-
Основной поддомен для API-шлюза: Используйте поддомен для API (например,
api.yourdomain.com), в то время как основное веб-приложение может оставаться на основном домене или другом поддомене (www.yourdomain.com). Это позволяет безболезненно разделить обработку динамических и статических запросов. -
Настройка кросс-доменных запросов (CORS): Убедитесь, что ваши веб-приложения могут делать запросы к API через разные домены, настроив необходимые заголовки CORS. Это улучшит взаимодействие между вашим API-шлюзом и клиентскими приложениями.
4. Рекомендуемая архитектура
Опираясь на вышеизложенные аспекты, рекомендуется следующее:
- Поддержка API-шлюза в качестве основной точки входа.
- Хостинг статического контента на отдельном веб-сервере.
- Разделение доменов для API и веб-приложений.
Таким образом, управление станет более простым и безопасным, а работа с микросервисами будет оптимизирована. Это позволит как веб-приложениям, так и B2B-пользователям просто взаимодействовать с вашими добровольными API.
С концепцией API-шлюза вы не только упростите архитектуру вашего приложения, но и подготовите почву для дальнейшего масштабирования и интеграции новых микросервисов.