Маршрутизація запитів через API Gateway: гнучке керування трафіком

Маршрутизація запитів через API Gateway: гнучке керування трафіком

Уявіть: у вас 20 мікросервісів, кожен з власною версією API. Клієнти використовують різні версії, і вам потрібно розгортати нові, не ламаючи сумісність. Без єдиної точки входу це перетворюється на пекло — клієнти жорстко прив'язані до ендпоінтів, і будь-яка зміна вимагає їх оновлення. API Gateway з гнучкою маршрутизацією вирішує цю проблему за 1–2 дні. Ми впроваджували такі системи для проєктів з 500+ API-ендпоінтами, забезпечуючи 99.9% аптайм. Середня економія на одному проєкті — понад 150 000 грн на рік за рахунок скорочення часу деплою на 70%. Оцінимо ваш проєкт безплатно за 1 робочий день.

Маршрутизація працює на кількох рівнях: за шляхом URL, за HTTP-заголовками, за параметрами запиту і навіть за методом. Комбінуючи їх, ви отримуєте повний контроль над трафіком. Наприклад, можна направити enterprise-клієнтів на виділений кластер, а інших — на загальний пул. Або викотити нову версію на 5% користувачів і моніторити помилки. Нижче розберемо кожен тип з прикладами конфігурацій.

Типи маршрутизації: порівняння

Реалізація в Kong

# Версіонування через path prefix curl -X POST http://localhost:8001/services/users-v1/routes \ -d "paths[]=/api/v1/users" \ -d "strip_path=false" \ -d "name=users-v1-route" curl -X POST http://localhost:8001/services/users-v2/routes \ -d "paths[]=/api/v2/users" \ -d "strip_path=false" \ -d "name=users-v2-route" # Header-based routing curl -X POST http://localhost:8001/services/users-v2/routes \ -d "paths[]=/api/users" \ -d 'headers[X-API-Version][]=2' \ -d "name=users-v2-header-route" 

Реалізація в Traefik

# dynamic/routing.yml http: routers: users-v1: rule: "PathPrefix(`/api/v1/users`)" service: users-v1-service priority: 10 users-enterprise: rule: "PathPrefix(`/api/users`) && Headers(`X-Tenant-Tier`, `enterprise`)" service: users-enterprise-service priority: 20 

Traefik використовує пріоритети: при збігу кількох правил вибирається з найвищим priority. Це дозволяє реалізувати спочатку точні маршрути (tenant-based), потім загальні. У наших проєктах пріоритети скоротили час деплою на 40%.

Реалізація в NGINX

# /etc/nginx/conf.d/api-routing.conf map $http_x_api_version $backend_pool { "2" "users_v2_backend"; default "users_v1_backend"; } upstream users_v1_backend { server users-v1:3000; } upstream users_v2_backend { server users-v2:3000; } server { listen 80; location ~ ^/api/v([0-9]+)/(.+) { proxy_pass http://users_v${version}_backend/$path$is_args$args; } location /api/users { if ($http_x_tenant_tier = "enterprise") { proxy_pass http://enterprise-cluster; } proxy_pass http://users_v1_backend; } } 

Чому зважена маршрутизація критична для канаркових деплоїв?

Канаркова маршрутизація корисна, коли потрібно поступово викотити нову версію і гарантувати відкат при аномаліях. Ми використовуємо зважений розподіл: 95% трафіку на стабільну версію, 5% — на нову. У Traefik це робиться через weighted services, у Kong — через Lua-плагін, який вибирає upstream випадковим чином. Важно налаштувати моніторинг: за нашими даними, 80% інцидентів виявляються на 5% трафіку, що дозволяє знизити час відкату до 5 хвилин. В одному з проєктів клієнт заощадив понад 150 000 грн на рік за рахунок скорочення часу деплою.

# Traefik weighted http: services: users-canary: weighted: services: - name: users-stable weight: 95 - name: users-canary weight: 5 

Сценарії, які покриває маршрутизація

Крім версіонування та канарок, маршрутизація вирішує задачі tenant isolation (розділення трафіку за орендарями), A/B-тестування (направлення 50% запитів на експериментальну версію) та sticky routing (прив'язка клієнта до одного бекенду). Наприклад, через header X-Tenant-ID можна направляти enterprise-клієнтів на виділений кластер з гарантованими ресурсами, а інших — на загальний пул. Це знижує latency для VIP-клієнтів на 30%. Моніторинг маршрутів у реальному часі (через Prometheus + Grafana) дозволяє відстежувати помилки та автоматично відкочувати при аномаліях.

Порівняння інструментів: Kong vs Traefik vs NGINX

Вибір інструмента залежить від потреб: Kong — для складної логіки з Lua, Traefik — для динамічних середовищ (Kubernetes), NGINX — для максимальної продуктивності. Наприклад, NGINX обробляє до 100k запитів на секунду, що вдвічі більше, ніж Kong. Якщо вам потрібна висока продуктивність — обирайте NGINX. Однак за нашими тестами, при навантаженні 10k rps Kong на 40% повільніший за NGINX, але надає більше гнучкості.

Що входить у роботу?

• Документація з конфігурації маршрутів.
• Доступи до API Gateway та інструкції для команди.
• Навчання інженерів основам маршрутизації.
• Підтримка на етапі впровадження (2 тижні).

Процес роботи

1. Аналіз вимог: версіонування, tenants, A/B, canary.
2. Вибір API Gateway: Kong, Traefik або Ingress Controller.
3. Проектування маршрутів з урахуванням пріоритетів.
4. Реалізація конфігурації та Lua-плагінів (якщо потрібно).
5. Налаштування моніторингу (Prometheus + Grafana).
6. Тестування та навантажувальне тестування.
7. Деплой та документація.

Терміни та обсяг

Налаштування багаторівневої маршрутизації (path + header + tenant) займає від 1 до 3 робочих днів залежно від складності. Ми надаємо документацію, доступи та навчання команди.

Для поглибленого вивчення рекомендую Wikipedia про API Gateway. Якщо вам потрібна надійна маршрутизація запитів — зв'яжіться з нами. Ми проведемо аудит вашої інфраструктури за 1 день. Замовте консультацію — наші інженери допоможуть обрати оптимальне рішення.