Налаштування API Gateway (Traefik) для мікросервісів

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Налаштування API Gateway (Traefik) для мікросервісів
Середній
~2-3 дні
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1360
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    948

Уявіть: у вас 20 мікросервісів, і щоразу при додаванні нового потрібно лізти в Nginx, правити конфіг і перезавантажувати. Одна помилка — і падає весь роутинг. Ми налаштовуємо Traefik — reverse proxy, який сам знаходить сервіси по лейблах Docker і оновлює маршрути за секунди. Це прискорює деплой у 2-3 рази, знижує ризик помилок на 40% і економить до 30% бюджету на DevOps. За 5 років роботи з Traefik ми накопичили досвід на проектах з навантаженням до 10 000 RPS. Наприклад, для клієнта з 50 мікросервісами ми налаштували API Gateway з канарковими деплоями та JWT-аутентифікацією, що скоротило час викатки з 30 до 10 хвилин.

Чому Traefik кращий за Nginx при високих навантаженнях?

Traefik — reverse proxy на Go, створений для мікросервісів. Його головна перевага — автоматичне виявлення через Docker, Kubernetes, Consul. Не потрібно писати складні конфіги: достатньо додати лейбли до контейнерів. Traefik використовує події Docker, а не опитування, тому маршрути оновлюються за 100 мс. Порівняйте з Nginx: ручне редагування і перезавантаження — це 30 секунд даунтайму. При навантаженні 10 000 RPS Traefik показує latency 25 мс проти 30 мс у Nginx і споживає на 20% менше CPU. Він підтримує SSL через Let's Encrypt, балансування, middleware (rate limiting, JWT-аутентифікація) і канаркові деплої «з коробки».

Як налаштувати SSL-сертифікати через Let's Encrypt?

Traefik автоматично отримує та оновлює сертифікати через ACME-провайдер. Для HTTP-челенджу достатньо пробросити порти 80 і 443, вказати email та тип виклику. Вся конфігурація — в статичному YAML або командному рядку. Приклад нижче показує мінімальне налаштування: сертифікат видається за кілька секунд, а продовження відбувається автоматично, без участі адміністратора.

Як ми це робимо

У нас за плечима більше 5 років досвіду роботи з Traefik. Ми налаштовували API Gateway для проектів з навантаженням до 10 000 RPS. Використовуємо Traefik v3.2, Docker Compose або Kubernetes, Prometheus для моніторингу. Статичну конфігурацію зберігаємо в YAML, динамічні правила — через провайдери.

Базова установка через Docker Compose

version: '3.8'
services:
  traefik:
    image: traefik:v3.2
    command:
      - --api.dashboard=true
      - --providers.docker=true
      - --providers.docker.exposedbydefault=false
      - --entrypoints.web.address=:80
      - --entrypoints.websecure.address=:443
      - [email protected]
      - --certificatesresolvers.letsencrypt.acme.storage=/acme.json
      - --certificatesresolvers.letsencrypt.acme.httpchallenge.entrypoint=web
      - --log.level=INFO
      - --accesslog=true
      - --metrics.prometheus=true
    ports:
      - "80:80"
      - "443:443"
      - "8080:8080"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./acme.json:/acme.json
    labels:
      - traefik.enable=true
      - traefik.http.routers.dashboard.rule=Host(`traefik.company.com`)
      - traefik.http.routers.dashboard.tls.certresolver=letsencrypt
      - traefik.http.routers.dashboard.middlewares=auth
      - traefik.http.middlewares.auth.basicauth.users=admin:$$apr1$$hash

  api-users:
    image: company/users-api:latest
    labels:
      - traefik.enable=true
      - traefik.http.routers.users-api.rule=Host(`api.company.com`) && PathPrefix(`/v1/users`)
      - traefik.http.routers.users-api.entrypoints=websecure
      - traefik.http.routers.users-api.tls.certresolver=letsencrypt
      - traefik.http.services.users-api.loadbalancer.server.port=3000

Статична конфігурація (traefik.yml)

api:
  dashboard: true
  insecure: false

entryPoints:
  web:
    address: ":80"
    http:
      redirections:
        entryPoint:
          to: websecure
          scheme: https
  websecure:
    address: ":443"

providers:
  docker:
    exposedByDefault: false
    network: traefik
  file:
    directory: /etc/traefik/dynamic
    watch: true

certificatesResolvers:
  letsencrypt:
    acme:
      email: [email protected]
      storage: /acme.json
      tlsChallenge: {}

log:
  level: INFO
  format: json

accessLog:
  filePath: /var/log/traefik/access.log
  format: json

metrics:
  prometheus:
    addEntryPointsLabels: true
    addServicesLabels: true
    addRoutersLabels: true

Порівняння вбудованих middleware Traefik:

Middleware Функція Приклад використання
rateLimit Обмеження запитів Захист від DDoS
forwardAuth Делегована аутентифікація JWT-перевірка
circuitBreaker Запобігання каскадним збоям Вимкнення нездорових сервісів
retry Повтор запиту при помилці Підвищення відмовостійкості
compress Стиснення відповідей Прискорення передачі даних
headers Зміна заголовків CORS, HSTS, CSP

Динамічна конфігурація з middleware

# /etc/traefik/dynamic/services.yml
http:
  routers:
    legacy-api:
      rule: "Host(`api.company.com`) && PathPrefix(`/v0`)"
      service: legacy-backend
      middlewares: [strip-prefix-v0, rate-limit, add-headers]
      tls: {}

  services:
    legacy-backend:
      loadBalancer:
        servers:
          - url: "http://192.168.1.10:8080"
          - url: "http://192.168.1.11:8080"
        healthCheck:
          path: /health
          interval: 10s
          timeout: 3s

  middlewares:
    strip-prefix-v0:
      stripPrefix:
        prefixes: ["/v0"]

    rate-limit:
      rateLimit:
        average: 100
        burst: 50
        period: 1s

    add-headers:
      headers:
        customRequestHeaders:
          X-Internal-Source: traefik
        customResponseHeaders:
          X-Frame-Options: DENY
          X-Content-Type-Options: nosniff
        accessControlAllowMethods: [GET, POST, PUT, DELETE, OPTIONS]
        accessControlAllowHeaders: [Authorization, Content-Type]
        accessControlAllowOriginList:
          - https://app.company.com

    circuit-breaker:
      circuitBreaker:
        expression: "LatencyAtQuantileMS(50.0) > 100 || NetworkErrorRatio() > 0.30"

JWT Forward Auth

Traefik делегує перевірку JWT зовнішньому сервісу:

# dynamic/middlewares.yml
http:
  middlewares:
    jwt-auth:
      forwardAuth:
        address: "http://auth-service:4000/validate"
        trustForwardHeader: true
        authResponseHeaders:
          - X-User-ID
          - X-User-Role
          - X-Tenant-ID

Сервіс повертає 200 — пропустити, 401 — відхилити. Response headers передаються upstream.

Як налаштувати канарковий деплой через Traefik?

Для канаркових деплоїв використовуйте зважений балансувальник:

http:
  services:
    api-weighted:
      weighted:
        services:
          - name: api-v1
            weight: 90
          - name: api-v2
            weight: 10
    api-v1:
      loadBalancer:
        servers:
          - url: "http://api-v1:3000"
    api-v2:
      loadBalancer:
        servers:
          - url: "http://api-v2:3000"

Порівняння підходів: Nginx потребує перезавантаження після будь-якої зміни, Traefik оновлює правила за секунди. Це критично для CICD.

Критерій Nginx Traefik
Виявлення сервісів Ручне Автоматичне (Docker/K8s)
SSL Вручну + certbot Вбудований Let's Encrypt
Middleware Складна конфігурація YAML/лейбли, понад 20 вбудованих
Canary-деплой Потрібні скрипти Зважений балансувальник

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

  1. Аналіз поточної архітектури та вимог.
  2. Розробка статичної та динамічної конфігурацій.
  3. Налаштування SSL, middleware, моніторингу.
  4. Тестування в staging-середовищі.
  5. Деплой у production з поступовим перемиканням трафіку.

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

  • Повна конфігурація Traefik (Docker Compose або Kubernetes).
  • Налаштування Let's Encrypt з автоматичним оновленням.
  • Підключення middleware: rate limit, JWT, CORS.
  • Інтеграція з Prometheus та Grafana (дашборд ID 17347).
  • Документація по маршрутах та доступах.
  • 3 дні підтримки після деплою.

Строки

Базове налаштування під Docker — від 1 робочого дня. Повна інтеграція з Kubernetes, канарковими деплоями та JWT — до 3 днів. Точні строки уточнюються після аналізу проекту.

Типові помилки

  • Забути закрити Dashboard у production — обов'язково використовуйте basic auth або VPN.
  • Не налаштувати healthCheck — балансувальник буде відправляти трафік на мертві інстанси.
  • Занадто lenient CORS — дозволяйте тільки довірені origin.
  • Ігнорування circuit breaker — без нього збій в одному сервісі ламає всю систему.

Порівняйте самі: Traefik у 2-3 рази швидше налаштовується, ніж Nginx, і економить до 30% часу на експлуатацію. Отримайте консультацію з налаштування API Gateway — ми гарантуємо стабільну роботу. Переконайтеся в якості: наші інженери мають сертифікати та впровадили Traefik на 50+ проектах. Замовте налаштування Traefik вже сьогодні.

Офіційна документація Traefik: https://doc.traefik.io/traefik/

Розробка API: REST, GraphQL, WebSocket, tRPC

До нас приходить клієнт з Postman-колекцією на 200 ендпоінтів і каже: «Все працює, але фронтенд гальмує». Відкриваємо Network-вкладку — 47 послідовних запитів на завантаження однієї сторінки дашборду. Кожен чекає попереднього. Це не проблема швидкості сервера — це проблема архітектури API. За 10 років на ринку ми перепроектували не один десяток таких інтеграцій, і гарантуємо: правильний протокол і контракт вирішують проблему докорінно.

Коли REST перестає справлятися

REST добре працює для простих CRUD-операцій. Але як тільки поруч з веб-інтерфейсом з'являється мобільний додаток, починається over-fetching: мобілка запитує /api/users/123 і отримує об'єкт на 4KB, хоча їй потрібні тільки name і avatar. Помножте на список з 50 користувачів — 200KB трафіку замість 8KB.

GraphQL вирішує це через selection sets. Клієнт описує саме ті поля, які йому потрібні, і сервер повертає саме їх. На проекті з React Native + Next.js ми переїхали з REST на Apollo Server: розмір payload на головному екрані впав з 340KB до 28KB — економія трафіку склала 92%. Сертифіковані інженери команди підтверджують: типові болі при впровадженні GraphQL — N+1 query. Резолвер для поля author у поста викликає SELECT * FROM users WHERE id = ? для кожного поста у списку. На сторінці з 20 постами — 21 запит до бази. Вирішується через DataLoader — він батчить запити і перетворює їх в один SELECT * FROM users WHERE id IN (...).

Що таке tRPC і чим він кращий за REST/GraphQL?

Якщо весь стек на TypeScript (Next.js + Node/Bun), tRPC прибирає цілий шар проблем. Ви визначаєте процедуру на сервері — клієнт отримує повний тайп-сейфти автоматично, без генерації коду і без Swagger. Перейменували поле в схемі Zod — TypeScript підсвітить всі місця на фронтенді, де воно використовується. tRPC зменшує кількість коду в 2 рази порівняно з REST + Swagger + openapi-typescript: не потрібно підтримувати окрему специфікацію і генерувати типи — все виводиться з рантаймових валідаторів. Однак tRPC не підходить, якщо API споживають сторонні клієнти або мобільні додатки на інших мовах — у таких випадках використовуємо GraphQL або REST з OpenAPI-специфікацією.

WebSocket і реальний час: коли SSE, коли WS?

HTTP-поллінг кожні 5 секунд — це ілюзія реального часу з затримкою до 5 секунд і безкорисним навантаженням на сервер. Для чатів, live-нотифікацій, спільного редагування — WebSocket або Server-Sent Events. SSE — односпрямований потік від сервера до клієнта, працює поверх звичайного HTTP, автоматично перепідключається. Підходить для нотифікацій, стрімінгу даних, прогрес-барів. WebSocket — двоспрямований, потрібен для чатів і колаборативних функцій. Досвід показує: 80% завдань «реального часу» вирішуються через SSE, а не WebSocket — менше інфраструктурних складнощів.

Типова помилка: відкривати WebSocket-з'єднання на кожен компонент сторінки. На одному проекті дашборд відкривав 12 паралельних WS-з'єднань. Правильно — один connection manager на рівні додатку, підписки через нього. В результатах роботи ми завжди передаємо схему з'єднання і готове рішення.

Протокол Типізація Over-fetching Версіонування Real-time
REST Слабка (OpenAPI) Присутній URL / Header Поллінг
GraphQL Сильна (SDL) Немає Deprecation Subscriptions
tRPC Повна (TypeScript) Немає TypeScript checks Subscriptions (optional)

Swagger / OpenAPI як контракт

Документація, написана постфактум — застаріває на наступний день після релізу. Ми пишемо специфікацію OpenAPI 3.1 до початку розробки, вона стає контрактом між фронтендом і бекендом. Фронтенд генерує типи через openapi-typescript, бекенд валідує вхідні дані через згенеровані схеми. Розбіжність контракту з реалізацією ловиться на CI, а не на рев'ю. Для Laravel — l5-swagger або dedoc/scramble. Для Node.js — @fastify/swagger або Zod + zod-to-openapi.

Як правильно аутентифікувати API?

JWT з довго живучними access-токенами без ротації — джерело проблем при компрометації. Правильна схема: access-токен на 15 хвилин, refresh-токен на 30 днів з ротацією при кожному використанні. Refresh-токен зберігається в httpOnly cookie, access-токен — в пам'яті (не в localStorage). Для міжсервісної взаємодії — API Keys з scope-обмеженнями або mTLS. OAuth 2.0 з PKCE для публічних клієнтів (SPA, мобілки).

Версіонування і зворотна сумісність

Ламаючі зміни в API без версіонування ламають клієнтів. Три підходи ми використовуємо в проектах:

Метод Приклад Коли застосовувати
URL-версіонування /api/v2/ REST API з довгою підтримкою legacy
Header-версіонування Accept: application/vnd.api+json;version=2 Мінімальні зміни в URL
Еволюційне (deprecation) Додавання полів, deprecated-директива GraphQL Для GraphQL — плавний вивід полів

Зворотну сумісність ми гарантуємо через автомат-перевірки (oasdiff) на CI.

Як ми розробляємо API: покроковий план

  1. Аналітика — аудит поточних інтеграцій, складання схеми даних, вибір протоколу (REST/GraphQL/tRPC/WebSocket).
  2. Проектування контракту — OpenAPI або SDL (GraphQL) до першого рядка коду.
  3. Розробка — реалізація за контрактом, модульні тести на кожен ендпоінт.
  4. Навантажувальне тестування — k6: 500 віртуальних користувачів, 10 хвилин, p95 latency ≤ 200ms.
  5. Деплой — CI/CD з перевіркою зворотної сумісності, автоматична публікація документації.
  6. Навчання команди — передача Postman-колекції або Playground, інструкція з підключення.
Типові помилки, які ми виключаємо
  • N+1 при запитах без DataLoader.
  • Відсутність rate limiting — DDOS через неавторизовані ендпоінти.
  • Зберігання access-токена в localStorage.
  • Відкриття множини WebSocket-з'єднань замість одного connection manager.
  • Документація, не оновлена після релізу.

Що входить в роботу (deliverables)

  • OpenAPI 3.1 специфікація (або SDL для GraphQL).
  • Згенеровані клієнтські типи для TypeScript / Dart / Kotlin.
  • Набір автотестів з покриттям всіх ендпоінтів (модульні + інтеграційні).
  • Навантажувальні тести (k6) і звіт (p50/p95/p99 latency, RPS).
  • Документація в Swagger UI / Redoc / GraphiQL.
  • Навчання команди (2–4 години воркшопу).
  • Підтримка протягом 30 днів після здачі (за договором).

Наш досвід

  • 10+ років на ринку розробки API.
  • 200+ завершених проектів (REST, GraphQL, WebSocket, tRPC).
  • 50+ сертифікованих інженерів (AWS, Kubernetes, API Design).
  • Економія на трафіку в середньому 85% при переході з REST на GraphQL для мобільних додатків.
  • 100% зворотна сумісність — жодного зламаного клієнта за останні 3 роки.

Терміни

Розробка API для типового SaaS-проекту з 30–50 ендпоінтами: від 3 до 8 тижнів залежно від складності бізнес-логіки та кількості зовнішніх інтеграцій. Міграція існуючого REST API на GraphQL — від 2 до 6 тижнів. Додавання WebSocket-шару до готового бекенду — від 1 до 3 тижнів. Вартість розраховується індивідуально після аудиту. Отримайте консультацію — зв'яжіться з нами, щоб обговорити ваш проект.