Назад к документации

Сравнение api-gateway с аналогами

Методология и результаты нагрузочного теста, на которые ссылается статья «Скорость рынка. Авторизация в комплекте».

Сравнение api-gateway (репозиторий sarnas-it/api-gateway) с четырьмя популярными API gateway / reverse proxy: Traefik, Nginx, Envoy и Kong. Материал описывает методологию нагрузочного теста готового продукта и его результаты; функциональное сравнение приведено в отдельной таблице.

1. Методология бенчмарка

Все пять прокси настроены одинаково: один роут / → backend, без TLS, без дополнительного middleware сверх встроенных дефолтов. Бэкенд — один и тот же для всех (traefik/whoami, отвечает ~200 байтами текста).

  • Хост: Linux, 12 vCPU, 15 GiB RAM, Docker 28.3.2
  • Изоляция: каждый gateway запускался в отдельном контейнере с --cpuset-cpus=0-1 --memory=768m (жёстко 2 ядра + лимит памяти), по одному за раз — без соседей, конкурирующих за CPU
  • Backend: контейнер traefik/whoami, закреплён на ядрах 8-11 (не пересекается с gateway)
  • Нагрузочный клиент: wrk (taskset -c 2-7, тоже не пересекается с gateway и backend по ядрам)
  • Тест 50 соединений (умеренная нагрузка): wrk -t2 -c50 -d15s
  • Тест 300 соединений (высокая конкурентность): wrk -t4 -c300 -d20s
  • Перед каждым тестом — прогрев 5 секунд (не измеряется)
  • Память снималась через docker stats раз в секунду во время обоих тестов

Версии образов: api-gateway (собран из актуального кода репозитория), traefik:v3.1, nginx:1.27-alpine, envoyproxy/envoy:v1.31-latest (--concurrency 2), kong:3.7 (DB-less, KONG_NGINX_WORKER_PROCESSES=2, access-log выключен).

Оговорки:

  • Это proxy-only тест: JWT-валидация, роли, permissions-модуль, rate-limiting и т.д. в конфиге api-gateway выключены, чтобы сравнивать голый reverse-proxy путь. Включение auth добавит накладные расходы только api-gateway — у остальных таких функций из коробки нет, поэтому сравнение «как есть» было бы нечестным.
  • Service discovery — управляющий слой (обнаружение контейнеров по labels через Docker/Podman API), на горячем пути проксирования он не работает, поэтому пропускную способность и память не меняет.
  • Backend отвечает мгновенно (~0 полезной нагрузки) — это тест накладных расходов самого gateway, а не реальной сети или бэкенда.
  • Цифры — из одиночных прогонов, выполненных подряд на одном и том же железе; числа ориентировочные (±10-15% от прогона к прогону), при сравнении стоит опираться на относительные разрывы.

2. Результаты

Пропускная способность (запросов/секунду)

Gateway50 соединений300 соединений
api-gateway23 69025 063
Traefik23 84525 002
Nginx26 41226 748
Envoy24 73725 340
Kong24 62425 076

api-gateway держится в одной лиге с Traefik, Envoy и Kong, отставая от самого быстрого — Nginx — не более чем на ~10%.

Память под нагрузкой (пик, тест на 300 соединений)

GatewayПамять
Nginx12.4 MB
Envoy33.2 MB
api-gateway90.5 MB
Traefik163.4 MB
Kong301.9 MB

Потолок памяти одинаков для всех пяти — 768MB. api-gateway занимает меньше памяти, чем Traefik и Kong, при том что оба уступают ему в возможностях аутентификации.

3. Функциональное сравнение

Возможностьapi-gatewayTraefikNginxEnvoyKong
Path-based роутинг✅ (вручную)
Host-based роутинг (wildcard)✅ (вручную)
JWT-аутентификация «из коробки»✅ (встроено)⚠️ через ForwardAuth/plugin❌ (нужен njs/Lua/сторонний модуль)⚠️ через jwt_authn filter✅ (плагин jwt)
RBAC по ролям из claims✅ (встроено)⚠️ через RBAC filter/OPA⚠️ через плагины ACL/OPA
Rate limiting (per-route, per-IP)✅ (token bucket)✅ (middleware)⚠️ (limit_req)✅ (local/global ratelimit filter)✅ (плагин rate-limiting)
Circuit breaker✅ (встроено, простой)✅ (продвинутый)⚠️ через плагины
Health checks target'ов⚠️ (Plus/сторонние модули)✅ (продвинутые)
Hot reload конфига (без даунтайма)✅ (SIGHUP)✅ (file provider watch)✅ (nginx -s reload)✅ (xDS API)⚠️ (DB-less: reload API)
TLS с авто-сертификатами (ACME)✅ (встроено)✅ (встроено)❌ (нужен certbot снаружи)
Service discovery (Docker/Podman/K8s)✅ (Docker/Podman по labels, встроено)✅ (из коробки)⚠️ (через Ingress Controller)✅ (xDS, Consul, K8s)⚠️ (через K8s Ingress Controller)
Webhook/event publishing (NATS и т.п.)✅ (встроено)⚠️ (access log / tap filter)⚠️ через плагины
Permission-service интеграция с кэшем✅ (встроено, TTL-кэш)
SPA/статику✅ (встроено)⚠️ (через file provider)✅ (основная сила Nginx)
Экосистема плагинов❌ (не нужна — всё встроено)⚠️ (небольшая)⚠️ (модули на этапе компиляции)⚠️ (WASM/Lua filters)✅ (большая)
Admin UI / API⚠️ (нет UI, только /metrics)✅ (dashboard)❌ (если не Plus)✅ (admin endpoint)✅ (Admin API)
gRPC / HTTP2 proxying❌ (не реализовано)✅ (сильная сторона)

4. Выводы

  • Производительность. На одинаковом железе (2 vCPU / 768MB) api-gateway работает на уровне лидеров рынка: отставание от самого быстрого из пяти (Nginx) не превышает ~10%, от Traefik — в пределах погрешности измерений. Катастрофических деградаций под конкурентной нагрузкой нет: на 300 соединениях разница между всеми пятью — в пределах ~7%.
  • Функциональность. api-gateway — единственный из пяти, где JWT-аутентификация, ролевой RBAC по claims, кэшируемая интеграция с permission-service и публикация webhook-событий встроены «из коробки», без плагинов и без внешнего auth-сервиса. Плюс service discovery по labels контейнеров (Docker/Podman) — как у Traefik, но без отдельного auth-сервиса и без плагинного маркетплейса: обнаруженные сервисы дополняют статический конфиг, при конфликте приоритет у статики.
  • Ресурсы. По пиковой памяти api-gateway легче Traefik и Kong (90.5 MB против 163.4 и 301.9 MB под нагрузкой), уступая лишь Nginx и Envoy, у которых нет встроенной авторизации.

Бенкмарк проведён локально на одном железе; методология выше достаточна для воспроизведения на своей машине.