Что такое API Gateway и зачем он нужен в микросервисной архитектуре?
Если в системе много микросервисов, клиенту не очень удобно напрямую взаимодействовать с каждым из них.
Например, мобильному приложению нужно получить информацию для совершения платежа C2B (client to business — платеж от физического лица к юридическому). Клиентская часть не должна знать, где находится сервис C2B, как устроен полностью бэкенд и какие ещё сервисы участвуют в обработке запроса.
Между клиентом и бэкендом можно поставить API Gateway. Тогда клиент отправляет Post /CreatePaymentC2B → API Gateway определяет маршрут → запрос уходит в C2B сервис. В этом случае основная задача API Gateway — маршрутизация. API Gateway выступает единой точкой входа для внешних клиентов и направляет запросы в нужные бэкенд-сервисы. API Gateway может быть самописным или купленным готовым решением у какого-то вендора. Если функционал несложный, то можно реализовать его своими силами или переиспользовать уже имеющийся API Gateway, главное — согласовать реализацию с архитекторами.
Какие ещё функции может выполнять API Gateway?
Аутентификация. Например, Gateway может проверить JWT: подпись, срок действия и другие параметры токена. При этом токен может передаваться дальше в сервисы, если им необходимо самостоятельно определить права пользователя.
Rate limiting. Gateway может ограничивать количество запросов. Например, для конкретного клиента разрешено не больше 100 запросов в секунду. Если лимит превышен, новые запросы Gateway не пропускает дальше. Для хранения информации о лимитах может использоваться как собственная память Gateway, так и внешнее хранилище, например Redis.
TLS терминирование. API Gateway может расшифровать HTTPS и дальше прокинуть запрос в незашифрованном виде, если внутренняя сеть уже защищена.
Первичная валидация. На входе можно проверить формат запроса, обязательные заголовки, размер payload и другие технические параметры.
Кэширование. Для некоторых запросов Gateway может вернуть ответ из кэша, не обращаясь каждый раз к бэкенду.
Важный момент: не надо пихать бизнес-логику в API Gateway. Иногда так делают, но ни к чему хорошему это обычно не приводит.
Очень часто Nginx выполняет функции API Gateway. Есть ещё такие решения, как Istio Ingress Gateway, Traefik, Kong, Tyk, Spring Cloud Gateway.
На практике API Gateway может стоять перед взаимодействием с ЕСИА (государственные услуги), ЕБС (единая биометрическая система), СМЭВ (система межведомственного взаимодействия), ТРИБ (типовое решение информационной безопасности), НСПК (национальная система платежных карт). Иногда по требованию информационной безопасности нужно аттестовать API Gateway; это дополнительное время при реализации, которое стоит закладывать в дорожную карту.
Работали с API Gateway?
Да - 👍
Нет - 🙈
Полезно - 🦅
Если в системе много микросервисов, клиенту не очень удобно напрямую взаимодействовать с каждым из них.
Например, мобильному приложению нужно получить информацию для совершения платежа C2B (client to business — платеж от физического лица к юридическому). Клиентская часть не должна знать, где находится сервис C2B, как устроен полностью бэкенд и какие ещё сервисы участвуют в обработке запроса.
Между клиентом и бэкендом можно поставить API Gateway. Тогда клиент отправляет Post /CreatePaymentC2B → API Gateway определяет маршрут → запрос уходит в C2B сервис. В этом случае основная задача API Gateway — маршрутизация. API Gateway выступает единой точкой входа для внешних клиентов и направляет запросы в нужные бэкенд-сервисы. API Gateway может быть самописным или купленным готовым решением у какого-то вендора. Если функционал несложный, то можно реализовать его своими силами или переиспользовать уже имеющийся API Gateway, главное — согласовать реализацию с архитекторами.
Какие ещё функции может выполнять API Gateway?
Аутентификация. Например, Gateway может проверить JWT: подпись, срок действия и другие параметры токена. При этом токен может передаваться дальше в сервисы, если им необходимо самостоятельно определить права пользователя.
Rate limiting. Gateway может ограничивать количество запросов. Например, для конкретного клиента разрешено не больше 100 запросов в секунду. Если лимит превышен, новые запросы Gateway не пропускает дальше. Для хранения информации о лимитах может использоваться как собственная память Gateway, так и внешнее хранилище, например Redis.
TLS терминирование. API Gateway может расшифровать HTTPS и дальше прокинуть запрос в незашифрованном виде, если внутренняя сеть уже защищена.
Первичная валидация. На входе можно проверить формат запроса, обязательные заголовки, размер payload и другие технические параметры.
Кэширование. Для некоторых запросов Gateway может вернуть ответ из кэша, не обращаясь каждый раз к бэкенду.
Важный момент: не надо пихать бизнес-логику в API Gateway. Иногда так делают, но ни к чему хорошему это обычно не приводит.
Очень часто Nginx выполняет функции API Gateway. Есть ещё такие решения, как Istio Ingress Gateway, Traefik, Kong, Tyk, Spring Cloud Gateway.
На практике API Gateway может стоять перед взаимодействием с ЕСИА (государственные услуги), ЕБС (единая биометрическая система), СМЭВ (система межведомственного взаимодействия), ТРИБ (типовое решение информационной безопасности), НСПК (национальная система платежных карт). Иногда по требованию информационной безопасности нужно аттестовать API Gateway; это дополнительное время при реализации, которое стоит закладывать в дорожную карту.
Работали с API Gateway?
Да - 👍
Нет - 🙈
Полезно - 🦅