Какой у вас опыт работы с API Gateway?

А, ну вот, блядь, классика жанра! API Gateway — это ж такая штука, без которой в микросервисах нихуя не работает, а с ней — всё работает, но иногда тоже нихуя, если настроить криво.

Слушай, представь себе: у тебя куча этих самых микросервисов, как тараканы по углам разбежались. И каждый орет: «Ко мне на порт 8081!», «А ко мне на 8082, блядь!». А клиенту-то что? Ему что, по всем этим портам бегать, как угорелому? Хуй там! Вот тут и выходит на сцену наш главный герой — шлюз, ёпта. Он как суровый швейцар в дорогом борделе: всех встречает на одном парадном входе, а дальше уже сам решает, кого в какую комнату провести.

И чем же этот швейцар, простите, шлюз, занимается? Да всем, блядь!

1. Маршрутизация и балансировка. Это основа основ. Пришёл запрос на /api/orders — отправил его в сервис заказов. Пришёл на /api/users — ну ты понял. А если сервисов заказов несколько? А он их по кругу гоняет, чтобы ни один не сдох от нагрузки. Умная жопа, короче.
2. Агрегация запросов. Это вообще магия. Клиенту нужно за раз и пользователя, и его заказы, и ещё погоду в его городе. Без шлюза ему пришлось бы делать три отдельных вызова, как дурачку. А с ним — один запрос кинул, а шлюз сам по-тихому сбегает во все три сервиса, соберёт ответы в кучу и одним пакетом отдаст. Красота, ебать мои старые костыли!
3. Аутентификация и авторизация. Вот это, я тебе скажу, самое охуенное. Вместо того чтобы в каждом сервисе повторять один и тот же код по проверке JWT-токенов (который ещё и написать правильно — тот ещё геморрой), ты эту хуйню настраиваешь в одном месте — на шлюзе. Пришёл запрос без токена — сразу, нахуй, 401 Unauthorized. Токен есть, но прав нет — 403 Forbidden. И бэкендовые сервисы уже получают запросы от проверенных ребят и могут спокойно заниматься своей работой, а не ебёй с безопасностью.
4. Ограничение скорости (Rate Limiting). Чтобы какой-нибудь еблан не начал слать по десять тысяч запросов в секунду и не положил всю систему. Шлюз считает: «Ага, Васян с IP 123.456.789, ты сегодня уже достаточно насосал, отдохни, дружок». И отправляет ему вежливый 429 Too Many Requests.
5. Кеширование. Ну, тут всё просто. Если данные редко меняются, зачем каждый раз дергать бэкенд? Отдал из кеша — и все довольны, и сервис разгружен.
6. Мониторинг и логи. Это ж золотая жила! Все запросы проходят через одну точку. Хочешь — логируй, хочешь — метрики собирай. Понять, где тормозит, кто кого заDDOSил — раз плюнуть.

Ну и как это выглядит под капотом? Вот, смотри, простой пример для Spring Cloud Gateway. Выглядит почти как мирный конфиг, но сила в нём — овердохуища.

spring:
  cloud:
    gateway:
      routes:
      - id: user_service
        uri: lb://user-service # Куда отправлять? В сервис пользователей.
        predicates:
          - Path=/api/users/** # Если путь начинается с /api/users
        filters:
          - name: RequestRateLimiter # И навесим на этот путь ограничитель скорости
            args:
              redis-rate-limiter.replenishRate: 10 # 10 запросов в секунду
              redis-rate-limiter.burstCapacity: 20 # но можно кратковременно 20, если хорошо себя вел

Вот так, блядь. Одна строчка в конфиге — и уже есть и маршрутизация, и балансировка (lb://), и лимитер, привязанный к Redis. Красота!

Пробовал и Spring Cloud Gateway (для своих, на Java), и Kong (монстр мощный), и AWS API Gateway (когда всё уже в облаках). У каждого свои приколы, но суть одна: без этой хитрой жопы в виде шлюза строить микросервисы — это как ебаться с разбегу в бетонную стену. Больно и бесполезно.