Что такое API Gateway и как он работает в микросервисной архитектуре

Что проверяют

Понимаете ли вы, через что реально проходит запрос в микросервисной системе, и умеете ли этим пользоваться при тестировании. Тестировщику вопрос задают, чтобы услышать, как вы локализуете дефект: на шлюзе, в сети или в самом сервисе.

Как отвечать

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

Полезно разграничить: шлюз обслуживает трафик снаружи внутрь, а вызовы сервисов между собой это уже задача сервисной сетки или самих клиентов. Шлюз, заточенный под один тип клиента со своей агрегацией, называют BFF.

Что из этого важно на тестировании: один и тот же запрос надо уметь послать и через шлюз, и напрямую в сервис, тогда видно, чей ответ; проверять, что сервис не доверяет заголовкам, которые клиент может подделать; отдельно гонять лимиты и ожидаемый код при превышении; помнить, что таймаут шлюза короче таймаута сервиса даёт ошибку клиенту при живом сервисе; следить, что маршруты новой версии не перехватывают старые.

Где спотыкаются

Называют шлюз единой точкой отказа и на этом останавливаются. В проде их несколько за балансировщиком, а интересный ответ про другое: про деградацию, таймауты и про то, что при падении шлюза встаёт только внешний трафик.

Тестируют исключительно через шлюз. Тогда любая ошибка выглядит одинаково, а отчёт регулярно уходит не той команде.

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