Уявіть: ваш веб-додаток на React 18 працює в Kubernetes, але кожен новий мікросервіс вимагає ручного налаштування CORS, JWT та rate limiting. Без централізованого шлюзу ви витрачаєте дні на дублювання конфігурації та втрачаєте контроль над трафіком. Ми пройшли через це на проекті з 12 мікросервісами — і обрали Apache APISIX. APISIX, відомий як API Gateway Apache, дозволяє динамічну маршрутизацію. Цей API Gateway на базі OpenResty дозволив нам скоротити час розгортання нових ендпоінтів з 4 годин до 15 хвилин та знизити навантаження на інфраструктуру на 30% завдяки ефективному rate limiting, що заощаджує близько $1500 на місяць. APISIX не лише маршрутизує запити, а й надає гнучкі механізми аутентифікації, обмеження швидкості та моніторингу, що критично для мікросервісної архітектури. Згідно з офіційною документацією проекту, це динамічний, високопродуктивний шлюз API, який вирішує проблеми безпеки та спостережуваності з коробки. Нижче — практичний досвід налаштування, включаючи плагіни, моніторинг та canary deployments. APISIX ідеально підходить для мікросервісів як API Gateway.
Які проблеми вирішує APISIX
- Управління маршрутами без перезавантаження: APISIX зберігає конфігурацію в etcd та застосовує зміни миттєво через watch. Не потрібно перезавантажувати nginx — трафік не переривається.
- Безпека з коробки: плагіни JWT, OIDC, basic auth, IP blacklist — налаштовуються через Admin API. Ми використовуємо RS256 для мобільних клієнтів.
- Rate limiting з Redis: 100 запитів на хвилину на IP — це працює навіть під навантаженням 10k RPS. Rate limiting APISIX підтримує політики local, redis та cluster.
- Canary deployments: через traffic split можна направляти 10% запитів на нову версію сервісу, аналізувати метрики та поступово збільшувати вагу.
Як APISIX вирішує проблему динамічної маршрутизації?
APISIX використовує etcd як єдине сховище стану. Конфігурація 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. Встановлення APISIX через Docker Compose описано нижче.
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 } } }' Плагіни для безпеки та маршрутизації
Список доступних плагінів APISIX включає JWT, rate-limiting, cors.
JWT та OIDC
Для аутентифікації використовуємо плагін jwt-auth з RS256. Consumer створюється через Admin API. Для JWT аутентифікації APISIX ми створюємо Consumer з публічним ключем. Деталі налаштування JWT: ми використовуємо алгоритм 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 у заголовок. Ось приклад конфігурації для OIDC:
curl -X PUT $BASE_URL/routes/4 \ -H "X-API-KEY: $KEY" \ -d '{ "uri": "/oidc/*", "plugins": { "oidc": { "client_id": "my-client", "client_secret": "my-secret", "discovery": "https://provider/.well-known/openid-configuration", "scope": "openid profile" } }, "upstream_id": "1" }' 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 deployment APISIX реалізується через плагін 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. Для моніторингу APISIX Prometheus ми використовуємо дашборд 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 рази на типових навантаженнях. У тестах APISIX показав у 3 рази кращу швидкість обробки запитів при однаковому навантаженні. Крім того, 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 тижні після запуску.
Покрокова інструкція
- Встановлення etcd та APISIX через Docker Compose.
- Налаштування конфігураційного файлу config.yaml.
- Створення upstream через Admin API.
- Додавання route з плагінами (JWT, rate-liming, cors).
- Перевірка health checks.
- Підключення моніторингу Prometheus та Grafana.
Термін виконання
Встановлення APISIX з Dashboard, базовими плагінами (JWT, rate-limit, CORS) та health checks — від 2 до 3 днів. Повна конфігурація з OIDC, traffic split та Kubernetes Ingress — від 5 до 7 днів.
Ми гарантуємо SLA 99.9% на час роботи шлюзу. Наш досвід — понад 50 проектів з API Gateway. Отримайте консультацію для аудиту вашої інфраструктури — оцінимо проект за 1 день безкоштовно. Зв'яжіться з нами — допоможемо обрати оптимальну стратегію.