Stefan Mogeritsch
09b0b1a462
Streamlined Keycloak configurations with defaults for development and production in `.env`. Added health checks and improved environment variable documentation with comments to differentiate local and server deployments. Ensured compatibility with pre-built registry images.
4.7 KiB
| type | status | owner |
|---|---|---|
| ADR | ACTIVE | Lead Architect |
ADR-0007: API-Gateway-Muster
Status
Akzeptiert
Kontext
Mit unserer Microservices-Architektur (ADR-0003) standen wir vor mehreren Herausforderungen im Zusammenhang mit der Client-Service-Kommunikation:
- Clients müssten die Standorte und Schnittstellen mehrerer Dienste kennen
- Verschiedene Clients (Web, Desktop, Mobil) müssten mehrere Aufrufe an verschiedene Dienste tätigen
- Authentifizierung und Autorisierung müssten konsistent über alle Dienste hinweg implementiert werden
- Querschnittsbelange wie Rate-Limiting, Logging und Monitoring müssten in jedem Dienst implementiert werden
- API-Versionierung und Abwärtskompatibilität müssten über alle Dienste hinweg verwaltet werden
- Die Netzwerksicherheit wäre komplexer, wenn mehrere Dienste direkt exponiert würden
Wir benötigten eine Lösung, die die Client-Service-Kommunikation vereinfachen und gleichzeitig diese Herausforderungen adressieren würde.
Entscheidung
Wir haben uns entschieden, das API-Gateway-Muster mit Spring Cloud Gateway (Spring Boot) zu implementieren. Das API-Gateway dient als einziger Eingangspunkt für alle Client-Anfragen und bietet die folgenden Funktionen:
- Anfrage-Routing: Deklaratives Routing auf Basis von Prädikaten und Filtern
- Authentifizierung und Autorisierung: Integration mit Keycloak (ADR-0006), Validierung über JWKs; Kontext-Propagation zu Backends
- Rate-Limiting: Token-Bucket/Burst-Limits via Gateway-Filter (optional Redis-gestützt)
- Anfrage/Antwort-Transformation: Manipulation von Headern/Body per Global/Gateway-Filtern
- Logging und Monitoring: Micrometer/Prometheus, strukturierte Logs, verteiltes Tracing
- Caching: Selektiv per Downstream oder Reverse-Proxy; Gateway-seitig per Filter möglich
- API-Dokumentation: Aggregation/Weiterleitung von OpenAPI-Dokumentation
- Service-Discovery: Integration mit Consul/Eureka
Unsere Implementierung umfasst:
- Eine Spring-Cloud-Gateway-Applikation (Spring Boot), containerized
- Integration mit Keycloak für Authentifizierung und Autorisierung
- Benutzerdefinierte Global/Gateway-Filter für Rate-Limiting, Logging, Monitoring
- Micrometer/Actuator für Metriken und Health
- Service-Discovery-Integration
Konsequenzen
Positive
- Vereinfachte Client-Entwicklung: Clients müssen nur mit einem einzigen Endpunkt kommunizieren
- Konsistente Sicherheit: Authentifizierung und Autorisierung werden konsistent gehandhabt
- Zentralisierte Querschnittsbelange: Rate-Limiting, Logging und Monitoring werden einmal implementiert
- Verbesserte Sicherheit: Interne Dienste werden nicht direkt Clients ausgesetzt
- Flexibilität: Das Gateway kann Anfragen und Antworten für verschiedene Clients anpassen
Negative
- Single Point of Failure: Das Gateway wird zu einer kritischen Komponente, die hochverfügbar sein muss
- Leistung-Overhead: Anfragen durchlaufen einen zusätzlichen Netzwerk-Hop
- Komplexität: Das Gateway muss eine breite Palette von Funktionalitäten handhaben
- Entwicklung-Engpass: Änderungen am Gateway können Koordination über Teams hinweg erfordern
Neutral
- Deployment-Überlegungen: Das Gateway muss angemessen bereitgestellt und skaliert werden
- Versionierungsstrategie: API-Versionierung muss immer noch verwaltet werden, wenn auch an einem Ort
Betrachtete Alternativen
Direkte Client-zu-Service-Kommunikation
Wir haben in Betracht gezogen, Clients die direkte Kommunikation mit Diensten zu ermöglichen. Dies hätte den Netzwerk-Hop durch das Gateway eliminiert, hätte aber die Client-Entwicklung komplexer gemacht und hätte die Implementierung von Querschnittsbelangen in jedem Dienst erfordert.
Backend for Frontend (BFF)-Muster
Wir haben die Implementierung separater Backend for Frontend (BFF)-Dienste für jeden Client-Typ in Betracht gezogen. Dies hätte mehr klientenspezifische Optimierungen ermöglicht, hätte aber den Entwicklungs- und Betriebsaufwand erhöht.
Service Mesh
Wir haben die Verwendung eines Service Mesh wie Istio oder Linkerd zur Handhabung der Service-zu-Service-Kommunikation in Betracht gezogen. Dies hätte viele der gleichen Vorteile für die Service-zu-Service-Kommunikation geboten, hätte aber die Herausforderungen der Client-zu-Service-Kommunikation nicht so effektiv adressiert.