API Gateway в микросервисной архитектуре

Что такое API Gateway?

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

Другими словами, Gateway:

• Cлужит единой точкой входа в распределенную систему;
• Перенаправляет запросы к нужным микросервисам;
• Выполняет сквозные (cross-cutting) задачи: логирование, авторизация и др;
• Упрощает клиентам взаимодействие с системой, скрывая ее внутреннюю структуру.

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

Ограничения прямого взаимодействия с микросервисами

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

Однако по мере роста системы и числа микросервисов такой подход становится все менее жизнеспособным:

• Клиенту приходится знать адреса и порты всех микросервисов, что нарушает принцип инкапсуляции и усиливает связанность компонентов.
• Задачи безопасности, логирования и аудита приходится реализовывать и поддерживать в каждом сервисе отдельно.
• Сложная маршрутизация по ролям, заголовкам и параметрам запроса требует дублируемой логики. Т.е. если необходимо направлять запросы в разные сервисы в зависимости от ролей пользователя, заголовков, параметров или версии API — такую динамическую маршрутизацию приходится реализовывать вручную в каждом сервисе, что ведет к дублированию логики и увеличивает технический долг.
• Каждый сервис должен самостоятельно решать задачи отказоустойчивости (timeouts, retries, circuit breakers).

Такой подход не масштабируется и становится источником технического долга. Поэтому в зрелой архитектуре вводится единая точка входа — API Gateway. На определенном этапе становится ясно: нам нужен единый вход в систему, или по-другому — Edge Server / API Gateway.

⚠️Термин Edge Server (дословно — “краевой сервер”) означает, что этот компонент располагается на границе системы, принимая внешний трафик и передавая его внутрь. Он отделяет внешний мир от внутренних сервисов и служит входной точкой в систему.

Какие задачи решает API Gateway

В микросервисной архитектуре существует набор задач, которые повторяются во всех сервисах и не относятся напрямую к бизнес-логике. Эти задачи называются сквозными (cross-cutting concerns). Их целесообразно централизовать — и именно этим занимается API Gateway.

Какие это задачи:

• Request Validation — проверка корректности входящих запросов до передачи в микросервис (например, структура, обязательные поля).
• Include & Exclude List — фильтрация доступа на основе списков разрешенных и запрещенных клиентов (IP, user-agent, tenant ID и т.п.).
• Authentication & Authorization — централизованная проверка токенов, ролей и прав доступа.
• Rate Limiting — ограничение частоты запросов от клиента для защиты от перегрузок и атак.
• Exception Handling — единообразная обработка ошибок и возврат понятных ответов клиенту.
• Circuit Breaker — механизм, который предотвращает избыточные попытки обращения к сбойному сервису. Если сервис не отвечает (например, возвращает ошибки или не укладывается в таймаут), Gateway временно разрывает цепочку вызовов и сразу возвращает предсказуемый ответ клиенту, не нагружая систему повторными обращениями. Это помогает защитить всю систему от перегрузки, особенно когда множество клиентов одновременно пытаются достучаться до недоступного сервиса.
• Logging / Monitoring — сбор логов и метрик о входящих запросах, интеграция с системами мониторинга.
• Caching — кэширование часто запрашиваемых данных на уровне Gateway для снижения нагрузки на микросервисы.

Кроме того, можно выделить ряд инфраструктурных задач:

• Service Discovery — автоматическое определение доступного экземпляра нужного микросервиса на основе регистрационной службы (например, Eureka). Вместо того чтобы жестко прописывать адреса сервисов, Gateway обращается к реестру, чтобы узнать, куда именно нужно отправить запрос — с учетом масштабирования, отказов и обновлений.
• Dynamic Routing — маршрутизация запросов в зависимости от заголовков, версий API, URI-шаблонов и других условий.
• Modify Request/Response — изменение заголовков или тела запроса/ответа. Это нужно, например, чтобы добавить технические заголовки (например, X-Request-ID), удалить лишние данные перед передачей клиенту или адаптировать формат между системами.
• Protocol Conversion — шлюз между несовместимыми протоколами. Например, когда клиент отправляет REST-запрос, а внутренний сервис работает по gRPC — Gateway берет на себя трансляцию между ними. Это позволяет согласовать работу разных компонентов без изменений в их коде.

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

Поэтому такие задачи выносятся в API Gateway, который выступает в роли Edge Server или Policy Enforcement Point (PEP) — посредника, который проверяет и применяет правила перед тем, как запрос попадет внутрь системы.

На практике в качестве API Gateway чаще всего используют Spring Cloud Gateway.

Spring Cloud Gateway

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

Spring Cloud Gateway выполняет роль центральной точки входа в систему. Все внешние запросы сначала проходят через него, где они могут быть проверены, модифицированы, логированы и перенаправлены во внутренние сервисы.

Ключевые особенности Spring Cloud Gateway:

• Основан на Spring WebFlux и Reactor, поддерживает неблокирующую реактивную модель.
• Интегрируется с Eureka, Resilience4j, Prometheus и другими компонентами Spring Cloud.
• Позволяет легко настраивать фильтры, маршруты и правила обработки запросов через application.yml или Java DSL.
• Поддерживает все задачи, описанные выше: маршрутизацию, безопасность, ограничение нагрузки, кеширование, логирование, трансформацию данных и многое другое.

Spring Cloud Gateway легко разворачивается как обычное Spring Boot-приложение.

Внутренне устройство Spring Cloud Gateway

Spring Cloud Gateway обрабатывает каждый входящий HTTP-запрос через четко структурированную цепочку, состоящую из нескольких этапов.

1. Определение маршрута (Routing)

Когда приходит HTTP-запрос, Gateway сначала проверяет, подходит ли он под один из заранее настроенных маршрутов. Это происходит через тн предикаты — условия, которые должны быть выполнены, чтобы маршрут сработал. Например:

• путь запроса начинается с /api/,
• в заголовке есть X-User-Role=admin,
• используется определенный HTTP-метод(POST и тд).

Если ни один маршрут не подходит, Gateway возвращает ошибку (404 Not Found или 403 Forbidden), в зависимости от конфигурации.

⚠️ Предикаты — это первый уровень фильтрации, еще до передачи запроса в цепочку фильтров.

2. Фильтры до передачи запроса (Pre-filters)

Когда маршрут найден, запрос передается через набор Pre-filters — фильтров, которые обрабатывают запрос до его отправки в целевой микросервис. Среди них могут быть:

• Логирование — запись информации о входящих запросах для мониторинга и аудита.
• Аутентификация и проверка токена — валидация JWT или другого механизма авторизации.
• Модификация заголовков — добавление технических заголовков (например, X-Request-ID для трейсинга) или удаление ненужных.
• Rate limiting — ограничение частоты запросов, чтобы защитить внутренние сервисы от перегрузки.
• Перенаправление или трансформация запроса — например, изменение пути или параметров до отправки.

Pre-filters позволяют централизовать сквозную логику и упростить реализацию в микросервисах.

3. Передача запроса в микросервис

После обработки всеми пред-фильтрами запрос отправляется в целевой микросервис, определенный на этапе маршрутизации. В это время Gateway выступает как reverse proxy — проксирует запрос, сохраняя подключение клиента.

4. Фильтры после получения ответа (Post-filters)

Когда микросервис возвращает ответ, Gateway запускает цепочку Post-filters, которые могут:

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

⚠️ Благодаря реактивной модели Spring WebFlux, Gateway обрабатывает запросы неблокирующим образом, что повышает его производительность и масштабируемость — особенно при большом числе одновременных соединений.

Шаблоны использования API Gateway

API Gateway реализует несколько архитектурных паттернов в зависимости от задач системы. Рассмотрим основные из них.

API Gateway Pattern

Что это: Базовый шаблон, в котором Gateway служит единой точкой входа для всех клиентов (web, mobile, API) и маршрутизирует запросы к соответствующим микросервисам.

Когда применять:

• Нужно скрыть внутреннюю структуру системы от клиентов.
• Требуется централизованное управление кросс-сервисными задачами: безопасность, логирование, аудит.
• Клиенты не должны знать адреса отдельных сервисов.

Gateway Routing Pattern

Что это: Расширение базового паттерна, когда Gateway выполняет динамическую маршрутизацию запросов к разным микросервисам на основе:

• URL-пути (например, /api/profiles/**),
• заголовков запроса,
• параметров запроса (например, версия API).

Когда применять:

• Есть разные версии API, и необходимо маршрутизировать запросы без изменения клиента.
• Требуется отправлять запросы разных типов на разные микросервисы.

Gateway Offloading Pattern

Что это: Паттерн, при котором Gateway берет на себя сквозные задачи (cross-cutting concerns), разгружая микросервисы. Например:

• Аутентификация и авторизация.
• Rate limiting (ограничение запросов).
• Load balancing (балансировка нагрузки).
• SSL termination (завершение TLS). -Кеширование и мониторинг.

Когда применять:

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

Backend for Frontend (BFF) Pattern

Что это: В этом шаблоне создается отдельный Gateway для каждого типа клиента (web, mobile, tablet). Каждый такой gateway адаптирует API под нужды своего клиента.

Когда применять:

• Требуется разное представление данных или состав API для web и mobile.
• Нужно минимизировать трафик для мобильных клиентов (например, отдавать сокращенные DTO).
• Есть разные команды разработки фронтендов, которым удобнее работать с отдельными Gateway.

Gateway Aggregator / Composition Pattern

Что это: Gateway агрегирует данные от нескольких микросервисов в единый ответ. Например, при запросе профиля пользователя нужно получить данные из:

• сервиса пользователей (основная информация),
• сервиса заказов (последние покупки),
• сервиса уведомлений.

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

Когда применять:

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

Статьи серии

• Микросервисы: серия материалов о принципах, паттернах и практике
• Эволюция архитектур: от монолита к микросервисам
• Микросервисная архитектура
• Нужен ли Service Discovery в Docker-среде?
• Изоляция данных и Feign: архитектура без сквозных связей
• Вызов других микросервисов с помощью Feign
• Как работает Service Discovery в Spring Cloud и зачем он нужен
• (в разработке)