API-Gateway und Routing

1) Die Rolle des API-Gateways in der Architektur

• Empfang von eingehendem Datenverkehr (HTTP/HTTP2/HTTP3, WebSocket, gRPC);
• Routing nach Regeln (host/path/headers/method/query/geo/weight/health);
• wendet End-to-End-Richtlinien an: Authentifizierung/Autorisierung, Ratenbegrenzung, WAF, CORS, Caching;
• führt Transformationen durch (Normalisierung von Headern/Körpern, gRPC↔JSON, GraphQL-Stitching);
• bietet Stabilität (Timeouts, Retries, Circuit-Breaker, Outlier Detection);
• gibt Beobachtbarkeit und Abrechnung (Protokolle, Metriken, Traces, Quoten);
• isoliert die interne Topologie (Service Mesh, private Dienste).

Oft im Paar verwendet: Edge/API-Gateway + Ingress/Mesh (Envoy/Istio/Linkerd) - der erste entscheidet über die Außenpolitik, der zweite über Ost-West.

2) Typische Topologien

Ein einziges globales Gateway (CDN/Edge POP → L7 Gateway → Dienste) - einfach, zentralisierte Richtlinien.
Regionale Gateways (per-region) + intelligentes Geo/Latenz-Routing.
Multi-tenant: dedizierte Routen/Subdomains/Schlüssel, Quoten und Limits pro Mieter.
Hybrid: on-prem + cloud, private link/peering, private Backends hinter dem API-Gateway.

3) L7-Routing-Regeln

• Host/Path: `api. example. com` → `/v1/orders/`.
• Headers: `X-Client`, `X-Region`, `User-Agent`, `Accept`.
• Methode/Inhaltstyp: JSON/Proto/GraphQL Unterscheidung.
• Abfrage/Fragment: Vorsicht - beeinflusst Cache/Varianten.
• Geo/Latenz: nächstgelegene RR/Region, Failover bei Degradation.
• Weighted/Canary: Traffic-Verteilung 90/10, 50/50, Sticky per Cookie.
• Sitzungsaffinität: Hash-basiert auf Schlüssel/Token (ordentlich beim Skalieren).

yaml nginx. ingress. kubernetes. io/canary: "true"
nginx. ingress. kubernetes. io/canary-weight: "10" # 10% traffic to new backend

yaml match: { prefix: "/orders", headers: [{name: "X-Experiment", exact_match: "new"}] }
route: { cluster: orders-v2 }

4) Protokolle und Kompatibilität

REST/JSON ist ein Standard, beschreiben Sie OpenAPI für die Validierung/Generierung von Clients.
gRPC - binärer Proto über HTTP/2; für externe Kunden gRPC-JSON transcoding verwenden.
GraphQL - aggregiert Dienste; am Perimeter die Komplexität/Tiefe der Anfragen kontrollieren.
WebSocket/SSE - bidirektional/Push; Berücksichtigen Sie Sticky und Timeouts.
HTTP/2/3 (QUIC) - Multiplexing/Schnellstart; Überprüfen Sie die Kompatibilität mit WAF/Proxy.

5) Sicherheit: Authentifizierung und Autorisierung

5. 1 Transport

TLS 1. 2 + auf Perimeter, HSTS, OCSP Stapling, PFS.
mTLS für B2B/interne APIs und Machine-to-Machine.
IP allowlist/denylist, Geobeschränkungen.

5. 2 Anwendungsebene

OAuth2/OIDC: JWT-Bearer-Token, Signatur-/Verfalls-/Publikumsprüfung.
NMAS/Signaturen: Datum + kanonisierte Zeichenfolge + Signatur (AWS-like) - Schutz vor Ersetzung, Wiederholung (Nonce/Zeitfenster).
API-Schlüssel: nur als Kennung; Rechte - durch RBAC/ABAC/scopes.
CORS: Expliziter Allow-Origin, Pre-Flying-Cache.
WAF: Signaturen (OWASP API Top 10), Anormalität, Bot-Schutz, rekursive JSON-Felder.
DDoS/Missbrauch: Verbindungslimitierung, Token-Bucket/Leaky Bucket, Berst + Durchschnittsgeschwindigkeit, dynamische Verbote.

yaml plugins:
- name: oidc config: { issuer: "...", client_id: "...", client_secret: "...", scopes: ["orders. read"] }
- name: rate-limiting config: { minute: 600, policy: local }

6) Validierung, Transformationen und Kompatibilität

Schemata: Validierung von Body/Header/Parameter nach OpenAPI/JSON-Schema/Protobuf.
Transformationen: Normalisierung von Feldern, Maskierung von PII, Hinzufügen von Korrelationsüberschriften ('traceparent', 'x-request-id').
Versionierung: 'Header: X-API-Version', Präfixe '/v1', Ressourcenversionierung; deprecation policy и Sunset.
Backward-compat: nur Add-Feld; Vermeiden Sie „brechende“ Änderungen ohne neue Version.
Idempotency: `Idempotency-Key` для POST; gateway speichert Schlüssel in Redis mit TTL.

7) Nachhaltigkeit: Verbindungspolitik

Timeouts: connect/read/write; angemessene Ausfälle (z. B. 1s/5s/5s).
Retries: nur für sichere und idempotente; jitter, exponentieller Backoff, maximale Versuche.
Circuit Breaker: bei Fehlern/Latenz öffnen; halb-offen für Proben.
Outlier-Erkennung: Entfernen Sie schlechte Instanzen aus dem Pool.
Bulkhead/Wettbewerb: Grenzen für gleichzeitige Per-Route-Anfragen.
Failover: aktiver/passiver, zonaler Abbau.
Schattenverkehr: „grauer“ Lauf V2 parallel zu V1 (keine Beeinflussung der Antwort) zum Vergleich.

yaml circuit_breakers:
thresholds:
- priority: DEFAULT max_connections: 1024 max_pending_requests: 2048 max_retries: 3

8) Caching und Leistung

HTTP-кеш: `Cache-Control`, `ETag/If-None-Match`, `Vary`, `stale-while-revalidate`.
Edge-Caches/ROP: CDNs für Statik und „Caching“ APIs (idempotente GETs).
Kompression: 'gzip/br' (nicht bereits komprimiert komprimieren).
Request collapsing („coalescing“): Zusammenführen identischer paralleler Abfragen.
Response shaping: Felder/Filter, Pagination (cursor-based), Größenbegrenzungen.

9) Beobachtbarkeit und Betrieb

Метрики: `l7_req_total{route,method,code}`, `latency_ms{p50,p95,p99}`, `upstream_errors`, `retry_count`, `cb_state`, `429_rate`, `quota_usage{tenant}`.
Logs: strukturell, mit 'trace _ id/span _ id', 'user _ id/tenant _ id', 'client _ ip'.
Traces: W3C Trace Context ('traceparent', 'tracestate'), propagieren im Upstream.
Audit: Wer hat was mit welchen Rechten aufgerufen; unveränderliche Speicher für sensible APIs.
SLO/SLA: Ziel p99, Fehlerbudget; Die Rout-Ebene ist besser als die globale.

10) Verwaltung des Kapazitätsplans

Quote per-tenant/Schlüssel/Kundenpool, in min/Stunde/Tag.
Burst + nachhaltige Limits; leaky bucket zum Glätten.
Fairness: bei Überlastung - faires Queuing statt „Erstbegegnet“.
Prioritäten: System-/kritische Routen mit Priorität und dedizierten Pools.

11) Änderungsmanagement und Freigaben

Canary/Blue-Green: Weight Routing; automatische Förderung durch SLO (Fehler/Latenz).
Feature Gates/Backend Flags: Aktivierung nach Header/Token.
Schatten-/Diff-Validatoren: Körper/Status-Vergleich, Delta-Toleranzen.
Stageings: dedizierte Domains/Pfade ('staging. api...'), separate Schlüssel und Kontingente.

12) Beispiele für Konfigurationen

12. 1 NGINX - Basis-Gateway mit Limit und Cache

nginx map $http_x_request_id $reqid { default $request_id; }

limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

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

security add_header Strict-Transport-Security "max-age = 31536000" always;

location /v1/ {
limit_req zone=perip burst=30 nodelay;
proxy_set_header X-Request-ID $reqid;
proxy_set_header Authorization $http_authorization;
proxy_connect_timeout 1s;
proxy_read_timeout 5s;

proxy_cache api_cache;
proxy_cache_valid 200 10s;
proxy_cache_use_stale error timeout updating;
proxy_pass http://orders-v1;
}
}

12. 2 Envoy - Routing nach Gewichten und Retrays

yaml routes:
- match: { prefix: "/orders" }
route:
weighted_clusters:
clusters:
- name: orders-v1 weight: 90
- name: orders-v2 weight: 10 retry_policy:
retry_on: "5xx,reset,connect-failure"
num_retries: 2 per_try_timeout: 2s

12. 3 Traefik - Midlwari und Header

yaml http:
middlewares:
secHeaders:
headers:
stsSeconds: 31536000 contentTypeNosniff: true routers:
api:
rule: "Host(`api. example. com`) && PathPrefix(`/v1`)"
service: svc-orders middlewares: ["secHeaders"]

13) Anti-Muster

Eine globale Grenze für alle - die „guten Nachbarn“ leiden unter den „lauten“.
Retrays ohne Idempotenz → doppelte Effekte (Zahlungen, Schaffung von Entitäten).
Ignorieren 'timeout '/' max body size' → einfrieren/Erschöpfung worker.
Mischen von Edge-Richtlinien und Geschäftslogik in einem Gateway (Perimeter-Gewichtung).
Fehlende Validierung von Schemata → die Fragilität von Kunden und „Breaking“ -Freigaben.
Nackte WebSocket ohne Rücksicht auf auth/limits/idle-time.
Geheimnisse in Überschriften ohne Rotation; kein mTLS im internen B2B.

14) Test-Playbooks (Spieltage)

Sturm der Anfragen: Limiter/Quota-Check, 429-Verhalten, Degradation.
Verlust eines Clusters: Failover/Gewichtsverteilung; SLO der Kanarienvögel.
Gewichtete Antworten: max body/timeouts; Abschneiden von Verbindungen.
Injektionen/Anomalien: WAF-Regeln, Verbot von rekursiven JSONs, große GraphQL-Tiefen.
Trace-Fehler: Überprüfung der Propagierung von 'traceparent' und Sampling.
Geheimnisse: Schlüsselrotation/JWKS, Token-Ablauf, Clock-Skew-Toleranz.

15) Checkliste Umsetzung

• Domains/Pfade/Versionen definiert, OpenAPI/Proto veröffentlicht.
• TLS/mTLS, HSTS, Secret Management und Rotation sind eingerichtet.
• Inklusive Authentifizierung (OIDC/HMAC), RBAC/Scopes, CORS.
• Limits/Quoten per tenant, faire Warteschlangen, 429-UX.
• Routing nach Gewichten/Überschriften, Kanarienplan und Rollback.
• die Politiker timeout/retry/circuit-breaker/outlier.
• Validierung von Schemata, Transformationen, PII-Maskierung.
• Edge-кеш/ETag, coalescing, gzip/br.
• Beobachtbarkeit: Metriken, Protokolle, Tracks, Dashboards und Alerts.
• Runbooks: Vorfälle, Schlüsselrotation, Blocklisten, Black Friday.

16) FAQ

F: Wie unterscheidet sich ein API-Gateway von einem Service-Mesh?
A: Gateway - Nord-Süd (externer Perimeter, End-to-End-Richtlinien). Mesh - Ost-West (Intraclusterkonnektivität/MTLS/Retrai). Oft zusammen verwendet.

Q: Wo zu implementieren auth: in Gateway oder Dienstleistungen?
A: Beide Ebenen: Gateway - coarse-grained (Authentifizierung, Grundrechte/Kontingente), Service - fine-grained (Domänenrollen/Attribute).

F: Wann wird gRPC-JSON transcoding benötigt?
A: Wenn internes gRPC und nach außen REST/JSON und einfache Clients/Browser erforderlich sind.

F: Wie wählt man eine Versionsstrategie?
A: Für öffentliche APIs - Pfad '/vN'+ deprivation header und lange overlap. Für interne - capability-flags/Kompatibilitätsschema.

17) Ergebnisse

Das API-Gateway ist nicht nur ein „Proxik“, sondern ein Zentrum für Politik und Nachhaltigkeit. Richtiges Routing, Sicherheit, Limits, Validierung und Beobachtbarkeit sorgen für Vorhersagbarkeit und Geschwindigkeit der Releases. Kombinieren Sie ein Edge-Gateway mit einem Service-Mesh, automatisieren Sie Kanarienvögel und Quoten, testen Sie Störungen - und der Perimeter wird Ihr Beschleuniger, kein Engpass.