Всем привет! Недавно в общих чертах писала про API Gateway.
Решила чуть подробнее раскрыть эту тему. API Gateway бывают разные, давайте разберем основные паттерны.

1. Шлюз-агрегатор (Gateway Aggregation)
Сценарий: клиенту нужны данные сразу из нескольких микросервисов, но вместо множества HTTP-запросов он делает один запрос к API Gateway, который агрегирует данные.
API Gateway отправляет запросы к нескольким микросервисам.
Собирает их ответы и возвращает клиенту единый объект.
Может использовать GraphQL для запроса только нужных данных.
Плюсы:
Меньше зависимостей для фронта.
Уменьшает число запросов.
Повышает скорость ответа клиенту.
Минусы:
Спецификация API-GW становится достаточно сложной, в том числе для поддержки и развития.

2. Шлюз-прокси (Gateway Routing / Reverse Proxy)
Сценарий: API Gateway просто маршрутизирует запросы на нужный микросервис, не изменяя их.
Клиент делает запрос на метод к общему URI, например: GET: https://ecom.shop/orders
API-GW перенаправляет его на необходимый сервис: https://order-service/orders.
Клиент не знает какой сервис выполнил его запрос.
Плюсы:
Простота реализации.
Клиент остается независимым от внутренних URL.
Можно легко менять маршруты без обновления клиентов.
Минусы:
Количество запросов не снижается.

3. API Gateway с адаптацией (Gateway Offloading)
Сценарий: API Gateway берет на себя кросс-сервисные функции (аутентификация, кэширование, rate limiting, CORS).
API Gateway проверяет JWT-токены, API-ключи, аутентифицирует запросы.
Реализует кэширование ответов, чтобы разгрузить сервисы.
Ограничивает количество запросов (rate limiting), защищая систему от DDoS.
Добавляет CORS-заголовки для браузеров.
Плюсы:
Централизованное управление стандартами безопасности. Единые стандарты заголовков, маркеров сессий или транзакций, управление безопасностью, выполняется API-GW.
Разгружает микросервисы, за счет вынесение вышеописанного функционала в отдельный компонент(API-GW).
Улучшает производительность.
Минусы:
Сложность API Gateway увеличивается.
Данный вариант часто применяется для высоконагруженных систем.

Давайте вернемся к часто используемому NGINX.
NGINX может выполнять следующие функции:
— маршрутизировать запросы к нужным сервисам;
— работать как балансировщик нагрузки (Load Balancer) и распределять запросы между несколькими экземплярами одного сервиса;
— выполнять TLS termination;
— ограничивать количество запросов;
— кэшировать ответы;
— добавлять и изменять HTTP-заголовки;
— раздавать статический контент — например, HTML, CSS, JavaScript, изображения;
— реализовывать различные схемы распределения трафика.
Давайте про балансировку поговорим в следующем посте.
А сейчас обсудим про - canary release (канарейку).

Допустим, мы выпустили новую версию сервиса:
order-service v1 — текущая версия
order-service v2 — новая версия.
С помощью NGINX можно настроить распределение трафика, например:
95% →на  v1
5% → на v2
Так небольшая доля пользователей сначала работает с новой версией. Если всё хорошо — постепенно увеличиваем процент трафика на v2.

NGINX — это технология, которая может выполнять функции reverse proxy, web-сервера и балансировщика и закрывать часть задач API Gateway.Используется для простой маршрутизации без дополнительных инструментов, таких как сложная аутентификация и service-mesh. Позволяют также реализовать простые паттерны кэширования.

Предлагаю в следуюшем посте обсудить балансировщиков нагрузки, горизонтальное масштабирование, ставь орла🦅 если нужен следуюший пост.

Полезно- ❤️