API-шлюз: единая точка входа для многих сервисов

Коротко: Посредник, принимающий все запросы извне и пересылающий их соответствующим внутренним сервисам.

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

Подробности

Задачи

• Маршрутизация (routing): /orders идёт в сервис заказов, /users — в сервис пользователей.
• Аутентификация и авторизация: проверка токенов до того, как что-либо дойдёт до сервисов.
• Ограничение частоты запросов и защита от злоупотреблений.
• Терминирование TLS: шифрование на входе, внутри проще.
• Объединение нескольких ответов в один (агрегация) и преобразование форматов.
• Журналирование, метрики, кэширование.

Пример правила маршрутизации

В нотации, похожей на nginx:

location /api/orders/ { proxy_pass http://orderservice:8080/; }
location /api/users/  { proxy_pass http://userservice:8080/; }

На практике используют такие продукты, как Kong, Traefik, AWS API Gateway или Azure API Management.

Backend for frontend (BFF)

Вариант — отдельный шлюз на каждый тип приложения, например один для мобильного приложения и один для веб-интерфейса. Каждый отдаёт ровно те данные, которые нужны его клиенту, и избавляет от множества отдельных вызовов.

Недостатки

Шлюз — центральная точка: если он выйдет из строя, пропадёт всё, и он может стать узким местом. Поэтому его нужно эксплуатировать с резервированием и высокой доступностью. Он также не должен накапливать слишком много бизнес-логики, иначе возникнет новый монолит. Чистый трафик между сервисами обычно идёт не через него, а через сервисную сетку (service mesh).

См. также: Микросервисы, nginx и обратный прокси, Ограничение частоты запросов, Балансировщик нагрузки