Открыть сервис
Главная → Блог → API Gateway

API Gateway

API Gateway — это серверный компонент, выступающий единой точкой входа для клиентских запросов к микросервисной архитектуре. Он выполняет функции маршрутизации, аутентификации, агрегации данных, ограничения нагрузки и преобразования протоколов, скрывая внутреннюю структуру бэкенда от внешних клиентов.

Назначение и роль

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

  • Сложность клиента: клиентское приложение должно знать адреса всех сервисов и обрабатывать логику их взаимодействия.
  • Повышенная сетевая нагрузка: для получения данных из нескольких сервисов клиент выполняет множество HTTP-запросов.
  • Проблемы безопасности: каждый сервис вынужден самостоятельно реализовывать аутентификацию и авторизацию, что увеличивает поверхность атаки.
  • Сложность протоколов: сервисы могут использовать разные протоколы (HTTP, gRPC, WebSocket, AMQP), что требует от клиента поддержки всех этих протоколов.

API Gateway решает эти проблемы, предоставляя единый интерфейс для внешних клиентов. Он принимает запрос, маршрутизирует его к нужному сервису, агрегирует ответы, преобразует протоколы и возвращает клиенту единый ответ.

Основные функции

Маршрутизация

API Gateway перенаправляет входящие запросы к соответствующим микросервисам на основе URL, HTTP-метода, заголовков или других параметров. Например, запрос GET /api/users/123 может быть направлен к сервису пользователей, а POST /api/orders — к сервису заказов.

Аутентификация и авторизация

Gateway проверяет подлинность клиента (например, с помощью JWT-токенов, OAuth 2.0, API-ключей) и проверяет права доступа к запрашиваемому ресурсу. Это позволяет централизованно управлять безопасностью, не дублируя логику в каждом сервисе.

Агрегация данных

Часто клиенту требуются данные из нескольких сервисов. API Gateway может выполнить несколько запросов к разным сервисам, объединить результаты и вернуть единый ответ. Например, для страницы профиля пользователя может потребоваться информация из сервиса пользователей, сервиса заказов и сервиса уведомлений.

Ограничение нагрузки (Rate Limiting)

Gateway контролирует количество запросов от одного клиента за определённый промежуток времени. Это предотвращает перегрузку бэкенда и защищает от DDoS-атак.

Преобразование протоколов

API Gateway может преобразовывать запросы из одного протокола в другой. Например, внешний клиент использует HTTP/1.1, а внутренний сервис — gRPC. Gateway преобразует HTTP-запрос в gRPC-вызов и обратно.

Логирование и мониторинг

Gateway собирает метрики (время ответа, количество запросов, ошибки) и логирует все входящие запросы. Это упрощает отладку и мониторинг работы всей системы.

Кэширование

Для часто запрашиваемых данных (например, список стран, справочные данные) API Gateway может кэшировать ответы, снижая нагрузку на бэкенд и ускоряя ответ клиенту.

Архитектура и принципы работы

API Gateway располагается на границе сети, между клиентами (веб-браузеры, мобильные приложения, сторонние сервисы) и внутренними микросервисами. Он обычно реализуется как отдельный сервис, развёрнутый на выделенных серверах или в контейнерах.

Типичный жизненный цикл запроса через API Gateway:

  1. Клиент отправляет HTTP-запрос на известный URL (например, https://api.example.com/orders`).
  2. Gateway принимает запрос и проверяет аутентификацию (например, валидирует JWT-токен).
  3. Gateway проверяет авторизацию (например, имеет ли пользователь право на создание заказа).
  4. Gateway применяет правила ограничения нагрузки (Rate Limiting).
  5. Gateway маршрутизирует запрос к соответствующему микросервису (например, http://order-service:8080/orders`).
  6. Микросервис обрабатывает запрос и возвращает ответ.
  7. Gateway может преобразовать ответ (например, добавить заголовки, изменить формат) и вернуть его клиенту.

Классификация

По типу развёртывания

  • Встроенный (Embedded): Gateway реализован как библиотека, встраиваемая в приложение. Примеры: Zuul (Netflix) — устаревший, Spring Cloud Gateway.
  • Отдельный сервис (Standalone): Gateway развёрнут как самостоятельный сервер. Примеры: Kong, Traefik, NGINX Plus, Amazon API Gateway, Yandex API Gateway (сервис компании «Яндекс», зарегистрированной в РФ).

По протоколу

  • HTTP/HTTPS: наиболее распространённый тип, работающий с REST API.
  • gRPC: поддерживает gRPC-вызовы, часто используется в высоконагруженных системах.
  • WebSocket: поддерживает долгоживущие соединения для реального времени.
  • MQTT: для IoT-устройств.

По функциональности

  • Простые (Basic): только маршрутизация и аутентификация.
  • Расширенные (Advanced): включают агрегацию, кэширование, преобразование протоколов, мониторинг.

Примеры популярных реализаций

Kong

Открытое решение, основанное на NGINX. Поддерживает плагины для аутентификации, Rate Limiting, логирования, мониторинга. Распространяется под лицензией Apache 2.0.

Traefik

Современный обратный прокси, интегрированный с Docker, Kubernetes, Consul. Автоматически обнаруживает сервисы и обновляет конфигурацию.

NGINX Plus

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

Amazon API Gateway

Управляемый сервис от Amazon Web Services (AWS). Поддерживает REST и WebSocket API, интеграцию с Lambda, Cognito, CloudWatch.

Yandex API Gateway

Сервис от компании «Яндекс» (зарегистрирована в РФ), предоставляемый в облачной платформе Yandex Cloud. Позволяет создавать, развёртывать и управлять API-шлюзами без управления серверной инфраструктурой.

Spring Cloud Gateway

Решение на основе Spring Framework, популярное в экосистеме Java. Поддерживает маршрутизацию, фильтры, интеграцию с Spring Security.

Преимущества и недостатки

Преимущества

  • Централизованное управление: безопасность, мониторинг, ограничение нагрузки — всё в одном месте.
  • Упрощение клиента: клиент взаимодействует только с одним адресом, не зная внутренней архитектуры.
  • Гибкость: можно менять внутреннюю структуру (добавлять/удалять сервисы) без изменения клиента.
  • Повышение безопасности: внешний трафик проходит через единую точку, где можно применять фильтры и проверки.

Недостатки

  • Единая точка отказа: при выходе из строя Gateway вся система становится недоступной. Требуется резервирование и высокая доступность.
  • Увеличение задержки: каждый запрос проходит дополнительный слой обработки, что добавляет задержку (обычно 1–5 мс).
  • Сложность разработки: реализация Gateway требует тщательного проектирования, особенно при агрегации данных и преобразовании протоколов.
  • Потенциальное узкое место: при большом количестве запросов Gateway может стать узким местом, требуя масштабирования.

Критика и альтернативы

Некоторые архитекторы считают, что API Gateway нарушает принцип единой ответственности, объединяя слишком много функций. В распределённых системах с высокой нагрузкой Gateway может стать узким местом. Альтернативой является использование Service Mesh (например, Istio, Linkerd), где функции маршрутизации и безопасности выносятся на уровень sidecar-прокси, работающих рядом с каждым микросервисом. Это позволяет избежать единой точки отказа, но усложняет инфраструктуру.

Другой альтернативой является Backend for Frontend (BFF) — подход, при котором для каждого типа клиента (веб, мобильное приложение, IoT) создаётся свой Gateway, оптимизированный под его потребности. Это уменьшает нагрузку на один Gateway и упрощает агрегацию данных.

Применение в России

В России API Gateway активно используется в крупных интернет-компаниях (например, «Яндекс», «Сбер», «Т-Банк» (ранее «Тинькофф»), «ВКонтакте»), а также в государственных информационных системах (например, портал «Госуслуги»). Российские облачные провайдеры, такие как Yandex Cloud, VK Cloud, Selectel, предоставляют собственные реализации API Gateway как управляемые сервисы.

Источники

  • Newman, Sam. Building Microservices: Designing Fine-Grained Systems. O'Reilly Media, 2015.
  • Richardson, Chris. Microservices Patterns: With examples in Java. Manning Publications, 2018.
  • Документация Kong (Kong Inc.).
  • Документация Traefik (Traefik Labs).
  • Документация Spring Cloud Gateway (VMware).
  • Документация Yandex API Gateway (Yandex Cloud).
  • «API Gateway: что это, зачем нужно и как работает» — Хабр, 2020.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы