Налаштування Apache APISIX як API Gateway для мікросервісів

Налаштування Apache APISIX як API Gateway для мікросервісів

Ми постійно стикаємося з ситуацією, коли мікросервісна архітектура розростається, а звичайний Nginx або HAProxy перестають справлятися з динамічною маршрутизацією. Багаторічний досвід з API-шлюзами показав: Apache APISIX — найкраще рішення для гнучкого керування трафіком без простоїв. Гарантуємо, що після налаштування ви забудете про ручні правки конфігів і простій при кожному деплої.

APISIX — високопродуктивний API gateway на базі OpenResty (Nginx + LuaJIT) з etcd як сховищем конфігурації. Його головна відмінність від Kong та інших рішень — конфігурація застосовується без перезавантаження, а latency на зміну роутів вимірюється мілісекундами. Для динамічних мікросервісних середовищ, де деплої відбуваються десятки разів на день, це суттєво. Наші інженери сертифіковані та налаштували APISIX на проектах з навантаженням 50 000 RPS.

Чому Apache APISIX швидший за інші API Gateway?

APISIX у 2 рази швидший за Kong у сценаріях частого оновлення маршрутів завдяки etcd та hot-reload плагінів. Плагіни виконуються на LuaJIT без перемикання контексту. Це дає latency близько 1 мс на запит навіть з десятком активних плагінів. Для високонавантажених систем — критично.

Архітектура та компоненти

APISIX складається з трьох ключових частин: data plane (обробка трафіку), control plane (Admin API + Dashboard) та etcd (зберігання конфігурації). У production-середовищі data plane розгортається як мінімум у двох екземплярах за load balancer, control plane ізолюється від зовнішнього доступу. Etcd-кластер повинен включати не менше трьох реплік для відмовостійкості та швидкої консистентності.

Kubernetes-деплой через Helm:

helm repo add apisix https://charts.apiseven.com
helm repo update
helm install apisix apisix/apisix \
  --namespace ingress-apisix \
  --create-namespace \
  --set gateway.type=LoadBalancer \
  --set ingress-controller.enabled=true \
  --set etcd.replicaCount=3 \
  --set apisix.replicaCount=2

Після встановлення Admin API доступний на 9180/tcp — тільки всередині кластера. Ніколи не виставляємо його назовні.

Роутинг та upstream-конфігурація

Створення upstream та route через Admin API:

# Upstream — пул бекендів
curl -X PUT http://apisix:9180/apisix/admin/upstreams/1 \
    -H "X-API-KEY: $ADMIN_KEY" \
    -d '{
        "type": "roundrobin",
        "nodes": {
            "orders-svc.default.svc.cluster.local:8080": 1,
            "orders-svc-v2.default.svc.cluster.local:8080": 1
        },
        "checks": {
            "active": {
                "http_path": "/health",
                "interval": 5,
                "successes": 2,
                "http_failures": 3
            }
        }
    }'

# Route — правило матчингу трафіку
curl -X PUT http://apisix:9180/apisix/admin/routes/1 \
    -H "X-API-KEY: $ADMIN_KEY" \
    -d '{
        "uri": "/api/v1/orders/*",
        "host": "api.example.com",
        "upstream_id": 1,
        "plugins": {
            "rate-limiting": {
                "count": 1000,
                "time_window": 60,
                "key": "consumer_name"
            },
            "jwt-auth": {},
            "prometheus": {}
        }
    }'

Health checks вбудовані в upstream — APISIX автоматично виключає нездорові ноди з балансування. Це критично при rolling deploy: поки новий pod ще не пройшов readiness probe, старі ноди приймають трафік.

Плагінна архітектура

Сила APISIX — у плагінах. З коробки: аутентифікація (JWT, OAuth 2.0, API key, LDAP), rate limiting з кількома стратегіями (consumer, IP, service), трансформація запитів/відповідей, circuit breaker, трасування через OpenTelemetry та Zipkin, метрики для Prometheus.

Приклад конфігурації circuit breaker для захисту від каскадних відмов:

"api-breaker": {
  "break_response_code": 503,
  "max_breaker_sec": 30,
  "unhealthy": {
    "http_statuses": [500, 502, 503],
    "failures": 5
  },
  "healthy": {
    "http_statuses": [200],
    "successes": 3
  }
}

П'ять помилок поспіль — circuit відкривається, запити отримують 503 без звернення до бекенду. Три успішні відповіді після таймауту — circuit закривається. Бекенд-сервіс отримує час відновитися.

Кастомні плагіни пишуться на Lua або через plugin runner на Go/Python/Java. Це відрізняє APISIX від рішень, де розширення потребує форку коду.

Як налаштувати канаркове розгортання з APISIX?

У Kubernetes-середовищі конфігурація через CRD органічніша за прямі API-виклики:

---
apiVersion: apisix.apache.org/v2
kind: ApisixRoute
metadata:
  name: orders-route
spec:
  http:
    - name: orders
      match:
        hosts:
          - api.example.com
        paths:
          - /api/v1/orders/*
      backends:
        - serviceName: orders-svc
          servicePort: 8080
          weight: 90
        - serviceName: orders-svc-v2
          servicePort: 8080
          weight: 10
      plugins:
        - name: jwt-auth
          enable: true
        - name: prometheus
          enable: true

Canary 10%/90% між версіями сервісу керується через weight — жодних ручних змін при поступовому викочуванні нової версії.

Як APISIX масштабується під навантаження?

Data plane APISIX горизонтально масштабується за рахунок додавання реплік за load balancer. Для динамічного масштабування в Kubernetes використовуємо HPA за метриками CPU або RPS. Etcd-кластер також масштабується — рекомендуємо 3, 5 або 7 вузлів залежно від навантаження. При зростанні кількості роутів (до 5000+) etcd зберігає стабільну продуктивність.

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

Оцінимо ваш проект. В рамках налаштування під ключ:

• Проектування топології: кількість data plane реплік, ізоляція control plane, схема зберігання конфігурації в etcd.
• Встановлення в Kubernetes або bare metal.
• Міграція існуючих nginx/HAProxy правил в APISIX-конфігурацію.
• Налаштування аутентифікації, rate limiting та спостережуваності (Prometheus + Grafana dashboard).
• Тестування під навантаженням з імітацією failover.
• Документація адміністративних процедур.

Вартість розраховується індивідуально після аудиту. Напишіть нам — отримайте консультацію по вашому проекту. Замовте аудит вашої інфраструктури — визначимо вузькі місця та підберемо оптимальну конфігурацію. 5+ років досвіду з APISIX та 30+ впроваджень гарантують результат.