В современных IT-продуктах микросервисная архитектура уже давно норма, и одну из центральных ролей в таком подходе занимает API Gateway.

В этой статье разберём, что такое API Gateway, зачем он нужен в микросервисной архитектуре, какие 10 ключевых функций он выполняет и в каких местах становится потенциальной точкой отказа.

Внутри вы найдёте много картинок и примеров схем архитектуры, чтобы объяснения были максимально понятными.

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

Цель простая: дать вам уверенные знания, чтобы уверенно читать архитектурные схемы, задавать правильные вопросы на проектах и верно закладывать в требования и тесты всё, что завязано на API Gateway.

Оглавление:
Что такое API Gateway:
- Как работает API Gateway
- Когда используют API Gateway
- Самописные решения и коробочные API Gateway
10 главных функций API Gateway
Виды API Gateway
API Gateway - центральная точка отказа
Примеры схем архитектуры с API Gateway в нотации C4 (и не только)
Заключение и полезные ссылки

Что такое API Gateway

API Gateway — это сервис, который выступает единой точкой входа для всех клиентских API-запросов к набору Backend-сервисов в микросервисной архитектуре.

Это такой же микросервис, как и все остальные в системе, только со своей особенной технической функциональностью по перенаправлению запросов.

Он работает как прокси-сервер:
+ принимает запрос от клиента,
+ решает, в какой сервис его отправить,
+ может собрать ответ из нескольких сервисов и вернуть итоговый результат.

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

Как работает API Gateway

Разберём алгоритм на примере работы маркетплейса:

1. Пользователь, через iOS Покупателя, запрашивает список товаров методом
   POST https://api.marketplacega.com/catalog-service/v1/products
   (используем POST, потому что в запросе много фильтров, подобный пример тут).

2. Запрос принимает API Gateway на стороне Backend.

3. API Gateway выполняет проверки безопасности:
   a. аутентификация запроса — в данном кейсе авторизация не требуется, поэтому проверка пропускается;
   b. rate limiting — проверяется количество запросов в минуту с одного IP-адреса. Если лимит превышен, на iOS Покупателя возвращается ошибка HTTP 429 Too Many Requests, иначе запрос идёт дальше.

4. API Gateway определяет, в какой микросервис отправить запрос.
   По части URL catalog-service (имя сервиса в маршруте), API Gateway, согласно своим настройкам, понимает, что запрос нужно проксировать в Микросервис Товаров.

5. API Gateway трансформирует запрос из формата REST API в gRPC, так как внутренний микросервис товаров работает на gRPC, а на API Gateway настроен приём REST API.

6. Микросервис Товаров принимает запрос в обработку, обращается к своей БД и собирает список товаров в формате protobuf.

7. Микросервис Товаров возвращает результат на API Gateway в формате protobuf.

8. API Gateway трансформирует ответ в формат REST API (JSON).

9. API Gateway возвращает ответ на iOS Покупателя.

10. iOS Покупателя показывает каталог товаров пользователю (этап подгрузки картинок для товаров далее).

Проследите описанную цепочку обработки запроса на схеме архитектуры ниже.

В данном алгоритме показали, как работают сразу 4 ключевые функции:

• маршрутизация запросов,

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

• ограничение частоты запросов (Rate Limiting)

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

Когда используют API Gateway

API Gateway имеет смысл внедрять, когда:

• Микросервисов много (хотя бы больше 5), и прямое обращение фронта к каждому из них ведёт к зоопарку вызовов разных API-сервисов и логики на стороне клиентов.

• Нужно единое место для повторяющихся проверок, одинаковых для всех микросервисов: аутентификация/авторизация, rate limiting, CORS и другие.

• Требуется агрегация данных: один запрос от клиента → несколько вызовов к разным микросервисам → единый ответ (классика для мобильных приложений и BFF-подхода в микросервисной архитектуре).

• Есть разные типы клиентов (веб, мобильные приложения, партнёрские интеграции), и API Gateway помогает скрыть внутреннюю архитектуру микросервисов от клиентов API.

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

Если у вас 2-5 микросервисов в системе, то API Gateway не нужен, так как может только усложнить архитектуру и создать лишние "тормоза" в обработке запросов.

Стоит держать в уме, что это дополнительный слой, чтобы достучаться до внутренних сервисов системы.

Самописные решения и коробочные API Gateway

Сервис API Gateway можно запрограммировать с нуля самостоятельно, как и любой другой сервис в системе.

Но в большинстве случаев лучше взять готовое решение "из коробки". Они есть как платные, так и бесплатные.

10 главных функций API Gateway

1️⃣ Первичная обработка запроса
Клиент (мобильное приложение, веб-приложение или внешняя система) отправляет запрос в API Gateway, а не напрямую к сервисам. Это даёт централизованную точку входа и упрощает интеграцию для клиентов.

2️⃣ Валидация запроса
API Gateway проверяет корректность запроса: метод, путь, обязательные параметры, формат данных. Если формат нарушен — запрос отклоняется с ошибкой.

3️⃣ Проверка безопасности
Проверка по спискам разрешённых (allow-list) и запрещённых (deny-list) источников. Подозрительные или явно небезопасные запросы блокируются.

4️⃣ Аутентификация и авторизация
Проверяются токены и другие учётные данные. API Gateway гарантирует, что у клиента есть права доступа к запрашиваемому ресурсу. При этом API Gateway может делать это как за счет встроенных механизмов, так и постоянно обращаясь к Сервису Аутентификации и Авторизации.

5️⃣ Ограничение частоты запросов (Rate Limiting)
Если клиент превышает допустимый лимит запросов, лишние запросы отклоняются с ответом 429 Too Many Requests.
Так защищают систему от перегрузки и простых атак.

6️⃣ Маршрутизация к нужному сервису
На основе пути, домена или других признаков, API-шлюз определяет, какому микросервису отправить запрос и по какому адресу.

7️⃣ Преобразование протоколов
При необходимости API Gateway преобразует запрос в нужный формат.
Например, снаружи от клиента запрос приходит как HTTP (REST API/JSON), а внутри передаётся в микросервис по gRPC/protobuf.

8️⃣ Агрегация ответов
Если ответ нужно собрать из нескольких микросервисов, API Gateway делает несколько внутренних вызовов и формирует единый ответ для клиента.

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

Собранный ответ приводится к нужному формату (чаще всего JSON, так как REST API - лучшее решение для взаимодействия клиентов и сервера, для интеграций) и возвращается клиенту с учётом настроек тайм-аутов.

9️⃣ Кэширование ответов
Для часто повторяющихся запросов API Gateway может вернуть данные из кэша, не обращаясь каждый раз к микросервису (например, список категорий товаров, список самих товаров с определенными фильтрами или справочники).
Это снижает нагрузку на Backend и ускоряет ответы для клиента.

? Логирование, мониторинг, обработка ошибок
На протяжении всего процесса обработки запроса API Gateway логирует входящие запросы и ответы, отправляет метрики в системы мониторинга и фиксирует ошибки. Это помогает отслеживать состояние системы, находить узкие места и быстрее разбирать инциденты.

Виды API Gateway

Есть два основных вида API Gateway, которые встраивают в проекты — External и Internal. Часто они используются вместе.

✔️ External API Gateway (внешний) - стоит «на границе» системы и:

• принимает запросы от мобильных приложений, веб-клиентов и внешних систем-партнёров;

• скрывает внутреннюю архитектуру Backend (микросервисы, их адреса и протоколы);

• отвечает за аутентификацию, авторизацию, rate limiting, базовую защиту от атак.

Это тот API Gateway, который видят клиенты и внешние системы.

✔️ Internal API Gateway (внутренний)
Используется внутри контура системы для организации взаимодействия между микросервисами:

• маршрутизирует запросы между сервисами;

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

Такой API Gateway не "торчит наружу", с ним работают только внутренние сервисы.

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

Пример:

• API Gateway External принимает запросы от iOS/Android/Web-клиентов и внешних партнёров. Через него идут «фронтовые» сценарии: авторизация, создание и просмотр заказов, получение каталога товаров.
  Для клиентов система выглядит как один единый Backend, хотя внутри работает несколько микросервисов.

• API Gateway Internal используется для внутренних взаимодействий между сервисами.
  Например, Микросервис Заказов может через Internal-шлюз:

  • обратиться в Микросервис Товаров, чтобы дотянуть актуальные данные о товарах для расчёта или записи в заказ;

  • вызвать Микросервис Уведомлений, чтобы отправить письмо, push или SMS по событию заказа;

  • передать данные в Микросервис Отчётов, чтобы сохранить показатели для аналитики.

• Микросервис Отчётов при этом доступен и снаружи, и изнутри:

  • через API Gateway External — когда клиент (или партнёр) напрямую запрашивает отчёт;

  • через API Gateway Internal — когда другие микросервисы (например, Заказы) пишут туда статистику.

Такое разделение позволяет одному шлюзу отвечать за «вход» в систему снаружи, а второму — за управляемое и единообразное взаимодействие между микросервисами внутри.

API Gateway - центральная точка отказа

API Gateway — центральная точка отказа в системе?

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

Ответ:
Да — если он не масштабирован горизонтально.

Если на сервере развернут единственный инстанс (установленная копия) API Gateway и он выйдет из строя, работа всех клиентов, которые в него обращаются, остановится.

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

Что будет, если API Gateway «упадёт»?

1. Внешние клиенты потеряют доступ к сервисам.

2. Внутренние вызовы (если они идут через Gateway) тоже могут быть нарушены.

3. В логах вы увидите HTTP 502 / 503 ошибки (Bad Gateway / Service Unavailable).

4. Мониторинг начнёт фиксировать обрыв соединения и рост ошибок. Это будет сложно не заметить ?

Как это решается?
Чтобы API Gateway не стал "узким горлышком", применяют следующие решения:

• Горизонтальное масштабирование
  Несколько инстансов API Gateway, развернутых за балансировщиком нагрузки. Тогда при сбое одного — остальные продолжают обслуживать запросы.

• Health-check и авто-рестарт
  Kubernetes и другие оркестраторы позволяют перезапускать поды/контейнеры при сбое.

• Failover-механизмы
  Некоторые решения "из коробки" поддерживают автоматическое переключение между инстансами при сбоях.

• Разделение входящего трафика
  В больших системах могут использовать несколько API Gateway по зонам или типам трафика (например, публичный API и внутренний API)

Несмотря на сбой API Gateway, внутренние сервисы продолжают жить, поэтому, если они не делают обратные вызовы в API Gateway для обращения в другие сервисы, то все начатые цепочки транзакций (запросов) будут выполнены.

Т.е. данные не теряются, процессы продолжаются.

API Gateway - потенциальная точка отказа в системе?
? Да

Но при нормальной инфраструктуре не должен быть ею.

Примеры схем архитектуры с API Gateway в нотации C4 (и не только)

Проект BookingGA - микросервисная архитектура проекта BookingGA с API Gateway, брокером, БД и ФХ.

Проект GreenChargeGA - микросервисная архитектура для системы зарядки электро-автомобилей.

Проект FarmFreshGA - микросервисная архитектура для системы доставки фермерских продуктов с API Gateway.

Проект RideFlow - микросервисная архитектура для системы заказа такси с API Gateway.

Заключение и полезные ссылки

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

Если вы понимаете, где именно выполняется аутентификация, что ограничивает трафик к серверу и как собираются логи и метрики в системе — вы гораздо увереннее себя чувствуете и в работе, и на собеседованиях.

Полезные ссылки:

• Оркестрация и API Gateway – разбор реального примера

• Нотация C4

• Гайд по API Gateway | Load Balancer | Reverse Proxy | Forward Proxy | Service Mesh

• Компоненты архитектуры: шпаргалка для системных аналитиков и архитекторов