API Gateway Hosting: Microservices richtig aufsetzen

Was ist ein API Gateway?

Ein API Gateway ist ein zentraler Reverse Proxy, der alle API-Requests entgegennimmt und an die richtigen Backend-Services weiterleitet. Statt dass dein Frontend zehn verschiedene Endpunkte direkt aufruft, ruft es einen einzigen Gateway an — der kümmert sich um alles andere.

Das klingt nach Overhead, aber ein Gateway übernimmt eine Menge Arbeit, die du nicht in jedem Microservice einzeln implementieren willst:

• Authentifizierung & Autorisierung — JWT-Validierung, API-Key-Check, OAuth-Token-Austausch
• Rate Limiting — Pro User, pro IP, pro Endpoint begrenzen
• Request-Routing — /users/* an User-Service, /orders/* an Order-Service
• Caching — Häufige Responses aus dem Cache ausliefern
• Protokoll-Transformation — HTTP → gRPC, REST → GraphQL
• Monitoring & Logging — Zentrales Logging, Metriken, Tracing
• SSL-Terminierung — HTTPS nur am Gateway, Backend-Kommunikation unverschlüsselt

Option 1: Nginx als einfaches API Gateway

Für die meisten Setups ist Nginx als leichtgewichtiger Reverse Proxy völlig ausreichend. Kein extra Software-Stack, minimale Konfiguration, maximale Kontrolle.

Typisches Routing-Setup in /etc/nginx/sites-available/api-gateway:

upstream user_service {
    least_conn;
    server 127.0.0.1:3001 max_fails=3 fail_timeout=30s;
}

upstream order_service {
    least_conn;
    server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;
}

upstream product_service {
    least_conn;
    server 127.0.0.1:3003 max_fails=3 fail_timeout=30s;
}

server {
    listen 443 ssl http2;
    server_name api.deine-domain.de;

    ssl_certificate /etc/letsencrypt/live/api.deine-domain.de/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/api.deine-domain.de/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;

    # --- User Service ---
    location /api/v1/users/ {
        proxy_pass http://user_service;
        proxy_http_version 1.1;
        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;
        proxy_set_header Connection "";
        proxy_connect_timeout 5s;
        proxy_read_timeout 30s;
    }

    # --- Order Service ---
    location /api/v1/orders/ {
        proxy_pass http://order_service;
        proxy_http_version 1.1;
        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_read_timeout 60s;  # Orders can be slow
    }

    # --- Product Service ---
    location /api/v1/products/ {
        proxy_pass http://product_service;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;

        # Cache Product-GET-Requests für 5 Minuten
        proxy_cache my_cache;
        proxy_cache_valid 200 5m;
        proxy_cache_key "$scheme$request_method$host$request_uri";
        add_header X-Cache-Status $upstream_cache_status;
    }

    # --- Health Check ---
    location /health {
        access_log off;
        return 200 "OK\n";
        add_header Content-Type text/plain;
    }
}

Rate Limiting mit Nginx

Nginx' limit_req_zone ermöglicht、赵, dass du API-Clients begrenzt:

# Im http-Block:
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=30r/s;
limit_req_zone $http_authorization zone=authenticated:10m rate=100r/s;

server {
    # Standard: 30 Requests/Sekunde pro IP
    location /api/ {
        limit_req zone=api_limit burst=50 nodelay;
        proxy_pass http://backend;
    }

    # Authenticated Users: 100 Requests/Sekunde
    location /api/v1/ {
        limit_req zone=authenticated burst=200 nodelay;
        proxy_pass http://backend;
    }

    # Strenge Limit für Login-Endpunkt
    location /api/v1/auth/login {
        limit_req zone=api_limit burst=5 nodelay;
        proxy_pass http://auth_service;
    }
}

Option 2: Kong Gateway — der Profi-Weg

Kong ist das Open-Source-Standard-Gateway für Microservices. Es bietet alles, was Nginx kann — plus Plugin-Architektur, Admin-API, Dashboard und Service Discovery. Für APIs mit komplexen Anforderungen (komplizierte Auth-Flows, granuläres Rate Limiting, Request-Transformation) ist Kong die bessere Wahl.

Kong auf Ubuntu/Debian installieren

# Repository hinzufügen
sudo apt update
sudo apt install -y apt-transport-https gnupg lsb-release
echo "deb [signed-by=/usr/share/keyrings/kong.gpg] https://download.konghq.com/gateway-3.x/debian bookworm main" | sudo tee /etc/apt/sources.list.d/kong.list

# Kong installieren
sudo apt update
sudo apt install kong

# Konfiguration (kong.conf)
echo "database = off" > /etc/kong/kong.conf.d/kubernetes.conf
echo " declarative = /etc/kong/kong.yml" >> /etc/kong/kong.conf.d/kubernetes.conf

# Starten
kong start

Kong: Services und Routes definieren

# Via Admin API:
# Service registrieren
curl -X POST http://localhost:8001/services/ \\
  --data "name=user-service" \\
  --data "url=http://localhost:3001/" \\
  --data "protocol=http"

# Route zum Service
curl -X POST http://localhost:8001/services/user-service/routes/ \\
  --data "name=user-route" \\
  --data "paths[]=/api/v1/users" \\
  --data "methods[]=GET" \\
  --data "methods[]=POST"

# Rate Limiting Plugin
curl -X POST http://localhost:8001/routes/user-route/plugins/ \\
  --data "name=rate-limiting" \\
  --data "config.minute=100" \\
  --data "config.policy=local"

# JWT-Auth Plugin
curl -X POST http://localhost:8001/routes/user-route/plugins/ \\
  --data "name=jwt" \\
  --data "config.uri_param_names=jwt" \\
  --data "config.cookie_names=jwt"

Authentifizierung am Gateway

Authentifizierung sollte am Gateway passieren — nicht in jedem Microservice. Das zentrale Muster: der Gateway validiert den Token und fügtUser-Informationen als Header hinzu, bevor weitergeleitet wird.

JWT-Validierung mit Nginx

Mit dem nginx-auth-jwt-Modul oder einem Lua-basierten Setup (OpenResty):

# Einfaches JWT-Check via ngx_http_auth_jwt_module (Nginx Plus)
location /api/ {
    auth_jwt "API Access";
    auth_jwt_key_file /etc/nginx/jwt-key.pem;

    # Bei erfolgreicher Validierung: User-ID als Header weiterleiten
    # (requires Nginx Plus oder ngx_http_auth_jwt_module mit Lua fallback)
    proxy_pass http://backend;
}

# Public Endpoints ausschließen
location /api/v1/auth/ {
    auth_jwt off;
    proxy_pass http://auth_service;
}

API-Key-Auth

Für einfachere Fälle: API-Keys. Der Gateway prüft den Key und leitet ihn als Header weiter:

# Nginx: API-Key aus Header lesen und validieren
map $http_x_api_key $api_key_valid {
    "sk_live_abc123" 1;
    "sk_live_def456" 1;
    default 0;
}

server {
    location /api/ {
        if ($api_key_valid = 0) {
            return 401 '{"error": "Invalid API Key"}';
        }
        proxy_set_header X-Api-Key $http_x_api_key;
        proxy_pass http://backend;
    }
}

Caching-Strategien am Gateway

Ein API Gateway kann häufig angefragte Daten cachen und so Backend-Services entlasten. Die Caching-Strategie hängt von der Datenart ab:

Load Balancing: Mehrere Backend-Instanzen

Ein einzelner Backend-Service ist ein Single Point of Failure. Bei mehreren Instanzen verteilt der Gateway die Last:

# Nginx: Round Robin (Standard) - gut genug für die meisten Fälle
upstream backend_cluster {
    least_conn;  # Load Balancing: am wenigsten Verbindungen zuerst
    server 127.0.0.1:3001;
    server 127.0.0.1:3002;
    server 127.0.0.1:3003;
}

server {
    listen 443 ssl http2;
    location /api/ {
        proxy_pass http://backend_cluster;
        # ... proxy_set_header ...
    }
}

# Kong: Health Checks automatisch
# Kong erkennt ungesunde Upstreams und leitet Traffic nur an gesunde weiter

Health Checks konfigurieren

# Nginx: Passive Health Checks
upstream backend_cluster {
    least_conn;
    server 127.0.0.1:3001;
    server 127.0.0.1:3002 max_fails=3 fail_timeout=30s;  # 3 Fehler in 30s = raus
    server 127.0.0.1:3003;
}

# Kong: Aktive Health Checks
# Via Admin API:
curl -X POST http://localhost:8001/health/checks/ \\
  --data "name=user-service-health" \\
  --data "protocol=http" \\
  --data "host=localhost" \\
  --data "port=3001" \\
  --data "path=/health" \\
  --data "interval=10" \\
  --data "timeout=5" \\
  --data "threshold=3"

Logging und Monitoring

Ohne Monitoring weißt du nicht, ob dein API Gateway funktioniert. Die Basics:

• Access Logs — Jeder Request mit Status Code, Latenz, Request-ID. In Elasticsearch oder Loki speichern für spätere Analyse.
• Error Logs — 5xx-Fehler, Gateway-Timeouts, Auth-Fehler.
• Metriken — Request-Rate, Latenz-Perzentile (p50, p95, p99), Error-Rate, Cache-Hit-Rate. Mit Prometheus scrapen und in Grafana visualisieren.
• Tracing — Request-IDs durch alle Services durchreichen. Mit OpenTelemetry oder Jaeger.

# Nginx: Strukturierte Logs im JSON-Format
log_format json_log escape=json '{'
    '"time":"$time_iso8601",'
    '"remote_addr":"$remote_addr",'
    '"request_id":"$http_x_request_id",'
    '"method":"$request_method",'
    '"uri":"$request_uri",'
    '"status":$status,'
    '"latency_ms":$request_time,'
    '"body_bytes":$body_bytes_sent,'
    '"upstream":"$upstream_addr"'
  '}';

access_log /var/log/nginx/api_access.log json_log;

Deployment: Docker + Kubernetes vs. VPS

Die richtige Plattform für dein API Gateway hängt von Skalierungsanforderungen und Komplexität ab:

Fazit: Der Gateway ist der entry point

Ein API Gateway ist kein Nice-to-have — es ist der zentrale Punkt, an dem alle Entscheidungen fallen: Wer darf rein? Wie viele Requests? Was wird gecacht? Wo geht's lang?

Für die meisten Projekte: fang mit Nginx an. Es ist schnell eingerichtet, braucht wenig RAM, und deckt 90 % der Anforderungen ab. Wenn du irgendwann komplexe Auth-Flows, Plugin-basierte Transformation oder granuläres Monitoring brauchst, wechselst du zu Kong. Der Umstieg ist gut dokumentiert.

Das Wichtigste: der Gateway muss genauso redundant sein wie deine Backend-Services. Ein einzelner Gateway-Server ist ein Single Point of Failure —egal wie gut die Backend-Services konfiguriert sind.