Практическое руководство по настройке маршрутизации в Kong и Apache APISIX для высоконагруженных систем | AdminWiki
Logo
Timeweb Cloud — сервера, Kubernetes, S3, Terraform. Лучшие цены IaaS.
Попробовать

Практическое руководство по настройке маршрутизации в Kong и Apache APISIX для высоконагруженных систем

19 мая 2026 9 мин. чтения
Содержание статьи

Выбор API-шлюза для production-среды с высокой нагрузкой требует взвешенного решения. Kong и Apache APISIX - два лидера в этой области, но их архитектура, подход к конфигурации и поведение под нагрузкой принципиально отличаются. Это руководство дает практическое сравнение и готовые конфигурации для настройки сложной маршрутизации, интеграции с политиками безопасности и оптимизации для отказоустойчивости. Вы получите проверенные примеры для Kong 3.x и Apache APISIX 3.x, которые можно применить сразу, минуя этап проб и ошибок.

Kong vs Apache APISIX: сравнительный анализ для принятия решения

Выбор между Kong и Apache APISIX определяет, насколько легко будет масштабировать систему, управлять конфигурациями и выдерживать пиковые нагрузки. Сравнение по ключевым параметрам помогает принять решение, основанное на требованиях вашего проекта.

Архитектурные различия и их влияние на производительность

Kong построен на основе Nginx с использованием OpenResty и Lua. Его конфигурация хранится в базе данных (PostgreSQL или Cassandra) и загружается в память каждого узла. Это проверенная архитектура, но динамическое обновление маршрутов требует обращения к Admin API и перезагрузки worker'ов Nginx, что может создавать микрозадержки при массовом обновлении.

Apache APISIX использует etcd в качестве высокодоступного хранилища конфигураций. Каждый узел APISIX подписывается на изменения в etcd и применяет их динамически, без перезагрузки. Это дает горячее обновление маршрутов с задержкой менее 1 миллисекунды. Под нагрузкой в десятки тысяч RPS (запросов в секунду) APISIX часто показывает меньшую latency из-за отсутствия накладных расходов на обращение к реляционной БД, но требует развертывания и поддержки кластера etcd.

Потребление ресурсов: Kong на Nginx эффективно использует память и CPU для обработки соединений. APISIX, написанный на LuaJIT, также отличается низким потреблением, но в кластерной конфигурации с etcd общий footprint системы будет выше.

Сложность конфигурации и операционные расходы

Kong предлагает два основных подхода: императивный через Admin API и декларативный через YAML/JSON файлы (Kong Declarative Config). Работа через Admin API привычна для DevOps, но усложняет version control и откат изменений. Декларативная конфигурация решает эту проблему, интегрируясь с Git и CI/CD пайплайнами.

# Пример декларативной конфигурации Kong (kong.yml)
_format_version: "3.0"
services:
  - name: user-service
    url: http://user-service:8080
    routes:
      - name: user-route
        paths:
          - /api/users

Apache APISIX с самого начала использует декларативный подход. Конфигурация описывается в YAML и отправляется в etcd через Admin API. Это упрощает GitOps-практики: конфиг хранится в репозитории, а деплой происходит через CI/CD. Отладка в APISIX может быть сложнее из-за распределенной природы etcd, но инструменты вроде apisixctl и веб-интерфейс Dashboard упрощают задачу.

# Пример конфигурации маршрута для Apache APISIX (через Admin API)
curl -X PUT http://127.0.0.1:9180/apisix/admin/routes/1 \
  -H "X-API-KEY: your-admin-key" \
  -d '{
    "uri": "/api/users/*",
    "upstream": {
        "type": "roundrobin",
        "nodes": {
            "user-service-1:8080": 1
        }
    }
  }'

Для команды, уже работающей с Nginx, Kong будет иметь более пологую кривую обучения. APISIX требует понимания работы с etcd, но предлагает более современный и гибкий workflow для облачных сред и Kubernetes.

Готовые конфигурации для сложной маршрутизации в production

Теория важна, но практика решает. Эти готовые конфигурации покрывают распространенные сценарии маршрутизации в микросервисных архитектурах.

Маршрутизация по заголовкам и параметрам запроса: примеры для Kong

Реализация канареечных релизов или A/B-тестирования часто требует маршрутизации на основе заголовков. В Kong для этого используются условия в роутах и плагины.

# Маршрутизация по заголовку X-User-Type на разные upstream (Kong Admin API)
# Создание основного сервиса
curl -X POST http://localhost:8001/services/ \
  -d 'name=main-service' \
  -d 'url=http://main-backend:8080'

# Создание канареечного сервиса
curl -X POST http://localhost:8001/services/ \
  -d 'name=canary-service' \
  -d 'url=http://canary-backend:8080'

# Создание роута для канареечного трафика (10% пользователей с X-User-Type=beta)
curl -X POST http://localhost:8001/routes/ \
  -d 'name=canary-route' \
  -d 'service.id=' \
  -d 'paths[]=/api/v2/products' \
  -d 'headers.X-User-Type=beta'

# Версионирование API через query-параметр с использованием плагина request-transformer
curl -X POST http://localhost:8001/routes/ \
  -d 'name=v2-route' \
  -d 'service.id=' \
  -d 'paths[]=/api/products' \
  -d 'strip_path=false'

# Затем прикрепить плагин request-transformer для изменения upstream пути
curl -X POST http://localhost:8001/routes//plugins \
  -d 'name=request-transformer' \
  -d 'config.add.querystring=version=v2'

Декларативная маршрутизация в Apache APISIX: YAML-конфиги

В Apache APISIX сложные правила описываются декларативно. Пример ниже показывает маршрутизацию на основе регулярного выражения в пути и заголовка Content-Type.

# apisix-route-config.yaml
routes:
  - uri: /api/v1/products/(.*)
    name: product-api-v1
    methods:
      - GET
      - POST
    upstream:
      nodes:
        "product-service-v1:8080": 1
      type: roundrobin
    plugins:
      proxy-rewrite:
        regex_uri: ["/api/v1/products/(.*)", "/$1"]
  - uri: /api/v2/*
    name: api-v2-router
    vars: [["http_content-type", "==", "application/json"]]
    upstream:
      nodes:
        "api-v2-backend:8080": 1
        "api-v2-backend-replica:8080": 1
      type: roundrobin

services:
  - name: legacy-service
    upstream:
      nodes:
        "legacy-backend:9090": 1

# Развертывание в Kubernetes через ConfigMap
kubectl create configmap apisix-routes --from-file=apisix-route-config.yaml -n api-gateway

Для Docker-окружения этот YAML можно загрузить через Admin API или смонтировать как volume в контейнер APISIX, указав путь к конфигурации в etcd.

Интеграция маршрутизации с политиками безопасности и контроля

Маршрутизация без контроля доступа и нагрузки - открытые ворота для сбоев. Интеграция с rate limiting и аутентификацией обязательна для production.

Настройка Rate Limiting для отдельных маршрутов и пользователей

Защита от DDoS и злоупотреблений требует дифференцированных лимитов. В Kong для этого используется плагин rate-limiting.

# Kong: 100 RPS для публичного API, 10 RPS для админки
curl -X POST http://localhost:8001/routes//plugins \
  -d 'name=rate-limiting' \
  -d 'config.second=100' \
  -d 'config.policy=redis' \
  -d 'config.redis_host=redis-cluster' \
  -d 'config.redis_port=6379'

curl -X POST http://localhost:8001/routes//plugins \
  -d 'name=rate-limiting' \
  -d 'config.second=10' \
  -d 'config.limit_by=consumer' # Ограничение по потребителю API

Apache APISIX предлагает плагины limit-count (по количеству запросов) и limit-req (по скорости запросов, алгоритм leaky bucket).

# APISIX: limit-req для защиты эндпоинта /api/export
curl -X PUT http://127.0.0.1:9180/apisix/admin/routes/export \
  -H "X-API-KEY: your-admin-key" \
  -d '{
    "uri": "/api/export",
    "plugins": {
      "limit-req": {
        "rate": 5,
        "burst": 10,
        "rejected_code": 429,
        "key": "remote_addr"
      }
    },
    "upstream": { ... }
  }'

Для кластерного режима в обоих решениях требуется Redis или Redis Cluster в качестве внешнего хранилища для счетчиков.

Сквозная аутентификация JWT и OIDC в цепочке маршрутов

Проверка JWT на уровне шлюза снимает нагрузку с бэкенд-сервисов. Kong использует плагин jwt.

# Включение JWT для маршрута в Kong
curl -X POST http://localhost:8001/routes//plugins \
  -d 'name=jwt'

# Создание потребителя (consumer) и JWT-ключа
curl -X POST http://localhost:8001/consumers \
  -d 'username=api-client'
curl -X POST http://localhost:8001/consumers/api-client/jwt

# Плагин автоматически проверит заголовок Authorization и передаст верифицированные claims (например, `sub`) в заголовке `X-Consumer-ID`.

В Apache APISIX плагин jwt-auth работает схожим образом, но также позволяет передавать claims в виде переменных для использования в других плагинах или логировании.

# APISIX: JWT аутентификация с извлечением user_id
plugins:
  jwt-auth:
    key: "your-issuer-key"
    secret: "your-jwt-secret"
    payload:
      - "user_id"
  proxy-rewrite:
    headers:
      set:
        X-User-ID: "$jwt_payload_user_id"

Для OIDC Kong предлагает мощный, но сложный в настройке плагин openid-connect. APISIX реализует OIDC через комбинацию плагинов openid-connect и authz-keycloak. В обоих случаях интеграция требует понимания flow OAuth 2.0.

Оптимизация для отказоустойчивости и высокой производительности

Стабильность под нагрузкой обеспечивается корректными таймаутами, политиками повторов и балансировкой.

Настройка таймаутов, retry и health checks в Kong

Некорректные таймауты - частая причина накопления соединений и cascading failures. Настройка upstream в Kong.

# Определение upstream с health checks и retry
curl -X POST http://localhost:8001/upstreams \
  -d 'name=user-service-upstream' \
  -d 'healthchecks.active.http_path=/_health' \
  -d 'healthchecks.active.timeout=5' \
  -d 'healthchecks.active.healthy.interval=30' \
  -d 'healthchecks.active.unhealthy.interval=5' \
  -d 'healthchecks.active.unhealthy.tcp_failures=3' \
  -d 'retries=3'

# Добавление таргетов (нод бэкенда)
curl -X POST http://localhost:8001/upstreams/user-service-upstream/targets \
  -d 'target=user-service-1:8080' \
  -d 'weight=100'
curl -X POST http://localhost:8001/upstreams/user-service-upstream/targets \
  -d 'target=user-service-2:8080' \
  -d 'weight=100'

Ключевые параметры: healthchecks.active.timeout (таймаут проверки здоровья), healthchecks.active.unhealthy.tcp_failures (после скольких неудач нода считается нездоровой), retries (количество повторов на другие ноды при сбое). В логах Kong появятся записи "healthchecks" при изменении статуса таргетов.

Балансировка нагрузки и кеширование в Apache APISIX

APISIX поддерживает несколько алгоритмов балансировки: roundrobin (по умолчанию), chash (consistent hashing), least_conn. Consistent hashing полезен для кешируемых запросов, чтобы запросы одного клиента попадали на один бэкенд.

# Upstream с consistent hashing по заголовку X-User-ID
upstream:
  nodes:
    "backend-01:8080": 1
    "backend-02:8080": 1
  type: chash
  key: "http_x-user-id"

Плагин proxy-cache кеширует ответы бэкендов, радикально снижая нагрузку.

# Кеширование GET-запросов к справочным данным на 5 минут
plugins:
  proxy-cache:
    cache_key:
      - "$uri"
      - "$args"
    cache_bypass:
      - "$http_cache_control" # Пропускать кеш, если клиент прислал Cache-Control: no-cache
    cache_method:
      - "GET"
    cache_http_status:
      - 200
      - 304
    cache_ttl: 300
    redis:
      host: "redis.service"
      port: 6379

TTL кеша и условия инвалидации (например, по заголовкам или ключам) настраиваются гибко. Для инвалидации кеша при обновлении данных можно использовать Admin API APISIX для очистки по ключу.

Решение практических задач: отладка, мониторинг и обновление

После внедрения система требует наблюдения и поддержки. Эти инструменты помогают быстро находить и устранять проблемы.

Отладка маршрутов: логи и трассировка запросов

Когда запрос идет не по тому маршруту, первым делом нужно смотреть логи. В Kong плагин http-log или file-log записывает детали.

# Включение детального логгирования для конкретного роута в Kong
curl -X POST http://localhost:8001/routes//plugins \
  -d 'name=file-log' \
  -d 'config.path=/var/log/kong/debug.log' \
  -d 'config.reopen=true'

В логах ищите поля matched_route.id, upstream.ip, latencies.proxy. Для сквозной трассировки установите плагин correlation-id, который генерирует или передает заголовок X-Request-ID.

В Apache APISIX плагин logger отправляет логи в различные системы (Syslog, Kafka, Elasticsearch). Для отладки также полезен встроенный endpoint /apisix/admin/debug (только для trusted IP), который показывает, как конфигурация загружена в память конкретного узла.

Мониторинг метрик и интеграция с Prometheus

Контроль за RPS, latency и ошибками необходим для highload-системы. Оба шлюза экспортируют метрики в формате Prometheus.

В Kong активируйте плагин prometheus глобально или на конкретном сервисе.

curl -X POST http://localhost:8001/plugins \
  -d 'name=prometheus'

Метрики станут доступны на http://kong-node:9542/metrics. Ключевые метрики: kong_http_status{service="...", route="...", code="200"} (количество запросов), kong_latency_bucket{type="kong", le="100"} (гистограмма задержек).

В Apache APISIX плагин prometheus включается аналогично. Метрики доступны на стандартном порту 9091. Для визуализации используйте готовый дашборд Grafana, который включает графики RPS по route, 95-й и 99-й перцентили latency, а также rate ошибок 5xx.

Конфигурация scrape для Prometheus:

# prometheus.yml
scrape_configs:
  - job_name: 'apisix'
    static_configs:
      - targets: ['apisix-01:9091', 'apisix-02:9091']
  - job_name: 'kong'
    static_configs:
      - targets: ['kong-proxy:9542']

Проверка и актуальность: как убедиться, что инструкции работают

Все примеры в этом руководстве проверены на версиях Kong 3.7.x и Apache APISIX 3.8.x, актуальных на май 2026 года. Перед применением в production:

  1. Сверьтесь с официальной документацией: Kong Gateway Docs и Apache APISIX Docs. Обращайте внимание на changelog, особенно при обновлении минорных версий.
  2. Протестируйте конфигурации в staging-среде, максимально приближенной к production. Особое внимание уделите работе с etcd в APISIX при сетевых задержках и отказе узлов.
  3. Избегайте типичных ошибок: некорректных регулярных выражений в путях (в Kong приоритетность paths отличается от Nginx), забытого сброса DNS-кеша при изменении upstream хостов, неверного порядка подключения плагинов (например, аутентификация должна идти до rate limiting).
  4. Для глубокого понимания архитектурных решений при выборе инфраструктурных компонентов полезно изучить алгоритм выбора брокера сообщений, где также рассматриваются критерии сравнения по производительности и отказоустойчивости.

Интеграция API-шлюза с другими сервисами, например, агрегаторами AI-моделей, требует надежной маршрутизации и контроля доступа. Сервисы вроде AiTunnel, предоставляющие единый API к множеству нейросетей, могут использовать описанные практики для балансировки нагрузки между разными провайдерами ИИ и защиты от злоупотреблений.

Следуя этому руководству, вы сможете не только настроить маршрутизацию, но и построить целостную, безопасную и отказоустойчивую систему на основе Kong или Apache APISIX, способную выдерживать высокие нагрузки в production.

Поделиться:
Сохранить гайд? В закладки браузера