Spring Cloud

Diese Seite bleibt auch ohne JavaScript lesbar. Suche und Buttons sind Zusatzkomfort.

Spring Cloud: Config, Gateway und Resilienz

Verteilte Systeme brauchen zentrale Konfiguration, Randkontrolle und begrenzte Fehlerausbreitung.

1. Warum Spring Cloud erst bei Verteilung wichtig wird

Solange eine Anwendung als einzelner Prozess läuft, sind viele Probleme einfach: lokale Konfiguration, direkte Methodenaufrufe, ein Deployment. In verteilten Systemen kommen neue Fragen: Welche Konfiguration gilt in welcher Umgebung? Wie wird geroutet? Wie begrenzen wir Ausfälle? Wie testen Teams API-Verträge?

Spring Cloud liefert Bausteine für diese Muster, ersetzt aber keine Plattformstrategie. Kubernetes, Service Mesh, API Gateway, Observability und CI/CD müssen als Gesamtbild betrachtet werden.

Cloud Config Client Beispiel

spring:
  application:
    name: order-service
  config:
    import: optional:configserver:http://config-server:8888

management:
  endpoint:
    health:
      probes:
        enabled: true

2. Gateway als Policy-Rand

Ein Gateway bündelt Querschnitte am Rand: Routing, Rate Limits, Header-Normalisierung, Auth-Weitergabe, CORS und Observability. Es sollte keine Fachlogik enthalten. Fachlogik gehört in Services, nicht in Gateway-Filter.

Gateway Route mit Filter-Idee

spring:
  cloud:
    gateway:
      routes:
        - id: order-service
          uri: lb://order-service
          predicates:
            - Path=/api/orders/**
          filters:
            - StripPrefix=1
            - AddRequestHeader=X-Edge, spring-gateway

3. Resilienz: Timeout, Retry, Circuit Breaker

Retry ohne Timeout erzeugt Stau. Timeout ohne Fallback kann Benutzer hart treffen. Circuit Breaker ohne Metriken ist Blindflug. Resilienz ist ein Set aus begrenztem Warten, kontrolliertem Wiederholen, Lastschutz, Fallback und Observability.

Remote Call mit Timeout und begrenztem Retry

@Service
class PricingClient {
    private final WebClient webClient;

    Mono<Price> price(String sku) {
        return webClient.get().uri("/prices/{sku}", sku)
            .retrieve()
            .bodyToMono(Price.class)
            .timeout(Duration.ofMillis(800))
            .retryWhen(Retry.backoff(2, Duration.ofMillis(100))
                .filter(this::isTransient));
    }

    private boolean isTransient(Throwable t) {
        return t instanceof TimeoutException || t instanceof IOException;
    }
}

Enterprise-Prüffragen

Config extern, versioniert und nachvollziehbar?
Gateway ohne Fachlogik?
Timeout vor Retry definiert?
Fallback fachlich akzeptiert und beobachtbar?