API Gateway упрощает вход в систему ровно до того момента, пока сам не становится самой тяжёлой точкой маршрутизации, безопасности и политик доступа.
Глава раскладывает gateway на отдельные обязанности: маршрутизацию, аутентификацию, лимиты, преобразование запросов и защиту внутренних сервисов от внешнего хаоса.
В интервью и архитектурных обсуждениях этот кейс полезен тем, что проверяет чувство границы между платформенным слоем и бизнес-логикой, а также понимание цены централизации.
Центральная точка политик
Через gateway удобно собирать аутентификацию, лимиты и правила доступа, но любая ошибка в этом месте сразу масштабируется на весь внешний трафик.
Критический путь запроса
Gateway стоит на пути каждого внешнего вызова, поэтому его задержка, квоты и преобразование трафика сразу становятся частью пользовательского SLA.
Отказные режимы
Нужно заранее определить, что происходит при сбое Redis, провайдера авторизации, конфигурации или зависимого сервиса: что блокируем, что упрощаем, что пропускаем.
Эксплуатационная цена
Мониторинг, трассировка, поэтапные выкладки и управление конфигурацией на gateway-слое требуют не меньше дисциплины, чем сами микросервисы.
Связанная книга
Building Microservices
Sam Newman подробно разбирает роль шлюза API в микросервисной архитектуре.
- это не просто единая точка входа для клиентских запросов. Здесь сходятся маршрутизация, безопасность, лимиты запросов, преобразование трафика и контроль над входным потоком. Поэтому удачный шлюз API делает внешний контур системы проще, а неудачный быстро превращается в перегруженную центральную точку.
Зачем нужен шлюз API?
Функциональные требования
Маршрутизация
- Маршрутизация по пути, например /users → User Service
- Маршрутизация по заголовкам, например для A/B-экспериментов
- Маршрутизация по параметрам запроса
- Взвешенная маршрутизация для канареечных релизов
Безопасность
- Проверка JWT- и OAuth2-токенов
- Управление API-ключами
- Белые и черные списки IP-адресов
- mTLS для межсервисных вызовов
Лимиты и квоты
- Лимиты на пользователя и IP-адрес
- Ограничения для отдельных эндпоинтов
- Обработка кратковременных всплесков нагрузки
- Управление квотами и планами доступа
Преобразование трафика
- Преобразование запросов и ответов
- Преобразование протоколов, например REST → gRPC
- Агрегация нескольких ответов в один
- Проверка схем и базовая валидация контракта
Связанный кейс
Rate Limiter
Подробный разбор алгоритмов ограничения запросов: Token Bucket, Sliding Window.
Нефункциональные требования
< 10 ms
Дополнительная задержка
P99
100K+ RPS
Пропускная способность
на инстанс
99.99%
Доступность
договорный уровень
Горизонтальное
Масштабирование
без локального состояния
Высокоуровневая архитектура
Мобильное приложение
Веб-клиент
Партнерский API
IoT-устройства
Балансировщик
L4/L7
Шлюз 1
Шлюз 2
Шлюз N
Пользователи
Заказы
Платежи
Внешние сервисы
Нажмите на клиента или запустите анимацию, чтобы посмотреть путь запроса
Ключевые паттерны
Бэкенд для фронтенда
Отдельный для каждого типа клиента. Так мобильное приложение, веб-клиент и админ-панель получают собственный фасад над одними и теми же внутренними сервисами.
Паттерн Backend for Frontend
Отдельный BFF для каждого клиентского интерфейса
КЛИЕНТЫ
Мобильное приложение
Оптимизировано под телефон
Веб-клиент
Полный пользовательский сценарий
Админ-панель
Расширенные права и обзор
СЛОЙ BFF
МИКРОСЕРВИСЫ
Композиция API
Шлюз API может собрать данные из нескольких сервисов в один ответ, чтобы клиенту не приходилось делать серию отдельных вызовов.
Преимущества:
- Меньше отдельных сетевых походов со стороны клиента
- Внутренняя структура сервисов скрыта от клиента
Риски:
- Растёт задержка ответа и цена каждого дополнительного запроса
- Усложняется обработка частичных ошибок и таймаутов
Связанная книга
Release It!
Michael Nygard подробно описывает размыкатель цепи и другие паттерны устойчивости.
Размыкатель цепи в шлюзе API
защищает шлюз API от каскадных отказов, когда недоступность одного зависимого сервиса начинает затрагивать весь входной слой.
Circuit Breaker Simulation
Паттерн защиты от каскадных сбоев
CLOSED
Нормальная работа. Запросы проходят к сервису.
State Transitions
Configuration
0
Total Requests
0
Successful
0
Rejected (Fast)
Fail Fast
Мгновенный отказ вместо ожидания timeout
Cascading Prevention
Защита от распространения сбоев
Self-Healing
Автоматическое восстановление через timeout
Документальный фильм
Inside Envoy: The Proxy for the Future
История Envoy Proxy и его роли рядом со шлюзами API и ingress-архитектурами.
Популярные решения
Kong
- Экосистема плагинов
- Расширение через Lua и Go
- Декларативная конфигурация
AWS API Gateway
- Интеграция с Lambda
- Поддержка WebSocket
- Оплата за запрос
Envoy
- L7-прокси
- Подходит для service mesh
- xDS API
NGINX Plus
- Высокая производительность
- Нативные модули
- Активные health checks
Traefik
- Автообнаружение сервисов
- Интеграция с Let's Encrypt
- Нативная работа с Kubernetes
Apigee (Google)
- Аналитика
- Портал для разработчиков
- Монетизация API
Советы для интервью
1. Начните с причины существования шлюза API
Объясните, какую проблему он решает: единая входная точка, защита внутренних сервисов, централизованные политики и единая обработка клиентского трафика.
2. Покажите, где живёт состояние
Сам шлюз API обычно держат без локального состояния, чтобы его можно было горизонтально масштабировать. Сессии, лимиты и другие общие данные выносят во внешнее хранилище, например в Redis.
3. Разберите отказ как у критичной входной точки
Gateway легко становится центральной точкой отказа, поэтому важно проговорить несколько инстансов, проверки здоровья, мягкую деградацию и понятное поведение по умолчанию при сбоях зависимостей.
4. Не превращайте шлюз API в бизнес-сервис
Он должен заниматься платформенными функциями: маршрутизацией, безопасностью, лимитами и преобразованием трафика. Бизнес-логика внутри шлюза API быстро делает его слишком тяжёлым.
Ключевые выводы
- Шлюз API даёт единую входную точку, где сходятся маршрутизация, безопасность, лимиты запросов и наблюдаемость.
- Шлюз API обычно держат без локального состояния, чтобы его можно было масштабировать горизонтально и безопасно обновлять.
- Бэкенд для фронтенда помогает дать разным клиентам свой фасад без утечки внутренней структуры сервисов.
- Композиция API уменьшает число клиентских вызовов, но повышает задержку ответа и усложняет обработку ошибок.
- Размыкатель цепи защищает входной слой от каскадных отказов зависимых сервисов.
- Чем больше бизнес-логики внутри шлюза API, тем выше риск превратить удобный платформенный слой в новую точку перегрузки.
Для дополнительной практики по паттерну шлюза API полезно посмотреть microservices.io: API Gateway pattern и AWS API Gateway Developer Guide.
Связанные главы
- System Design Primer (краткий обзор) - даёт базовые принципы декомпозиции, проектирования API и отказоустойчивости, на которых обычно строят gateway-слой.
- Continuous API Management (short summary) - расширяет тему жизненного цикла API, управления политиками и контрактного контроля вокруг gateway-платформы.
- Customer-friendly API: удобное API для клиентов - показывает, как строить клиентский фасад над внутренними сервисами и где отдельный слой под клиента действительно оправдан.
- Rate Limiter - детализирует алгоритмы ограничения трафика и управление квотами, которые часто реализуют на уровне gateway.
- API Security Patterns - дополняет разговор о безопасности gateway: аутентификация, авторизация, работа с токенами и применение политик доступа.
- Inter-Service Communication Patterns - показывает, где заканчивается ответственность gateway и начинается внутренняя синхронная или асинхронная коммуникация сервисов.
- Архитектура сервисной сетки (service mesh) - помогает развести роли внешнего gateway и service mesh внутри микросервисной платформы.
- Inside Envoy: The Proxy for the Future - даёт практический контекст по Envoy как одной из типовых L7-основ для gateway и ingress-архитектур.
- Resilience Patterns - усиливает разделы про таймауты, повторные попытки, размыкатель цепи и мягкую деградацию на уровне gateway.
- Zero Trust - связывает gateway с моделью непрерывной проверки, политиками доступа и минимизацией доверия.
- Kubernetes Fundamentals - объясняет, как gateway разворачивают в Kubernetes: ingress, автомасштабирование, обнаружение сервисов и поэтапные обновления.
- Notification System - показывает, как gateway работает перед многоканальной системой доставки и управляет внешним API-трафиком.