Помните непреодолимый пост охраны в общаге, на предприятии, где-нибудь еще? Суровый мужичок или не менее опасная бабуля сидят за столом или у стойки, проверяют у всех пропуска, идентифицируют личность как терминатор – и решают, пропустить вас или нет 🤷
Если не идентифицировали – то не пропускают. Если узнали – то подскажут, куда идти
🤍Что такое API Gateway
В мире IT подобный пост охраны называется API Gateway (шлюз) – единая точка входа, через которую клиенты (мобильное или веб-приложение) общаются с бэкендом
API Gateway это паттерн микросервисной архитектуры, поэтому этот компонент бэкенда вы увидите там
🤍 Основные функции
У API Gateway куда больше полезных функций, чем просто проверка и маршрутизция запроса:
🤍 Единая точка входа – клиенту не нужно знать адреса десятка серверов
🤍 Маршрутизация – шлюз сам решает, к какому сервису направить запрос
🤍 Аутентификация и авторизация – может выступать вместо или перенимать функции сервиса авторизации
🤍 Управление трафиком – можно поставить ограничение для одного клиента (например, не более 1000 в минуту)
🤍 Кэширование – может кэшировать ответ в своей памяти и отдавать данные, не обращаясь к сервису
🤍 Мониторинг и логирование – шлюз формирует журналы запросов, что поможет при отладке и анализе работы
🤍 Агрегация данных – шлюз собирает ответы из нескольких микросервисов
🤍Пример работы
Есть запрос:
GET https://api.my-shop.com/my/orders – получение списка заказов
где https://api.my-shop.com – адрес нашего API Gateway
Порядок работы:
1 – От клиента запрос поступает на шлюз
2 – Шлюз проверяет авторизацию (JWT-токен) на валидность и получает ID пользователя
3 – Шлюз видит URL /my/orders и понимает, что это для сервиса заказов
4 – Шлюз отправляет внутренний запрос в Сервис заказа (GET /internal/orders?user_id=12345)
5 – Шлюз получает ответ
6 – Шлюз отправляет ответ клиенту
Если нужно агрегировать данные – то между 4 и 5 шагами будет отправка других запросов и агрегация данных
🤍Мой опыт
На проектах, где были микросервисы, всегда был API Gateway. Где-то был задействован полнее (с функциями авторизации и управления трафика), где-то это был просто маршрутизатор
И на этих проектах, как СА, я просто знал, что API Gateway есть и выполняет определенные функции. Максимум моей работы – отобразить компонент на схеме архитектуры и описать возможности 🐸
Знаю при этом, что в крупных проектах, где несколько API Gateway, над каждым работает целая команда – и там, я думаю, СА вовлечен более детально. Если у вас есть такой опыт, пишите в комментах
—————
В итоге API Gateway – важный компонент микросервисной архитектуры, который принимает все запросы, проверяет их и отправляет нужным сервисам, а результат возвращает клиенту. Он разгружает внутренние сервисы и клиента, делая их независимыми, но при этом является единой точкой отказа
➡ Забирай себе, пригодится в работе с микросервисами или на собесах
#полезное_системный_анализ