❤️API Gateway — зачем ставить ещё один сервис перед микросервисами? Представим обычное приложение доставки еды. У нас есть несколько микросервисов: User Service — пользователи; Restaurant Service — рестораны; Order Service — заказы; Payment Service — оплаты; Delivery Service — доставка. Мобильному приложению нужно получить информацию о заказе. Теоретически оно может обратиться напрямую: GET order-service/api/v1/orders/123 Для пользователя: GET user-service/api/v1/users/42 Для доставки: GET delivery-service/api/v1/deliveries/777 И на первый взгляд всё нормально. Но теперь клиенту приходится знать: какие сервисы существуют; где они находятся; какие у них адреса; какие версии API используются; как авторизоваться в каждом сервисе; что делать, если сервис переехал; куда отправлять запрос после появления новой версии API. Получается довольно сильная связь: Frontend | ├── User Service ├── Order Service ├── Payment Service ├── Restaurant Service └── Delivery Service Frontend фактически начинает знать внутреннюю структуру backend-системы. И вот здесь появляется API Gateway. Что такое API Gateway? API Gateway — это единая точка входа для запросов клиентов в backend-систему. Теперь клиент обращается не напрямую к микросервисам: Frontend → API Gateway → Microservices Например: GET /api/v1/orders/123 Запрос приходит в Gateway. Gateway понимает: /api/v1/orders/** ↓ Order Service и перенаправляет запрос туда. Для клиента при этом вообще неважно, где физически находится Order Service. Например: Client | v api.company.ru | v API Gateway | +------> User Service | +------> Order Service | +------> Payment Service | +------> Delivery Service То есть Gateway скрывает внутреннюю структуру системы. Аналогия Представьте большой бизнес-центр. Внутри него работают десятки компаний. Без ресепшена посетителю пришлось бы самому знать: бухгалтерия → этаж 4 → кабинет 412
юристы → этаж 7 → кабинет 703
IT → этаж 10 → кабинет 1012 Но есть ресепшен. Вы говорите: Мне нужна бухгалтерия. А сотрудник ресепшена уже понимает, куда вас направить. API Gateway — примерно такой же ресепшен для API. Клиент знает только: api.company.ru А дальше Gateway решает, как обработать запрос. Но маршрутизация — только начало API Gateway обычно может решать и другие задачи: проверять авторизацию; проверять JWT; ограничивать количество запросов; маршрутизировать запросы; вести логи; собирать метрики; работать с версиями API; добавлять или изменять HTTP-заголовки; иногда агрегировать ответы нескольких сервисов. Например: Client | | GET /api/orders/123 | Authorization: Bearer JWT v API Gateway | | 1. Проверяет токен | 2. Проверяет лимиты | 3. Определяет маршрут v Order Service Поэтому Gateway — это не просто «прокси, который перекидывает запрос». Это отдельный инфраструктурный компонент, который контролирует входящий трафик в систему. Важная мысль для системного аналитика Когда на архитектурной схеме вы видите: Frontend → API Gateway → Backend нужно сразу задавать вопросы: Какие маршруты есть в Gateway? Где выполняется аутентификация? Где выполняется авторизация? Проверяет ли Gateway JWT? Есть ли rate limiting? Какие timeout установлены? Есть ли retry? Как Gateway находит нужный экземпляр сервиса? Кто отвечает за версионирование API? Какие заголовки Gateway передаёт дальше? Потому что API Gateway часто находится прямо на границе между внешним клиентом и внутренней архитектурой системы. В следующей части разберём самое интересное: что конкретно делает API Gateway с запросом — routing, authentication, rate limiting, headers, timeout и другие механизмы.
