Kong Gateway или Tyk Gateway: что выгоднее и когда

MAATRIX

Когда микросервисов становится больше трёх-четырёх, разработчики рано или поздно упираются в вопрос единой точки входа: авторизация, rate limiting, логирование и маршрутизация начинают дублироваться в каждом сервисе. Kong Gateway и Tyk Gateway — два самых обсуждаемых open source API-шлюза для такой задачи, но у них разная архитектура, разная модель лицензирования и разные требования к серверу. Разберём, чем они отличаются на практике и в каком сценарии каждый обойдётся дешевле — и по деньгам, и по времени на поддержку.

Архитектура: как устроены Kong и Tyk

Kong Gateway построен поверх NGINX и OpenResty — то есть по сути это NGINX с логикой на Lua, работающей через LuaJIT прямо в цикле обработки запроса. У Kong есть два режима хранения конфигурации:

• DB-less — вся конфигурация в одном YAML-файле (kong.yml), гейтвей перечитывает его при старте или по сигналу. Никакой базы данных не нужно, подходит для GitOps-подхода, когда конфиг лежит в репозитории.
• DB-режим — конфигурация хранится в PostgreSQL (Cassandra почти не используют в новых проектах), а сам Kong обращается к базе при каждом изменении маршрутов через Admin API.

Tyk Gateway написан на Go и не является надстройкой над NGINX — это самостоятельный HTTP-сервер. Для собственно проксирования запросов Tyk Gateway в open source редакции файл-центричен: конфигурации API описываются JSON-файлами в apps/, а сам процесс их подхватывает. Но полноценная эксплуатация с UI, аналитикой и синхронизацией между несколькими инстансами шлюза завязана на Redis (обязателен — используется для rate limiting, кэша токенов и pub/sub между узлами) и Tyk Pump для выгрузки аналитики в внешнее хранилище (MongoDB, PostgreSQL, Elasticsearch, InfluxDB — на выбор).

Практический вывод: Kong в DB-less режиме — это один процесс и один файл, минимальный стек. Tyk без Redis теряет rate limiting между узлами и часть функциональности, так что Redis фактически обязателен даже для скромной установки.

Лицензии и цена: что бесплатно, что enterprise

Оба продукта работают по модели open core: базовый gateway бесплатный, продвинутые возможности — платные.

Ключевая разница в мышлении: у Kong большая часть повседневной работы (маршруты, плагины, consumers) управляется через Admin API или декларативный YAML — UI не обязателен даже для продакшена, многие команды живут годами вообще без Kong Manager. У Tyk открытый gateway логически рассчитан на связку с Dashboard: без него управление API возможно, но неудобно — правки JSON-файлов вручную и релоад процесса плохо масштабируются на команду больше одного человека.

Если бюджет ограничен и вы готовы работать через API/конфиги, оба варианта бесплатны. Но по факту Kong OSS чаще используют «как есть» годами, а Tyk OSS быстрее подталкивает к покупке Dashboard, если в команде больше одного администратора API.

Производительность и нагрузка на ресурсы VPS

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

• Kong на LuaJIT в DB-less режиме имеет минимальный оверхед на запрос — плагины выполняются в том же воркере NGINX, без сетевых прыжков. При включённом PostgreSQL как источнике конфига сама база не участвует в горячем пути (Kong кэширует конфиг в памяти), она нужна только при изменениях.
• Tyk на Go тоже быстр за счёт компилируемого языка и собственного HTTP-стека, но каждый запрос с rate limiting обращается к Redis — если Redis на том же сервере с низкой задержкой, это некритично, но добавляет сетевой (или хотя бы IPC) шаг, которого у Kong DB-less нет.

По памяти в состоянии покоя оба гейтвея на небольшом трафике (до пары тысяч запросов в секунду) комфортно живут на VPS с 2 vCPU и 4 ГБ RAM, включая процесс базы/Redis рядом. Для Kong в DB-less режиме можно уложиться даже в 2 ГБ, если плагинов немного. Точные цифры throughput на вашем трафике стоит снять бенчмарком (wrk или k6) именно на вашем наборе плагинов и апстримов — универсальных «X тысяч RPS» тут давать не будем, слишком сильно зависит от того, что делает каждый плагин (например, JWT-валидация или обращение к внешнему auth-серверу съедает заметно больше времени, чем простой rate limiting).

# быстрый бенчмарк одного маршрута через wrk
wrk -t4 -c100 -d30s --latency http://localhost:8000/api/v1/ping

Если для вас критична задержка p99 при большом числе плагинов на запрос — закладывайте отдельный прогон на своём конфиге перед тем, как выбирать шлюз только по архитектуре.

Расширяемость: плагины и кастомная логика

У Kong своя плагинная модель на Lua, с хуками на всех этапах обработки запроса (access, header_filter, body_filter, log и т.д.). Есть готовый маркетплейс плагинов (rate-limiting, key-auth, oauth2, request-transformer, prometheus-exporter и десятки других), а собственный плагин пишется на Lua относительно быстро — если в команде уже есть опыт с NGINX/OpenResty, порог входа низкий.

-- пример минимального кастомного плагина Kong (handler.lua)
local MyPlugin = {}

MyPlugin.PRIORITY = 1000
MyPlugin.VERSION = "1.0.0"

function MyPlugin:access(conf)
  kong.service.request.set_header("X-Custom-Trace", kong.request.get_header("X-Request-Id"))
end

return MyPlugin

Tyk даёт middleware на Go (компилируемое, максимальная производительность, но дольше цикл разработки — нужна пересборка), а также «облегчённые» варианты на JavaScript (через движок Otto/Goja, встроенный в гейтвей) и через gRPC/Python-плагины в enterprise-версии. Для команд, где основной стек — Go, кастомная логика в Tyk пишется естественно и без переключения на другой язык, что для Go-ориентированных бэкенд-команд может быть решающим плюсом.

Итого: если ваша инфраструктура и так на NGINX/Lua или вы просто хотите готовые плагины без написания кода — Kong удобнее. Если у вас Go-команда и вы планируете много кастомной логики в гейтвее — Tyk ближе к вашему стеку.

Установка и эксплуатация на сервере

Оба гейтвея разворачиваются одинаково легко через Docker Compose, и мы уже разбирали установку каждого по отдельности: Kong Gateway на Ubuntu 24.04 пошагово и Tyk Gateway на Ubuntu 24.04 пошагово, а также готовый docker-compose-файл для Kong: Kong Gateway в Docker Compose.

Минимальный стек в DB-less режиме для Kong:

services:
  kong:
    image: kong:3.9
    environment:
      KONG_DATABASE: "off"
      KONG_DECLARATIVE_CONFIG: /kong/kong.yml
      KONG_PROXY_ACCESS_LOG: /dev/stdout
      KONG_ADMIN_ACCESS_LOG: /dev/stdout
    volumes:
      - ./kong.yml:/kong/kong.yml
    ports:
      - "8000:8000"
      - "8001:8001"

Минимальный стек для Tyk (gateway + обязательный Redis):

services:
  redis:
    image: redis:7-alpine
    command: redis-server --appendonly yes
  tyk-gateway:
    image: tykio/tyk-gateway:v5.5
    environment:
      TYK_GW_STORAGE_HOST: redis
      TYK_GW_STORAGE_PORT: 6379
    volumes:
      - ./apps:/opt/tyk-gateway/apps
    ports:
      - "8080:8080"
    depends_on:
      - redis

На практике мы фиксируем частые проблемы обеих систем в отдельных разборах: Kong Gateway на сервере — частые ошибки и решения и Tyk Gateway на сервере — частые ошибки и решения. Если рассматриваете альтернативы попроще — стоит также сравнить с более лёгкими reverse-proxy решениями, например Traefik или Nginx Proxy Manager: для задач без сложной API-логики (аутентификация клиентов, квоты по ключам, трансформация запросов) это может оказаться избыточно упрощённым сравнением, но полезным ориентиром по порогу сложности.

Для боевой эксплуатации важно не забыть про обновление образов, ротацию логов и мониторинг самого гейтвея как отдельного сервиса (Prometheus-экспортер есть у обоих). На VPS с SSD и достаточным запасом RAM оба варианта работают предсказуемо; для продакшн-нагрузки закладывайте отдельный сервер под Redis (для Tyk) или под PostgreSQL (для Kong в DB-режиме), не совмещая их с самим гейтвеем на одной машине, если трафик выше среднего.

Когда выбирать Kong, а когда Tyk

Коротко по сценариям:

• Выбирайте Kong, если: у вас уже есть опыт с NGINX/OpenResty; нужен максимально лёгкий DB-less деплой без внешних зависимостей; важен большой готовый каталог плагинов «из коробки»; планируете со временем перейти на управляемый Kong Konnect без миграции конфигов.
• Выбирайте Tyk, если: команда пишет на Go и хочет писать middleware на том же языке; нужен встроенный GraphQL-прокси без доплаты за плагины; важна гибкая multi-tenancy модель организаций из коробки в open source (Tyk изначально проектировался с учётом multi-org сценариев); готовы держать Redis как обязательную часть инфраструктуры.
• Оба варианта избыточны, если у вас 1-2 сервиса без сложной auth-логики — тогда проще обойтись Traefik или обычным NGINX с парой location-блоков, а полноценный API-шлюз подключить позже, когда появится реальная потребность в rate limiting по ключам API и множестве потребителей.

Обе системы одинаково честно работают на обычном VPS — разница не в том, «потянет ли сервер», а в том, какая модель эксплуатации ближе вашей команде и сколько enterprise-функций вам реально нужно уже сейчас, а не «на будущее».

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