Представьте: ваше веб-приложение на React 18 работает в Kubernetes, но каждый новый микросервис требует ручной настройки CORS, JWT и rate limiting. Без централизованного шлюза вы тратите дни на дублирование конфигурации и теряете контроль над трафиком. Мы прошли через это на проекте с 12 микросервисами — и выбрали Apache APISIX. Этот API Gateway на базе OpenResty позволил нам сократить время развёртывания новых эндпоинтов с 4 часов до 15 минут и снизить нагрузку на инфраструктуру на 30% за счёт эффективного rate limiting. APISIX не только маршрутизирует запросы, но и предоставляет гибкие механизмы аутентификации, ограничения скорости и мониторинга, что критично для микросервисной архитектуры. Согласно официальной документации проекта, это динамический, высокопроизводительный шлюз API, который решает проблемы безопасности и наблюдаемости из коробки. Ниже — практический опыт настройки, включая плагины, мониторинг и canary deployments.
Какие проблемы решает APISIX
- Управление маршрутами без перезагрузки: APISIX хранит конфигурацию в etcd и применяет изменения мгновенно через watch. Не нужно перезагружать nginx — трафик не прерывается.
- Безопасность из коробки: плагины JWT, OIDC, basic auth, IP blacklist — настраиваются через Admin API. Мы используем RS256 для мобильных клиентов.
- Rate limiting с Redis: 100 запросов в минуту на IP — это работает даже под нагрузкой 10k RPS.
- Canary deployments: через traffic split можно направлять 10% запросов на новую версию сервиса, анализировать метрики и постепенно увеличивать вес.
Как APISIX решает проблему динамической маршрутизации?
APISIX использует etcd как единое хранилище состояния. При каждом изменении маршрута через Admin API или Dashboard, etcd автоматически распространяет обновление на все узлы кластера. Это позволяет добавлять и изменять маршруты без downtime. В отличие от статической конфигурации nginx, APISIX поддерживает гибкие условия маршрутизации: по URI, методам, заголовкам, query-параметрам и даже по IP-диапазонам.
Архитектура и установка
Client → APISIX Gateway (nginx/OpenResty) → Upstream Services
↕
ETCD (config store)
↕
APISIX Dashboard
ETCD обязателен — именно в нём хранится вся конфигурация (routes, upstreams, plugins). Изменения применяются в реальном времени через watch.
Docker Compose
version: '3.8'
services:
etcd:
image: bitnami/etcd:3.5
environment:
ALLOW_NONE_AUTHENTICATION: "yes"
ETCD_ADVERTISE_CLIENT_URLS: http://etcd:2379
ETCD_LISTEN_CLIENT_URLS: http://0.0.0.0:2379
apisix:
image: apache/apisix:3.9.1-debian
volumes:
- ./apisix_conf/config.yaml:/usr/local/apisix/conf/config.yaml
ports:
- "9080:9080" # HTTP
- "9443:9443" # HTTPS
- "9180:9180" # Admin API
- "9091:9091" # Prometheus metrics
depends_on: [etcd]
apisix-dashboard:
image: apache/apisix-dashboard:3.0.1-alpine
volumes:
- ./dashboard_conf/conf.yaml:/usr/local/apisix-dashboard/conf/conf.yaml
ports:
- "9000:9000"
depends_on: [etcd]
Создание Route через Admin API
BASE_URL="http://localhost:9180/apisix/admin"
KEY="supersecret-admin-key"
# Создать upstream
curl -X PUT $BASE_URL/upstreams/1 \
-H "X-API-KEY: $KEY" \
-H "Content-Type: application/json" \
-d '{
"type": "roundrobin",
"nodes": {
"users-service:3000": 1,
"users-service-2:3000": 1
},
"checks": {
"active": {
"http_path": "/health",
"interval": 5,
"healthy": { "successes": 2 },
"unhealthy": { "http_failures": 3 }
}
}
}'
# Создать route с JWT и rate limiting
curl -X PUT $BASE_URL/routes/1 \
-H "X-API-KEY: $KEY" \
-H "Content-Type: application/json" \
-d '{
"uri": "/api/v1/users/*",
"methods": ["GET", "POST", "PUT", "DELETE"],
"upstream_id": "1",
"plugins": {
"jwt-auth": {},
"rate-limiting": {
"count": 100,
"time_window": 60,
"key": "remote_addr",
"policy": "redis",
"redis_host": "redis",
"redis_port": 6379
},
"cors": {
"allow_origins": "https://app.company.com",
"allow_methods": "GET,POST,PUT,DELETE",
"allow_headers": "Authorization,Content-Type",
"allow_credential": true
}
}
}'
Плагины для безопасности и маршрутизации
JWT и OIDC
Для аутентификации используем плагин jwt-auth с RS256. Consumer создаётся через Admin API:
curl -X PUT $BASE_URL/consumers/mobile-app \
-H "X-API-KEY: $KEY" \
-d '{
"username": "mobile-app",
"plugins": {
"jwt-auth": {
"key": "mobile-app-key",
"algorithm": "RS256",
"public_key": "-----BEGIN PUBLIC KEY-----\n..."
}
}
}'
Для OpenID Connect (OIDC) настройка чуть сложнее: требуется указать discovery endpoint, client_id и client_secret. Плагин поддерживает RS256 и автоматически пробрасывает access token в заголовок.
Serverless и canary
Serverless-плагин позволяет выполнять кастомную Lua-логику на фазах rewrite или access. Например, добавить заголовок tenant ID:
curl -X PUT $BASE_URL/routes/2 \
-H "X-API-KEY: $KEY" \
-d '{
"uri": "/api/v1/transformed",
"upstream_id": "1",
"plugins": {
"serverless-pre-function": {
"phase": "rewrite",
"functions": [
"return function(conf, ctx)\n local headers = ngx.req.get_headers()\n ngx.req.set_header(\"X-Tenant-ID\", headers[\"X-User-Tenant\"])\n ngx.req.set_header(\"X-Internal-Key\", \"secret\")\nend"
]
}
}
}'
Canary deployments реализуются через traffic-split: например, 10% на новую версию, при совпадении заголовка x-canary: true — 100% на старую. Это позволяет безопасно тестировать релизы.
Как настроить canary deployment в APISIX?
Для canary deployment используем плагин traffic-split. Пример конфигурации: 10% запросов направляются на новую версию (upstream с тегом canary). При получении заголовка x-canary: true трафик полностью идёт на старую версию. Плагин prometheus собирает метрики — при стабильной работе долю новой версии увеличивают. Ниже — фрагмент конфигурации route:
curl -X PUT $BASE_URL/routes/3 \
-H "X-API-KEY: $KEY" \
-d '{
"uri": "/api/v2/users/*",
"plugins": {
"traffic-split": {
"rules": [
{
"weighted_upstreams": [
{ "upstream_id": 1, "weight": 90 },
{ "upstream": { "type": "roundrobin", "nodes": { "users-v2:3000": 1 } }, "weight": 10 }
]
}
]
}
}
}'
Мониторинг и сравнение с Kong
Prometheus метрики APISIX экспортируются на порт 9091. Официальная документация включает пример конфигурации. Для Grafana используйте дашборд ID 11719.
| Критерий | APISIX | Kong |
|---|---|---|
| Производительность (RPS) | 100k+ на одном узле | 50k+ |
| Конфигурация | etcd (live) | PostgreSQL/CRI |
| Плагины | 80+ built-in | 200+ (с платными) |
| Kubernetes Ingress | Да, через Ingress Controller | Да, через KIC |
| Community | Apache проект, активный | Open-source + Enterprise |
APISIX превосходит Kong по производительности примерно в 2 раза на типовых нагрузках. Кроме того, etcd обеспечивает более быструю динамическую конфигурацию по сравнению с PostgreSQL. Для high-load проектов с десятками маршрутов APISIX — более эффективный выбор.
Процесс работы в таблице
| Этап | Длительность | Результат |
|---|---|---|
| Аналитика | 1 день | Схема маршрутов и upstreams |
| Проектирование | 1 день | Документация конфигурации |
| Реализация | 2-3 дня | Рабочий шлюз в staging |
| Тестирование | 1 день | Отчёт нагрузочного тестирования (k6) |
| Деплой | 1 день | Продакшн с canary deployment |
Что входит в работу и сроки
- Аудит текущей инфраструктуры и выбор схемы маршрутизации.
- Развёртывание APISIX с ETCD и Dashboard.
- Настройка плагинов: JWT, rate-limit, CORS, OIDC, serverless.
- Интеграция с Prometheus и Grafana.
- Документация по маршрутам и плагинам.
- Обучение команды: 2-часовой воркшоп.
- Поддержка 2 недели после запуска.
Срок выполнения
Установка APISIX с Dashboard, базовыми плагинами (JWT, rate-limit, CORS) и health checks — от 2 до 3 дней. Полная конфигурация с OIDC, traffic split и Kubernetes Ingress — от 5 до 7 дней.
Мы гарантируем SLA 99.9% на время работы шлюза. Наш опыт — более 50 проектов с API Gateway. Получите консультацию для аудита вашей инфраструктуры — оценим проект за 1 день бесплатно. Свяжитесь с нами — поможем выбрать оптимальную стратегию.