Транспорт бэкенда
API Gateway и Service Mesh
Netflix имеет 500+ микросервисов. Мобильное приложение не может знать URL каждого из них. Кто добавляет JWT токен в каждый запрос? Кто останавливает DDoS атаку? Кто логирует каждый запрос? Кто делает canary deployment для 2% пользователей? API Gateway - ответ на все эти вопросы.
- **Kong** (ранее Mashape) - самый популярный open-source API Gateway: 100M+ загрузок, используется Adobe, Microsoft, Honeywell. Плагинная архитектура на Lua поверх nginx.
- **AWS API Gateway** обрабатывает сотни миллиардов запросов в месяц для тысяч компаний. Интегрируется с Lambda, ECS, Cognito из коробки.
- **Istio** используется в Google Cloud, IBM Cloud, Red Hat OpenShift. Управляет mTLS для service-to-service коммуникации без изменений в коде приложения.
API Gateway Pattern
API Gateway - единая точка входа для всех клиентов (мобильные, веб, партнёры). Вместо того чтобы клиенты вызывали 50 микросервисов напрямую, Gateway агрегирует, маршрутизирует и применяет cross-cutting concerns: auth, rate limiting, logging.
Netflix разработал Zuul Gateway для управления 1B+ запросов в день. Позже перешли на Zuul 2 (async) и собственный решение. Amazon API Gateway обрабатывает сотни миллиардов запросов в месяц.
Какое главное преимущество API Gateway для микросервисной архитектуры?
Envoy Proxy
Envoy - high-performance Layer 7 proxy, разработанный в Lyft (2016). Написан на C++, обрабатывает HTTP/1.1, HTTP/2, gRPC, TCP. Основа большинства modern service mesh решений (Istio, AWS App Mesh, Consul Connect). Конфигурируется через xDS API (dynamic discovery).
Envoy как sidecar: в Kubernetes рядом с каждым pod запускается Envoy контейнер. Он перехватывает весь входящий и исходящий трафик pod'а. Приложение не знает о Envoy - он прозрачен.
Почему Envoy используется как sidecar в Kubernetes, а не как отдельный сервис?
Service Mesh и Istio
Service Mesh - инфраструктурный слой для управления service-to-service коммуникацией. Istio (Google, IBM, Lyft) - самый популярный service mesh: развёртывает Envoy sidecar в каждый pod и управляет конфигурацией через control plane.
Альтернативы Istio: Linkerd (проще, меньше overhead), Consul Connect (HashiCorp), AWS App Mesh. Istio добавляет ~5ms к каждому запросу и ~50MB RAM per sidecar. Для 1000 pod'ов это 50GB RAM только на sidecars.
В чём главное преимущество Service Mesh перед library-based подходом (Hystrix, Resilience4j)?
Rate Limiting алгоритмы
Rate Limiting защищает API от злоупотреблений и перегрузки. Алгоритмы отличаются по точности и поведению при burst трафике. Token Bucket (используется Stripe, AWS) - наиболее гибкий: разрешает burst до размера корзины, затем steady rate.
Redis + Lua скрипт - стандартная реализация distributed rate limiting. Lua скрипт выполняется атомарно (нет race conditions). Альтернатива: Redis RedisCell модуль (GCRA алгоритм) - одна команда CL.THROTTLE.
Клиент отправляет 200 запросов за 1 секунду, лимит 100 req/s с Token Bucket (capacity=100). Что произойдёт?
Observability в Gateway
API Gateway - идеальное место для сбора observability данных: все запросы проходят через него. Три столпа observability: Metrics (Prometheus), Logs (structured JSON), Traces (OpenTelemetry, Jaeger). Gateway добавляет request ID для корреляции.
Kong, AWS API Gateway, Nginx автоматически генерируют request ID и propagate его в upstream сервисы через X-Request-ID заголовок. Это позволяет трассировать запрос через всю цепочку сервисов в логах.
API Gateway и Service Mesh решают одну задачу - нужно выбрать что-то одно
API Gateway - для north-south трафика (клиент -> кластер), Service Mesh - для east-west трафика (сервис -> сервис). Их часто используют вместе.
API Gateway управляет внешними клиентами: auth, rate limiting, публичные endpoints. Service Mesh управляет внутренней коммуникацией: mTLS, circuit breaking, внутренняя observability. Istio + Kong - типичная production комбинация.
Почему P99 latency важнее среднего времени ответа для monitoring API Gateway?
Итоги
- **API Gateway** - единая точка входа: централизует auth, rate limiting, logging. Клиенты не знают о внутренней топологии сервисов.
- **Envoy + Istio** - service mesh для east-west трафика: mTLS между сервисами, circuit breaking, canary deployments без изменений в коде.
- **Rate Limiting** - Token Bucket для burst-tolerant APIs (Stripe), Leaky Bucket для constant rate. Redis + Lua для distributed implementation.
Связанные темы
API Gateway и Service Mesh работают вместе с другими слоями инфраструктуры:
- Distributed Tracing и Observability — Gateway генерирует request ID и первый span - начало distributed trace через все downstream сервисы
- Безопасность транспорта — Gateway - место для SSL termination, JWT validation, WAF; Service Mesh добавляет mTLS для внутренней коммуникации
Вопросы для размышления
- Когда Service Mesh становится излишним overhead и проще обойтись библиотеками (Resilience4j, Hystrix)?
- Как API Gateway влияет на latency? При каком P99 latency самого Gateway стоит рассматривать альтернативы?
- Как строить canary deployment через API Gateway для 1% пользователей, не по случайному выбору, а детерминированно (один пользователь всегда видит новую версию)?