Kapitel 15 · Cloud

Spring Cloud Gateway als API Gateway

Typ: FrameworkVersion 2 ausführlich

Spring Cloud Gateway routet APIs, kapselt Cross-Cutting Concerns wie Security, Monitoring und Resilience und ist häufig der Eingang in eine Service-Landschaft.

‹ Zurück ⌂ Index Weiter ›

Fachliche Einordnung

Ein Gateway ist kein Ort für Fachlogik. Es kontrolliert technische Eingangsregeln: Routing, Header, Tokenweitergabe, Rate Limit, CORS und Observability.

Enterprise-Merksatz: Spring Cloud Gateway routet APIs, kapselt Cross-Cutting Concerns wie Security, Monitoring und Resilience und ist häufig der Eingang in eine Service-Landschaft.

Technische Darstellung

Kernkonzepte

Route Predicate und Gateway Filter.
GlobalFilter für übergreifende Regeln.
Token Relay und Resource Server Integration.
Rate Limiting mit Redis.
Resilience und Timeouts vor Downstream-Systemen.

Wann einsetzen?

Du brauchst zentralen API-Eingang für mehrere Services.
Du migrierst Legacy-URLs auf neue Services.
Du willst technische Policies konsistent durchsetzen.

Typische Fehler und Risiken

Gateway wird zum ESB 2.0 mit Fachtransformationen.
Keine Timeouts pro Route.
Header ungeprüft weiterreichen.

Legacy- und Modernisierungssicht

Gateway unterstützt Strangler Fig: alte Pfade zeigen weiter auf Legacy, neue Pfade auf moderne Services, bis Bereiche schrittweise abgelöst sind.

Ausführliches Beispiel

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

spring:
  cloud:
    gateway:
      routes:
        - id: order-modern
          uri: http://order-service:8080
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1
            - name: Retry
              args:
                retries: 2
                statuses: BAD_GATEWAY,GATEWAY_TIMEOUT
        - id: legacy-readonly
          uri: http://legacy-order:9080
          predicates:
            - Path=/legacy/orders/**

Checkliste für Reviews

Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?