Архитектура API-шлюза и ключевые функции (руководство 2026)

Архитектура API-шлюза и ключевые функции (руководство 2026)

API-шлюз (API gateway) — это единая точка входа между клиентами и backend-сервисами: он принимает каждый запрос, применяет политики безопасности и трафика и направляет запрос в нужный сервис. Его архитектура состоит из двух частей: плоскости данных (data plane), которая обрабатывает живой трафик (маршрутизация, аутентификация, ограничение частоты запросов, преобразование, кэширование, логирование), и плоскости управления (control plane), где настраиваются эти политики. Ключевые функции, на которые стоит обращать внимание: маршрутизация, аутентификация и авторизация, rate limiting, преобразование запросов и ответов, кэширование, наблюдаемость и механизмы отказоустойчивости — таймауты, повторы и circuit breaker.

В этом руководстве архитектура API-шлюза разбирается на схеме, объясняется каждый компонент и функция, сравниваются распространённые схемы развёртывания и продукты, приводятся рабочие конфигурации и код. В последнем разделе показано, как та же архитектура применяется к шлюзам для API больших языковых моделей (LLM). Сведения о продуктах взяты из официальной документации по состоянию на 24 октября 2026 года.

Что такое API-шлюз?

В микросервисной системе без шлюза клиентам пришлось бы знать адрес, протокол и схему аутентификации каждого сервиса. Паттерн API gateway ставит перед ними один компонент. Клиенты обращаются к шлюзу, а шлюз решает, куда направить каждый запрос и какие правила применить.

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

Схема архитектуры API-шлюза

 Clients (web, mobile, partners, internal jobs)
        |
        v
 [ DNS / CDN / WAF / Load balancer ]
        |
        v
 +--------------------- API GATEWAY (data plane) ---------------------+
 |  TLS termination -> AuthN/AuthZ -> Rate limit & quota ->           |
 |  Request validation & transform -> Cache lookup -> Router          |
 |  -> Timeouts / retries / circuit breaker -> Response transform     |
 |  -> Logs, metrics, traces                                          |
 +--------------------------------------------------------------------+
        |               |                 |
        v               v                 v
   Orders service   Users service   Payments service   (or Lambda, queues, LLM providers)

 Control plane: config store, admin API/UI, policy and key management, deploys config to data plane

Основные компоненты

Компонент	Роль
Listener / терминация TLS	Принимает соединения HTTP/1.1, HTTP/2, gRPC или WebSocket и расшифровывает TLS
Аутентификация и авторизация	Проверяет API-ключи, токены OAuth 2.0 / JWT или сертификаты mTLS, затем права доступа
Ограничитель частоты и квоты	Ограничивает запросы по клиенту, ключу или маршруту; при превышении возвращает HTTP 429
Валидация и преобразование запросов	Проверяет схемы, переписывает пути и заголовки, конвертирует протоколы (например, REST в gRPC)
Кэш	Отдаёт повторяющиеся ответы без обращения к backend
Маршрутизатор	Сопоставляет путь, метод, хост или заголовок с upstream-сервисом и балансирует нагрузку между экземплярами
Слой отказоустойчивости	Таймауты, повторы с backoff, circuit breaker и фолбэки
Наблюдаемость	Логи доступа, метрики (задержка, доля ошибок) и распределённые трассировки
Плоскость управления	Хранит конфигурацию и доставляет её на экземпляры шлюза; предоставляет admin API или UI

Жизненный цикл запроса

1. Клиент отправляет GET /orders/42 с bearer-токеном.
2. Шлюз терминирует TLS и проверяет токен.
3. Проверяет лимит запросов и квоту вызывающей стороны.
4. Валидирует запрос и добавляет заголовки, например идентификатор запроса.
5. Проверяет кэш и при промахе направляет запрос на исправный экземпляр orders.
6. Применяет таймаут, один раз повторяет запрос при ошибке соединения и фиксирует результат.
7. При необходимости преобразует ответ и возвращает его, логируя статус, задержку и вызывающую сторону.

Ключевые функции API-шлюза

Вот функции, которые нужны большинству команд, примерно в порядке важности:

1. Маршрутизация запросов. Маршрутизация по пути, хосту, методу и заголовку, а также балансировка нагрузки и канареечные или взвешенные релизы.
2. Аутентификация и авторизация. API-ключи, проверка OAuth 2.0 и JWT, mTLS и политики доступа для каждого маршрута.
3. Rate limiting и квоты. Лимиты для каждого потребителя, защищающие backend; код HTTP 429 «Too Many Requests» определён в RFC 6585.
4. Преобразование запросов и ответов. Добавление заголовков, маппинг payload, трансляция протоколов и версионирование API.
5. Кэширование. Кэширование ответов с TTL для снижения задержки и нагрузки на backend.
6. Безопасность. TLS, белые и чёрные списки IP, ограничения размера запроса и интеграция с WAF.
7. Наблюдаемость. Структурированные логи доступа, метрики и передача трассировок в такие инструменты, как Grafana Tempo или Datadog.
8. Отказоустойчивость. Таймауты, повторы, circuit breaker и health checks.
9. Удобство для разработчиков. API-ключи и тарифы, портал разработчика и аналитика использования; часто объединяются под названием «API management».
10. Монетизация и учёт. Подсчёт использования по каждому потребителю для биллинга или внутреннего распределения затрат.

Схемы развёртывания

Схема	Как работает	Когда использовать
Единый центральный шлюз	Один кластер шлюза обслуживает все сервисы	Малые и средние системы, периметром владеет одна команда
Backend for frontend (BFF)	Отдельный шлюз для каждого типа клиентов (веб, мобильные, партнёры)	Клиентам нужны сильно различающиеся API
Шлюз на домен	Каждый бизнес-домен запускает собственный шлюз	Крупные организации с автономными командами
Kubernetes Ingress / Gateway API	Шлюз настраивается ресурсами Kubernetes	Сервисы уже работают в Kubernetes
Шлюз плюс service mesh	Шлюз обрабатывает трафик «север–юг» (клиенты), mesh — «восток–запад» (между сервисами)	Много внутренних сервисов, которым нужны mTLS и политики трафика

Kubernetes Gateway API теперь является стандартным способом настройки шлюзов в Kubernetes, и на нём построены такие реализации, как Envoy Gateway.

API-шлюз, балансировщик нагрузки и service mesh: в чём разница

• Балансировщик нагрузки распределяет трафик между экземплярами одного сервиса, в основном на сетевом или HTTP-уровне, без политик, учитывающих API.
• API-шлюз понимает API: аутентифицирует потребителей, применяет квоты по ключам, преобразует payload и маршрутизирует запросы между множеством сервисов.
• Service mesh управляет трафиком между внутренними сервисами, обычно через sidecar-прокси или прокси на узлах.

В большинстве продакшен-систем перед шлюзом стоит балансировщик нагрузки, а некоторые добавляют mesh за ним.

Популярные продукты API-шлюзов

Продукт	Тип	Примечания (октябрь 2026 года)
Amazon API Gateway	Управляемый (AWS)	REST, HTTP и WebSocket API; бесплатный уровень включает 1 млн вызовов REST, 1 млн вызовов HTTP и 1 млн сообщений WebSocket, а также 750 000 минут подключения в месяц в течение 12 месяцев
Kong Gateway	Open source и enterprise	Основан на плагинах; работает без БД (DB-less) с декларативной конфигурацией или с базой данных
Envoy Gateway	Open source	Прокси Envoy, управляемый через Kubernetes Gateway API
Azure API Management	Управляемый (Azure)	Управляемые и самостоятельно размещаемые шлюзы, а также портал разработчика

Пример: декларативная конфигурация Kong

Эта DB-less конфигурация Kong направляет /orders на backend, требует API-ключ и ограничивает каждого потребителя 60 запросами в минуту:

_format_version: "3.0"
services:
  - name: orders
    url: http://orders:8080
    routes:
      - name: orders-route
        paths: ["/orders"]
    plugins:
      - name: key-auth
      - name: rate-limiting
        config:
          minute: 60
          policy: local
consumers:
  - username: mobile-app
    keyauth_credentials:
      - key: replace-with-a-long-random-key

Пример: минимальный шлюз на Python

Чтобы увидеть архитектуру в коде, вот небольшой работающий шлюз с аутентификацией по API-ключу, ограничением частоты по ключу, маршрутизацией и таймаутом. Он предназначен для обучения; для реального трафика используйте продакшен-шлюз.

# pip install fastapi uvicorn httpx ; run: uvicorn gateway:app --port 8080
import time, httpx
from collections import defaultdict
from fastapi import FastAPI, Request, Response, HTTPException

ROUTES = {"/orders": "http://localhost:9001", "/users": "http://localhost:9002"}
KEYS = {"key-mobile": "mobile-app"}
LIMIT_PER_MIN = 60
hits = defaultdict(list)
app = FastAPI()

@app.api_route("/{path:path}", methods=["GET", "POST", "PUT", "DELETE"])
async def gateway(path: str, request: Request):
    consumer = KEYS.get(request.headers.get("x-api-key", ""))
    if not consumer:
        raise HTTPException(401, "invalid API key")
    now = time.time()
    hits[consumer] = [t for t in hits[consumer] if now - t < 60]
    if len(hits[consumer]) >= LIMIT_PER_MIN:
        raise HTTPException(429, "rate limit exceeded", headers={"Retry-After": "60"})
    hits[consumer].append(now)
    prefix = next((p for p in ROUTES if f"/{path}".startswith(p)), None)
    if not prefix:
        raise HTTPException(404, "no route")
    async with httpx.AsyncClient(timeout=5.0) as client:
        upstream = await client.request(request.method, ROUTES[prefix] + f"/{path}"[len(prefix):],
                                        content=await request.body(),
                                        headers={"x-consumer": consumer})
    return Response(upstream.content, upstream.status_code,
                    media_type=upstream.headers.get("content-type"))

От API-шлюза к LLM-шлюзу

Когда в роли backend выступают не микросервисы, а провайдеры ИИ-моделей, применяется та же архитектура, но с несколькими дополнительными задачами. LLM-шлюз (или AI gateway) добавляет:

Классическая функция шлюза	Расширение в LLM-шлюзе
Маршрутизация по пути	Маршрутизация по названию модели, стоимости, задержке или состоянию провайдера
Ограничение по числу запросов	Лимиты по токенам в минуту и расходам на ключ
Преобразование запросов	Перевод между форматами запросов OpenAI, Anthropic и Gemini
Кэширование ответов	Prompt caching и семантическое кэширование
Повторы и circuit breaker	Переключение на другого провайдера или модель при 429, 5xx или таймауте
Логи доступа	Количество токенов, стоимость запроса и использованная модель
API-ключи для потребителей	Один ключ для множества провайдеров с бюджетами по командам

 App / agent  --OpenAI-format request-->  LLM gateway
   auth + budget check -> model map -> route (primary provider)
   -> on 429/5xx/timeout: fallback provider -> usage + cost log
   -> Anthropic / OpenAI / Google / DeepSeek / self-hosted vLLM

Этот слой можно эксплуатировать самостоятельно (например, с LiteLLM или ИИ-плагинами Kong) или использовать управляемый сервис. Flatkey — управляемый вариант: один OpenAI-совместимый эндпоинт https://router.flatkey.ai/v1, один ключ для 300+ моделей, логи использования с токенами и стоимостью каждого вызова и лимиты расходов по ключу или группе, согласно его документации на октябрь 2026 года. Поскольку он использует формат OpenAI, существующим клиентам достаточно сменить base URL:

curl https://router.flatkey.ai/v1/chat/completions \
  -H "Authorization: Bearer $FLATKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"claude-sonnet-5-5","messages":[{"role":"user","content":"Summarize the API gateway pattern in one sentence."}]}'

Для более глубокого проектирования прочитайте наши руководства по архитектуре AI API-шлюза и маршрутизации моделей, circuit breaker для LLM-шлюзов, AI gateway и API management и управляемому AI-шлюзу против self-hosted прокси. Если тема для вас новая, начните с руководства для начинающих по LLM-шлюзам, а стратегии обработки 429 описаны в руководстве по работе с rate limit.

Чек-лист проектирования

• Размещайте TLS, аутентификацию и rate limiting на шлюзе, а не в каждом сервисе.
• Задавайте таймаут для каждого upstream-маршрута; никогда не ждите бесконечно.
• Повторяйте только идемпотентные запросы (GET, PUT, DELETE согласно RFC 9110), если backend не поддерживает ключи идемпотентности.
• Передавайте идентификатор запроса и контекст трассировки в каждый backend.
• Запускайте не менее двух экземпляров шлюза за балансировщиком, чтобы шлюз не стал единой точкой отказа.
• Не помещайте бизнес-логику в шлюз: он должен применять политики, а не реализовывать функции.
• Храните конфигурацию шлюза в git и развёртывайте её как код.

Частые вопросы

Что такое паттерн API gateway в микросервисах?

Это архитектура, в которой единый шлюз служит точкой входа для всех клиентских запросов. Шлюз направляет каждый запрос в нужный микросервис и берёт на себя общие задачи — аутентификацию, rate limiting и логирование, — поэтому клиенты не обращаются к сервисам напрямую.

Какие ключевые функции у API-шлюза?

Основные функции: маршрутизация запросов, аутентификация и авторизация, rate limiting и квоты, преобразование запросов и ответов, кэширование, средства безопасности, наблюдаемость и механизмы отказоустойчивости — таймауты, повторы и circuit breaker.

Из каких основных компонентов состоит архитектура API-шлюза?

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

API-шлюз — это то же самое, что балансировщик нагрузки?

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

Что такое LLM-шлюз?

LLM-шлюз — это API-шлюз, специализированный на трафике ИИ-моделей. Он маршрутизирует по модели и провайдеру, ограничивает по токенам и расходам, переводит запросы между форматами API провайдеров, переключается на резерв при сбое провайдера и логирует расход токенов и стоимость.

Является ли API-шлюз единой точкой отказа?

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

Источники

• Паттерн API gateway, microservices.io
• Руководство разработчика Amazon API Gateway и цены (октябрь 2026 года)
• Документация Kong Gateway (октябрь 2026 года)
• Envoy Gateway и Kubernetes Gateway API
• Обзор шлюзов Azure API Management
• RFC 6585 (HTTP 429) и RFC 9110 (семантика HTTP)