Настройка 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+ внедрений гарантируют результат.