API-Gateway: Ein einziger Eingang für viele Dienste

Kurz: Ein Vermittler, der alle Anfragen von außen entgegennimmt und an die passenden internen Dienste weiterleitet.

Genauer: Bei vielen kleinen Diensten (Microservices) wäre es mühsam, wenn jede App jeden Dienst einzeln kennen und absichern müsste. Ein API-Gateway bündelt den Zugang: Es hat eine Adresse, prüft die Anfragen und verteilt sie. Übergreifende Aufgaben werden so einmal zentral gelöst statt in jedem Dienst.

Im Detail

Aufgaben

• Routing: /bestellungen geht an den Bestelldienst, /benutzer an den Benutzerdienst.
• Authentifizierung und Autorisierung: Tokens prüfen, bevor etwas die Dienste erreicht.
• Rate Limiting und Schutz vor Missbrauch.
• TLS-Terminierung: Verschlüsselung am Eingang, intern einfacher.
• Zusammenfassen mehrerer Antworten zu einer (Aggregation) und Umformen von Formaten.
• Protokollierung, Metriken, Caching.

Beispiel für eine Routing-Regel

In nginx-ähnlicher Schreibweise:

location /api/bestellungen/ { proxy_pass http://bestelldienst:8080/; }
location /api/benutzer/     { proxy_pass http://benutzerdienst:8080/; }

In der Praxis nutzt man Produkte wie Kong, Traefik, AWS API Gateway oder Azure API Management.

Backend for Frontend (BFF)

Eine Variante ist ein eigenes Gateway je Anwendungsart, zum Beispiel eines für die mobile App und eines für die Web-Oberfläche. Jedes liefert genau die Daten, die der jeweilige Client braucht, und vermeidet viele einzelne Aufrufe.

Nachteile

Das Gateway ist ein zentraler Punkt: Fällt es aus, ist alles weg, und es kann zum Engpass werden. Es sollte darum mehrfach und hoch verfügbar betrieben werden. Außerdem darf es nicht zu viel Geschäftslogik ansammeln, sonst entsteht ein neuer Monolith. Reiner Dienst-zu-Dienst-Verkehr läuft meist nicht darüber, sondern über ein Service Mesh.

Siehe auch: Microservices, nginx und Reverse Proxy, Rate Limiting, Load Balancer