API Gateway vs. Reverse Proxy: различия и сценарии применения

IRC-Mania Die Seite rund um Sicherheit und Programmierung

Internet, Sicherheit , Internet Relay Chat

Gesponsert

API Gateway и Reverse Proxy часто путают, потому что оба компонента размещаются между клиентом и сервером и перенаправляют запросы. Однако они решают разные задачи на разных уровнях абстракции. Если не разобраться в различиях, можно либо добавить слишком много логики в неправильный слой, либо упустить нужный функционал.

Что такое Reverse Proxy?

Reverse Proxy это сервер, который размещается между клиентами и одним или несколькими backend-серверами и перенаправляет входящие запросы на backend. С точки зрения клиента Reverse Proxy выглядит как основной сервер — клиент не знает, какой именно backend-экземпляр обрабатывает запрос.

Слово “Reverse” означает следующее: в отличие от Forward Proxy, который работает на стороне клиента и перенаправляет запросы наружу, Reverse Proxy работает на стороне сервера и принимает запросы извне.

Основные функции Reverse Proxy

• Маршрутизация: перенаправление запросов на разные backend-серверы в зависимости от URL-пути или имени хоста
• Load Balancing: распределение запросов между несколькими backend-экземплярами (Round-Robin, Least-Connections, IP-Hash)
• TLS Termination: завершение SSL/TLS-соединения на прокси, backend общается незашифрованно во внутренней сети
• Кеширование: сохранение в буфере статического контента или ответов API
• Сжатие: сжатие ответов (gzip, brotli) перед отправкой клиенту
• Rate Limiting: простое ограничение количества запросов по IP
• Health Checks: мониторинг backend-серверов и удаление их из пула при отказе

Популярные решения Reverse Proxy

• Nginx: самый распространённый Reverse Proxy, высокопроизводительный, гибко настраивается
• HAProxy: специализирован на Load Balancing, работает на TCP и HTTP уровне
• Apache с mod_proxy: классический веб-сервер с функциональностью прокси
• Traefik: современный облачно-ориентированный Reverse Proxy с автоматической Service Discovery
• Caddy: простой в настройке Reverse Proxy с автоматическим TLS

Что такое API Gateway?

API Gateway это специализированная форма Reverse Proxy, которая предоставляет дополнительные функции, специфичные для API. Он размещается на входе в инфраструктуру API и управляет, защищает и координирует весь трафик API.

Если Reverse Proxy работает на HTTP-уровне (пути, имена хостов, заголовки), то API Gateway работает на уровне API (endpoints, API-ключи, OAuth-токены, quotas, версии API).

Основные функции API Gateway (помимо Reverse Proxy)

• Аутентификация и авторизация: OAuth 2.0, валидация JWT, проверка API-ключей на каждом endpoint
• Rate Limiting для API: quotas по API-ключу, по пользователю, по endpoint, не просто по IP
• Трансформация запросов и ответов: преобразование payload, добавление заголовков, маппирование версий
• Версионирование API: маршрутизация /v1/users и /v2/users на разные backend или версии
• Агрегация запросов: объединение нескольких backend-вызовов в один ответ на запрос клиента (API Composition)
• Трансляция протоколов: REST в gRPC, SOAP в REST, WebSocket в HTTP
• Аналитика и мониторинг API: детальные метрики по endpoint, по consumer, по API
• Интеграция с Developer Portal: документация API, self-service регистрация, управление ключами
• Circuit Breaker: при отказе backend автоматически отправляет ошибку вместо ожидания timeout
• Mocking: mock-endpoints для разработки и тестирования

Популярные решения API Gateway

• Kong: Open-Source API Gateway с системой плагинов, основан на Nginx/OpenResty
• AWS API Gateway: облачное решение, глубоко интегрировано в экосистему AWS
• Apigee: управление API от Google Cloud, ориентирован на Enterprise
• Tyk: Open-Source, лёгкий, написан на Go
• KrakenD: высокопроизводительный API Gateway с фокусом на агрегацию
• Azure API Management: облачное решение от Microsoft с Developer Portal

Главное различие

Различие можно свести к простой формуле:

Reverse Proxy = инфраструктурный слой (HTTP, TCP, маршрутизация, Load Balancing) API Gateway = слой API (endpoints, аутентификация, quotas, трансформация, аналитика)

Reverse Proxy спрашивает: Какой сервер должен обработать этот запрос? API Gateway спрашивает: Авторизован ли этот клиент вызывать этот endpoint, и сколько он может ещё запросить сегодня?

Таблица сравнения

Кто использует что?

• Reverse Proxy: системные администраторы, DevOps-инженеры, которые хотят распределять трафик и централизовать TLS
• API Gateway: API-команды, Platform-команды, которые управляют, защищают и монетизируют API

Почему это важно в IT и для экзаменов?

На архитектурных экзаменах и сертификациях (AWS Solutions Architect, Azure API Management) регулярно спрашивают о различиях. На практике незнание приводит к архитектурным ошибкам: логику аутентификации втискивают в Reverse Proxy (где ей не место), или API Gateway используют как простой Load Balancer (пустая трата функциональности). Правильное разделение ответственности показывает архитектурную зрелость.

Почему это важно на практике?

Сценарий 1: архитектура Microservices

В архитектуре Microservices с 20 сервисами нужны оба компонента: Reverse Proxy (например, Nginx/Envoy) для Load Balancing и TLS внутри кластера, и API Gateway (например, Kong) как публичный вход для внешних клиентов с аутентификацией, quotas и версионированием.

Сценарий 2: монолит с API

Отдельный backend-сервер с REST API часто нужно защитить Reverse Proxy (Nginx) для TLS и кеширования. API Gateway здесь был бы over-engineering.

Сценарий 3: платформа с несколькими клиентами

Платформа с web-приложением, мобильным приложением и B2B API-клиентами нуждается в API Gateway, так как каждый тип клиента требует разные методы аутентификации, quotas и поля. Reverse Proxy здесь недостаточно.

Практический пример: Nginx как Reverse Proxy vs. Kong как API Gateway

Этот пример показывает одну и ту же задачу — защита endpoint /users — сначала с Nginx как Reverse Proxy, потом с Kong как API Gateway. Сравнение наглядно демонстрирует различие в уровне абстракции и функциональности.

Nginx как Reverse Proxy

# nginx.conf — конфигурация Reverse Proxy
# Перенаправляет запросы на backend-серверы, с TLS и Rate Limiting

upstream backend {
    server 10.0.0.1:3000;
    server 10.0.0.2:3000;
    # Load Balancing: Round-Robin (по умолчанию)
    # Least-Connections: least_conn;
    # IP-Hash (Session-Stickiness): ip_hash;
}

# Rate Limiting Zone: 10 запросов в секунду по IP
limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;

server {
    listen 443 ssl;
    server_name api.example.com;

    # TLS Termination
    ssl_certificate /etc/ssl/certs/api.crt;
    ssl_certificate_key /etc/ssl/private/api.key;
    ssl_protocols TLSv1.2 TLSv1.3;

    # /users -> Backend
    location /users {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://backend;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    # /orders -> другой backend-сервер
    location /orders {
        limit_req zone=api burst=20 nodelay;
        proxy_pass http://10.0.0.3:3001;
        proxy_set_header Host $host;
    }

    # Health Check Endpoint
    location /health {
        return 200 "OK";
        add_header Content-Type text/plain;
    }
}

Kong как API Gateway

# kong.yml — Декларативная конфигурация
# Определяет сервисы, маршруты и плагины (Auth, Rate Limiting, Analytics)

services:
  - name: user-service
    url: http://10.0.0.1:3000
    routes:
      - name: users-route
        paths:
          - /users
        methods:
          - GET
          - POST
          - PUT
          - DELETE
        # API-версионирование через заголовки
        strip_path: false

  - name: order-service
    url: http://10.0.0.3:3001
    routes:
      - name: orders-route
        paths:
          - /orders
        methods:
          - GET
          - POST

plugins:
  # JWT-аутентификация для всех маршрутов
  - name: jwt
    config:
      secret_is_base64: false
      run_on_preflight: true

  # Rate Limiting на consumer (не только по IP)
  - name: rate-limiting
    config:
      minute: 100
      hour: 1000
      policy: redis
      redis_host: redis.internal
      limit_by: consumer
      fault_tolerant: true

  # CORS конфигурация
  - name: cors
    config:
      origins:
        - https://app.example.com
      methods:
        - GET
        - POST
        - PUT
        - DELETE
      headers:
        - Authorization
        - Content-Type
      credentials: true

  # Prometheus метрики для API Analytics
  - name: prometheus
    config:
      per_consumer: true

consumers:
  - username: mobile-app
    jwt_secrets:
      - key: mobile-app-key
        secret: mobile-app-secret-2026
  - username: web-app
    jwt_secrets:
      - key: web-app-key
        secret: web-app-secret-2026

Разница заметна сразу: Nginx настраивает HTTP-маршрутизацию и ограничение частоты по IP. Kong настраивает маршрутизацию API с JWT-аутентификацией, лимитированием по consumer, CORS и метриками — всё декларативно, для каждого API-endpoint.

Подробная информация

Может ли API Gateway заменить Reverse Proxy?

Да и нет одновременно. API Gateway вроде Kong часто сам построен на базе Reverse Proxy (Kong использует Nginx/OpenResty под капотом). Он предоставляет все функции Reverse Proxy плюс API-функции. В большинстве архитектур API Gateway заменяет Reverse Proxy для внешнего трафика. Внутри системы, между микросервисами, часто остаётся отдельный Reverse Proxy или Service Mesh (Envoy, Linkerd).

Когда хватает Reverse Proxy?

• Единая API или монолитное приложение
• Мало endpoint’ов, без версионирования API
• Аутентификация реализована в самом бэкенде (центральная аутентификация не требуется)
• Нет разных квот для разных клиентов
• Небольшая команда, ограниченная инфраструктура

Когда нужен API Gateway?

• Несколько API или микросервисов за одним входом
• Центральная аутентификация (OAuth, JWT) для всех API
• Разные квоты и лимиты частоты для разных клиентов/API
• Версионирование и миграция API
• Aggreation запросов (один запрос клиента -> несколько запросов в бэкенд)
• API-аналитика и монетизация
• Developer Portal для самообслуживания

Reverse Proxy vs. Load Balancer vs. API Gateway

Эти три термина часто путают:

• Load Balancer: распределяет трафик на несколько серверов (Layer 4, TCP/UDP). Фокус на доступности. Примеры: HAProxy, AWS ALB.
• Reverse Proxy: маршрутизирует HTTP-запросы, TLS, кэширование (Layer 7). Фокус на инфраструктуру. Примеры: Nginx, Caddy.
• API Gateway: Reverse Proxy плюс функции управления API. Фокус на API-governance. Примеры: Kong, AWS API Gateway.

Load Balancer может быть частью Reverse Proxy. Reverse Proxy может быть частью API Gateway. Уровень абстракции растёт от LB к RP к AG.

Service Mesh vs. API Gateway

Service Mesh (Istio, Linkerd) управляет коммуникацией между микросервисами внутри системы, тогда как API Gateway управляет внешним трафиком. В современных архитектурах оба существуют одновременно: API Gateway снаружи, Service Mesh изнутри. Envoy может выполнять обе роли.

FAQ: API Gateway vs. Reverse Proxy

Продолжение обучения API

Следующий материал посвящён защите API Gateway — как централизованно настроить аутентификацию, Rate Limiting и защиту от угроз на уровне API Gateway.

Источники и дополнительные материалы

1. https://nginx.org/en/docs/
2. https://docs.konghq.com/
3. https://learn.microsoft.com/en-us/azure/api-management/
4. https://docs.aws.amazon.com/apigateway/
5. https://www.martinfowler.com/articles/richardson-maturity-model.html

Рекомендуемые книги по разработке API

Premium VPS Hosting

Schnelle und sichere VPS Server

Gesponsert