# Spring Cloud Gateway im Interview: Routing, Filter und Load Balancing > Spring Cloud Gateway für technische Interviews meistern: 12 Fragen zu Routing, Filtern, Load Balancing und API-Gateway-Patterns mit Codebeispielen. - Published: 2026-03-20 - Updated: 2026-05-01 - Author: SharpSkill - Tags: spring cloud gateway, microservices, api gateway, routing, technical interview - Reading time: 15 min --- Spring Cloud Gateway ist die Referenzlösung für die Implementierung eines API-Gateways in einer Spring-Microservices-Architektur. Technische Interviews bewerten die Fähigkeit, Routing zu konfigurieren, eigene Filter zu erstellen und Load Balancing wirkungsvoll zu steuern. > **Tipp zur Interviewvorbereitung** > > Recruiter prüfen das Verständnis von Gateway-Patterns: zentralisierte Authentifizierung, Rate Limiting und Circuit Breaker. Erklären zu können, warum Spring Cloud Gateway den Alternativen vorzuziehen ist, macht den Unterschied. ## Architektur und Grundlagen von Spring Cloud Gateway ### Frage 1: Was ist Spring Cloud Gateway und warum sollte man es einsetzen? Spring Cloud Gateway ist ein reaktives API-Gateway auf Basis von Spring WebFlux und Project Reactor. Es dient als zentraler Eintrittspunkt für alle Anfragen an die Microservices und stellt Routing, Filterung und Load Balancing bereit. ```java // GatewayApplication.java // Grundlegende Konfiguration von Spring Cloud Gateway @SpringBootApplication public class GatewayApplication { public static void main(String[] args) { // Startet den reaktiven Netty-Server (kein Tomcat) SpringApplication.run(GatewayApplication.class, args); } } ``` ```yaml # application.yml # Minimale Gateway-Konfiguration spring: cloud: gateway: routes: # Route zum User-Service - id: user-service uri: http://localhost:8081 predicates: - Path=/api/users/** # Route zum Order-Service - id: order-service uri: http://localhost:8082 predicates: - Path=/api/orders/** ``` Zu den Hauptvorteilen von Spring Cloud Gateway zählen: nicht-blockierende Architektur für hohe Performance, native Integration in das Spring-Cloud-Ökosystem und Unterstützung moderner reaktiver Patterns. ### Frage 2: Erkläre die Konzepte Route, Predicate und Filter Drei grundlegende Konzepte strukturieren Spring Cloud Gateway: Routes definieren die Ziele, Predicates legen fest, wann eine Route greift, und Filter verändern Anfragen und Antworten. ```java // RouteConfiguration.java // Programmatische Routenkonfiguration @Configuration public class RouteConfiguration { @Bean public RouteLocator customRouteLocator(RouteLocatorBuilder builder) { return builder.routes() // Route mit mehreren Predicates .route("product-service", r -> r // Predicate: URL-Pfad .path("/api/products/**") // Predicate: HTTP-Methode .and() .method(HttpMethod.GET, HttpMethod.POST) // Predicate: Header vorhanden .and() .header("X-Api-Version", "v2") // Filter: Pfad-Rewrite .filters(f -> f .rewritePath("/api/products/(?.*)", "/products/${segment}") // Filter: Header hinzufügen .addRequestHeader("X-Gateway-Source", "spring-cloud-gateway") ) // Ziel-URI .uri("http://localhost:8083")) .build(); } } ``` Der Verarbeitungsfluss folgt dieser Reihenfolge: ```text Eingehende Anfrage │ ▼ ┌─────────────────┐ │ Predicates │ → Bedingungen prüfen (Pfad, Methode, Header...) └────────┬────────┘ │ Treffer gefunden ▼ ┌─────────────────┐ │ Pre-Filters │ → Anfrage vor dem Routing verändern └────────┬────────┘ │ ▼ ┌─────────────────┐ │ HTTP Proxy │ → Weiterleitung an den Zielservice └────────┬────────┘ │ ▼ ┌─────────────────┐ │ Post-Filters │ → Antwort vor der Auslieferung an den Client verändern └────────┬────────┘ │ ▼ Antwort an den Client ``` ### Frage 3: Was sind die am häufigsten genutzten Predicates? Spring Cloud Gateway liefert zahlreiche eingebaute Predicates für vielfältige Routing-Bedingungen. Die Kombination mehrerer Predicates ermöglicht ausgefeilte Routing-Regeln. ```yaml # application.yml # Beispiele gängiger Predicates spring: cloud: gateway: routes: # Pfad-Routing mit Variablenerfassung - id: user-details uri: http://user-service predicates: - Path=/users/{userId} # Routing nach HTTP-Methode - id: user-create uri: http://user-service predicates: - Path=/users - Method=POST # Header-basiertes Routing - id: mobile-api uri: http://mobile-service predicates: - Header=X-Client-Type, mobile # Routing nach Query-Parametern - id: search-api uri: http://search-service predicates: - Query=q # Host-basiertes Routing - id: admin-portal uri: http://admin-service predicates: - Host=admin.example.com # Zeitbasiertes Routing - id: maintenance-mode uri: http://maintenance-service predicates: - Between=2026-03-20T02:00:00Z,2026-03-20T04:00:00Z ``` ```java // CustomPredicateFactory.java // Erstellung eines eigenen Predicates @Component public class ApiKeyRoutePredicateFactory extends AbstractRoutePredicateFactory { public ApiKeyRoutePredicateFactory() { super(Config.class); } @Override public Predicate apply(Config config) { return exchange -> { // Prüft das Vorhandensein und die Gültigkeit des API-Keys String apiKey = exchange.getRequest() .getHeaders() .getFirst("X-Api-Key"); return apiKey != null && config.getValidKeys().contains(apiKey); }; } @Validated public static class Config { private List validKeys = new ArrayList<>(); public List getValidKeys() { return validKeys; } public void setValidKeys(List validKeys) { this.validKeys = validKeys; } } } ``` > **Reihenfolge der Predicates** > > Die Reihenfolge der Predicates beeinflusst die Auswertung nicht, die Routenreihenfolge dagegen schon. Routen werden nacheinander geprüft und der erste Treffer wird verwendet. ## Filter und Anfragenanpassung ### Frage 4: Wie funktionieren Pre- und Post-Processing-Filter? GatewayFilter laufen in einer geordneten Kette ab. "Pre"-Filter verändern die Anfrage vor dem Routing, "Post"-Filter passen die Antwort nach dem Erhalt vom Zielservice an. ```java // LoggingFilter.java // Globaler Logging-Filter @Component @Slf4j public class LoggingFilter implements GlobalFilter, Ordered { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // PRE-FILTER: vor dem Routing String requestId = UUID.randomUUID().toString(); long startTime = System.currentTimeMillis(); log.info("Request {} started: {} {}", requestId, exchange.getRequest().getMethod(), exchange.getRequest().getPath()); // Fügt die Request-ID den Headern hinzu ServerHttpRequest modifiedRequest = exchange.getRequest() .mutate() .header("X-Request-Id", requestId) .build(); // Setzt die Kette fort und behandelt die Antwort return chain.filter(exchange.mutate().request(modifiedRequest).build()) .then(Mono.fromRunnable(() -> { // POST-FILTER: nach der Antwort long duration = System.currentTimeMillis() - startTime; HttpStatusCode status = exchange.getResponse().getStatusCode(); log.info("Request {} completed: status={}, duration={}ms", requestId, status, duration); })); } @Override public int getOrder() { // Negativer Wert = wird zuerst ausgeführt return -1; } } ``` ```java // AuthenticationFilter.java // JWT-Authentifizierungsfilter @Component @RequiredArgsConstructor public class AuthenticationFilter implements GatewayFilter { private final JwtTokenValidator tokenValidator; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { String authHeader = exchange.getRequest() .getHeaders() .getFirst(HttpHeaders.AUTHORIZATION); // Prüft das Vorhandensein des Tokens if (authHeader == null || !authHeader.startsWith("Bearer ")) { return handleUnauthorized(exchange, "Missing or invalid Authorization header"); } String token = authHeader.substring(7); // Validiert das Token reaktiv return tokenValidator.validate(token) .flatMap(claims -> { // Reichert die Anfrage mit Benutzerinformationen an ServerHttpRequest enrichedRequest = exchange.getRequest() .mutate() .header("X-User-Id", claims.getSubject()) .header("X-User-Roles", String.join(",", claims.getRoles())) .build(); return chain.filter(exchange.mutate().request(enrichedRequest).build()); }) .onErrorResume(e -> handleUnauthorized(exchange, e.getMessage())); } private Mono handleUnauthorized(ServerWebExchange exchange, String message) { exchange.getResponse().setStatusCode(HttpStatus.UNAUTHORIZED); exchange.getResponse().getHeaders().setContentType(MediaType.APPLICATION_JSON); String body = String.format("{\"error\": \"%s\"}", message); DataBuffer buffer = exchange.getResponse() .bufferFactory() .wrap(body.getBytes(StandardCharsets.UTF_8)); return exchange.getResponse().writeWith(Mono.just(buffer)); } } ``` ### Frage 5: Welche eingebauten Filter sind besonders nützlich? Spring Cloud Gateway bietet zahlreiche eingebaute Filter für gängige Einsatzszenarien: URL-Rewrite, Header-Anpassung, Retry und Circuit Breaker. ```yaml # application.yml # Gängige eingebaute Filter spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/orders/** filters: # Pfad-Rewrite - RewritePath=/api/orders/(?.*), /orders/${segment} # Request-Header hinzufügen - AddRequestHeader=X-Gateway-Version, 1.0 # Sensible Response-Header entfernen - RemoveResponseHeader=X-Powered-By - RemoveResponseHeader=Server # Pfad-Präfix - PrefixPath=/v2 # Präfix entfernen - StripPrefix=1 # Automatischer Retry bei Fehlern - name: Retry args: retries: 3 statuses: BAD_GATEWAY,SERVICE_UNAVAILABLE methods: GET backoff: firstBackoff: 100ms maxBackoff: 500ms factor: 2 # Rate Limiting - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 key-resolver: "#{@userKeyResolver}" ``` ```java // RateLimiterConfiguration.java // Konfiguration des Rate Limiters pro Benutzer @Configuration public class RateLimiterConfiguration { @Bean public KeyResolver userKeyResolver() { // Begrenzung pro authentifiziertem Benutzer return exchange -> Mono.just( exchange.getRequest() .getHeaders() .getFirst("X-User-Id") ).defaultIfEmpty("anonymous"); } @Bean public KeyResolver ipKeyResolver() { // Begrenzung pro IP-Adresse return exchange -> Mono.just( Objects.requireNonNull(exchange.getRequest() .getRemoteAddress()) .getAddress() .getHostAddress() ); } } ``` ### Frage 6: Wie implementiert man einen Filter zur Body-Anpassung? Die Anpassung des Request- oder Response-Bodys erfordert einen spezifischen Ansatz mit ModifyRequestBodyGatewayFilterFactory oder ModifyResponseBodyGatewayFilterFactory. ```java // RequestBodyModificationFilter.java // Filter zur Anpassung des Request-Bodys @Component @RequiredArgsConstructor public class RequestBodyModificationFilter implements GlobalFilter, Ordered { private final ObjectMapper objectMapper; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // Nur POST/PUT-Anfragen mit JSON anpassen if (!isJsonRequest(exchange)) { return chain.filter(exchange); } return DataBufferUtils.join(exchange.getRequest().getBody()) .flatMap(dataBuffer -> { byte[] bytes = new byte[dataBuffer.readableByteCount()]; dataBuffer.read(bytes); DataBufferUtils.release(dataBuffer); try { // Parst das JSON und passt es an Map body = objectMapper.readValue( bytes, new TypeReference>() {} ); // Fügt Metadaten hinzu body.put("processedAt", Instant.now().toString()); body.put("gatewayVersion", "1.0"); byte[] modifiedBytes = objectMapper.writeValueAsBytes(body); // Erstellt eine neue Anfrage mit angepasstem Body ServerHttpRequest modifiedRequest = new ServerHttpRequestDecorator( exchange.getRequest() ) { @Override public Flux getBody() { return Flux.just( exchange.getResponse() .bufferFactory() .wrap(modifiedBytes) ); } @Override public HttpHeaders getHeaders() { HttpHeaders headers = new HttpHeaders(); headers.putAll(super.getHeaders()); headers.setContentLength(modifiedBytes.length); return headers; } }; return chain.filter(exchange.mutate().request(modifiedRequest).build()); } catch (IOException e) { return Mono.error(new RuntimeException("Failed to parse request body", e)); } }); } private boolean isJsonRequest(ServerWebExchange exchange) { MediaType contentType = exchange.getRequest().getHeaders().getContentType(); return contentType != null && contentType.isCompatibleWith(MediaType.APPLICATION_JSON); } @Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE; } } ``` ```java // ResponseBodyModificationConfig.java // Konfiguration zur Anpassung der Antworten @Configuration public class ResponseBodyModificationConfig { @Bean public RouteLocator responseModifyingRoutes( RouteLocatorBuilder builder, ModifyResponseBodyGatewayFilterFactory modifyResponseBodyFilter ) { return builder.routes() .route("modify-response", r -> r .path("/api/users/**") .filters(f -> f.modifyResponseBody( String.class, String.class, MediaType.APPLICATION_JSON_VALUE, (exchange, responseBody) -> { // Verpackt die Antwort in ein Standardformat return Mono.just(String.format( "{\"success\": true, \"data\": %s, \"timestamp\": \"%s\"}", responseBody, Instant.now() )); } )) .uri("lb://user-service")) .build(); } } ``` ## Load Balancing und Resilienz ### Frage 7: Wie konfiguriert man Load Balancing mit Spring Cloud LoadBalancer? Spring Cloud Gateway integriert sich in Spring Cloud LoadBalancer, um Datenverkehr auf mehrere Service-Instanzen zu verteilen. Das URI-Schema `lb://` aktiviert das automatische Load Balancing. ```yaml # application.yml # Konfiguration des Load Balancing spring: cloud: gateway: routes: - id: user-service # lb:// aktiviert das Load Balancing uri: lb://user-service predicates: - Path=/api/users/** # Konfiguration des Load Balancers loadbalancer: ribbon: enabled: false # Verwendet Spring Cloud LoadBalancer (nicht Ribbon) # Konfiguration pro Service configurations: default # Health Check für das Load Balancing health-check: path: user-service: /actuator/health interval: 10s # Service Discovery (Eureka oder anderes) eureka: client: serviceUrl: defaultZone: http://localhost:8761/eureka/ ``` ```java // LoadBalancerConfiguration.java // Eigene Konfiguration des Load Balancers @Configuration @LoadBalancerClients(defaultConfiguration = CustomLoadBalancerConfig.class) public class LoadBalancerConfiguration { } // CustomLoadBalancerConfig.java // Eigene Load-Balancing-Strategie public class CustomLoadBalancerConfig { @Bean public ReactorLoadBalancer loadBalancer( Environment environment, LoadBalancerClientFactory clientFactory ) { String serviceId = environment.getProperty( LoadBalancerClientFactory.PROPERTY_NAME ); // Standardmäßig Round Robin return new RoundRobinLoadBalancer( clientFactory.getLazyProvider(serviceId, ServiceInstanceListSupplier.class), serviceId ); } @Bean public ServiceInstanceListSupplier serviceInstanceListSupplier( ConfigurableApplicationContext context ) { // Fügt den Instanzen einen Health Check hinzu return ServiceInstanceListSupplier.builder() .withDiscoveryClient() .withHealthChecks() .withCaching() .build(context); } } ``` ```java // WeightedLoadBalancer.java // Gewichteter Load Balancer @Component @RequiredArgsConstructor public class WeightedLoadBalancer implements ReactorServiceInstanceLoadBalancer { private final String serviceId; private final ObjectProvider supplierProvider; private final Random random = new Random(); @Override public Mono> choose(Request request) { return supplierProvider.getIfAvailable() .get() .next() .map(instances -> { if (instances.isEmpty()) { return new EmptyResponse(); } // Berechnet die Gewichte aus den Metadaten List weighted = instances.stream() .map(instance -> { int weight = Integer.parseInt( instance.getMetadata().getOrDefault("weight", "1") ); return new WeightedInstance(instance, weight); }) .toList(); // Gewichtete Auswahl int totalWeight = weighted.stream() .mapToInt(WeightedInstance::weight) .sum(); int randomWeight = random.nextInt(totalWeight); int currentWeight = 0; for (WeightedInstance wi : weighted) { currentWeight += wi.weight(); if (randomWeight < currentWeight) { return new DefaultResponse(wi.instance()); } } return new DefaultResponse(weighted.get(0).instance()); }); } private record WeightedInstance(ServiceInstance instance, int weight) {} } ``` ### Frage 8: Wie implementiert man einen Circuit Breaker im Gateway? Der Circuit Breaker schützt vor kaskadierenden Ausfällen. Spring Cloud Gateway integriert sich mit Resilience4j für eine fortgeschrittene Fehlerbehandlung. ```yaml # application.yml # Konfiguration des Resilience4j Circuit Breakers spring: cloud: gateway: routes: - id: order-service uri: lb://order-service predicates: - Path=/api/orders/** filters: # Circuit Breaker mit Fallback - name: CircuitBreaker args: name: orderServiceCB fallbackUri: forward:/fallback/orders resilience4j: circuitbreaker: configs: default: # Anzahl bewerteter Anfragen slidingWindowSize: 10 # Fehlergrenzwert für das Öffnen des Stromkreises failureRateThreshold: 50 # Dauer im offenen Zustand vor dem nächsten Versuch waitDurationInOpenState: 30s # Erlaubte Anfragen im Half-Open-Zustand permittedNumberOfCallsInHalfOpenState: 3 # Automatische Übergänge automaticTransitionFromOpenToHalfOpenEnabled: true instances: orderServiceCB: baseConfig: default failureRateThreshold: 60 timelimiter: configs: default: timeoutDuration: 5s instances: orderServiceCB: timeoutDuration: 3s ``` ```java // FallbackController.java // Fallback-Controller @RestController @RequestMapping("/fallback") @Slf4j public class FallbackController { @GetMapping("/orders") public Mono>> ordersFallback( ServerWebExchange exchange ) { log.warn("Circuit breaker activated for orders service"); Map response = Map.of( "success", false, "error", "Service temporarily unavailable", "code", "SERVICE_UNAVAILABLE", "retryAfter", 30 ); return Mono.just(ResponseEntity .status(HttpStatus.SERVICE_UNAVAILABLE) .body(response)); } @PostMapping("/orders") public Mono>> ordersPostFallback() { Map response = Map.of( "success", false, "error", "Order creation temporarily unavailable", "code", "SERVICE_UNAVAILABLE", "message", "Please try again later" ); return Mono.just(ResponseEntity .status(HttpStatus.SERVICE_UNAVAILABLE) .body(response)); } } ``` ```java // CircuitBreakerEventListener.java // Überwachung der Circuit-Breaker-Ereignisse @Component @Slf4j @RequiredArgsConstructor public class CircuitBreakerEventListener { private final MeterRegistry meterRegistry; @EventListener public void onCircuitBreakerStateTransition( CircuitBreakerOnStateTransitionEvent event ) { CircuitBreaker.StateTransition transition = event.getStateTransition(); log.info("Circuit breaker {} state changed: {} -> {}", event.getCircuitBreakerName(), transition.getFromState(), transition.getToState()); // Micrometer-Metrik meterRegistry.counter( "circuit_breaker.state_transition", "name", event.getCircuitBreakerName(), "from", transition.getFromState().name(), "to", transition.getToState().name() ).increment(); } @EventListener public void onCircuitBreakerFailure(CircuitBreakerOnErrorEvent event) { log.error("Circuit breaker {} error: {}", event.getCircuitBreakerName(), event.getThrowable().getMessage()); } } ``` > **Timeout und Circuit Breaker** > > Konfiguriere ein konsistentes Timeout zwischen Circuit Breaker und HTTP-Client. Ein zu langes Timeout blockiert Threads, ein zu kurzes löst Fehlalarme aus. ### Frage 9: Wie implementiert man Retry mit exponentiellem Backoff? Ein intelligenter Retry mit exponentiellem Backoff verhindert, dass ein angeschlagener Service überlastet wird, und maximiert zugleich die Erfolgschancen. ```yaml # application.yml # Konfiguration von Retry mit Backoff spring: cloud: gateway: routes: - id: payment-service uri: lb://payment-service predicates: - Path=/api/payments/** filters: - name: Retry args: # Anzahl der Versuche retries: 3 # HTTP-Codes, die einen Retry auslösen statuses: BAD_GATEWAY,SERVICE_UNAVAILABLE,GATEWAY_TIMEOUT # Nur idempotente HTTP-Methoden methods: GET,PUT # Exceptions, die einen Retry auslösen exceptions: - java.io.IOException - java.net.ConnectException - org.springframework.cloud.gateway.support.TimeoutException # Exponentieller Backoff backoff: firstBackoff: 100ms maxBackoff: 2000ms factor: 2 basedOnPreviousValue: true ``` ```java // CustomRetryFilter.java // Eigener Retry mit Geschäftslogik @Component @Slf4j public class CustomRetryFilter implements GatewayFilter, Ordered { private static final int MAX_RETRIES = 3; private static final Duration INITIAL_BACKOFF = Duration.ofMillis(100); private static final double BACKOFF_MULTIPLIER = 2.0; private static final double JITTER_FACTOR = 0.1; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { return Mono.defer(() -> attemptRequest(exchange, chain, 0)); } private Mono attemptRequest( ServerWebExchange exchange, GatewayFilterChain chain, int attempt ) { return chain.filter(exchange) .onErrorResume(throwable -> { if (attempt >= MAX_RETRIES || !isRetryable(throwable, exchange)) { return Mono.error(throwable); } Duration backoff = calculateBackoff(attempt); log.warn("Retry attempt {} after {}ms for {} {}", attempt + 1, backoff.toMillis(), exchange.getRequest().getMethod(), exchange.getRequest().getPath()); return Mono.delay(backoff) .then(Mono.defer(() -> attemptRequest(exchange, chain, attempt + 1) )); }); } private boolean isRetryable(Throwable throwable, ServerWebExchange exchange) { // Wiederholt nur idempotente Methoden HttpMethod method = exchange.getRequest().getMethod(); if (!Set.of(HttpMethod.GET, HttpMethod.PUT, HttpMethod.DELETE) .contains(method)) { return false; } // Prüft den Exception-Typ return throwable instanceof ConnectException || throwable instanceof TimeoutException || throwable instanceof ServiceUnavailableException; } private Duration calculateBackoff(int attempt) { // Exponentieller Backoff mit Jitter long baseBackoff = (long) ( INITIAL_BACKOFF.toMillis() * Math.pow(BACKOFF_MULTIPLIER, attempt) ); // Fügt zufälligen Jitter hinzu (±10%) double jitter = 1.0 + (Math.random() - 0.5) * 2 * JITTER_FACTOR; long finalBackoff = (long) (baseBackoff * jitter); return Duration.ofMillis(finalBackoff); } @Override public int getOrder() { return Ordered.LOWEST_PRECEDENCE - 1; } } ``` ## Fortgeschrittene Patterns und Best Practices ### Frage 10: Wie implementiert man Anfragen-Aggregation? Aggregation kombiniert mehrere Microservice-Aufrufe zu einer einzigen Antwort an den Client und reduziert dadurch Latenz und Frontend-Komplexität. ```java // AggregationController.java // Multi-Service-Aggregation @RestController @RequestMapping("/api/aggregate") @RequiredArgsConstructor @Slf4j public class AggregationController { private final WebClient.Builder webClientBuilder; private final CircuitBreakerRegistry circuitBreakerRegistry; @GetMapping("/user-dashboard/{userId}") public Mono getUserDashboard(@PathVariable Long userId) { // Parallele Aufrufe an verschiedene Services Mono userMono = fetchUserProfile(userId); Mono> ordersMono = fetchRecentOrders(userId); Mono notificationsMono = fetchNotificationCount(userId); // Aggregation der Ergebnisse return Mono.zip(userMono, ordersMono, notificationsMono) .map(tuple -> DashboardResponse.builder() .user(tuple.getT1()) .recentOrders(tuple.getT2()) .notificationCount(tuple.getT3()) .generatedAt(Instant.now()) .build()) .timeout(Duration.ofSeconds(5)) .onErrorResume(this::handleAggregationError); } private Mono fetchUserProfile(Long userId) { return webClientBuilder.build() .get() .uri("lb://user-service/users/{id}", userId) .retrieve() .bodyToMono(UserProfile.class) .transform(CircuitBreakerOperator.of( circuitBreakerRegistry.circuitBreaker("user-service") )) .onErrorReturn(new UserProfile(userId, "Unknown", null)); } private Mono> fetchRecentOrders(Long userId) { return webClientBuilder.build() .get() .uri("lb://order-service/orders?userId={id}&limit=5", userId) .retrieve() .bodyToFlux(Order.class) .collectList() .transform(CircuitBreakerOperator.of( circuitBreakerRegistry.circuitBreaker("order-service") )) .onErrorReturn(Collections.emptyList()); } private Mono fetchNotificationCount(Long userId) { return webClientBuilder.build() .get() .uri("lb://notification-service/notifications/count/{id}", userId) .retrieve() .bodyToMono(NotificationCount.class) .transform(CircuitBreakerOperator.of( circuitBreakerRegistry.circuitBreaker("notification-service") )) .onErrorReturn(new NotificationCount(0, 0)); } private Mono handleAggregationError(Throwable error) { log.error("Dashboard aggregation failed: {}", error.getMessage()); return Mono.just(DashboardResponse.builder() .error("Partial data available") .generatedAt(Instant.now()) .build()); } } ``` ```java // DashboardResponse.java // DTO für die aggregierte Antwort @Data @Builder @NoArgsConstructor @AllArgsConstructor public class DashboardResponse { private UserProfile user; private List recentOrders; private NotificationCount notificationCount; private Instant generatedAt; private String error; } ``` ### Frage 11: Wie sichert man das Gateway mit OAuth2? Die OAuth2-Integration zentralisiert die Authentifizierung auf Gateway-Ebene und vermeidet doppelten Code in jedem Microservice. ```yaml # application.yml # OAuth2-Resource-Server-Konfiguration spring: security: oauth2: resourceserver: jwt: issuer-uri: https://auth.example.com/realms/myrealm jwk-set-uri: https://auth.example.com/realms/myrealm/protocol/openid-connect/certs ``` ```java // SecurityConfig.java // Sicherheitskonfiguration des Gateways @Configuration @EnableWebFluxSecurity public class SecurityConfig { @Bean public SecurityWebFilterChain securityWebFilterChain(ServerHttpSecurity http) { return http // CSRF für eine zustandslose API deaktivieren .csrf(ServerHttpSecurity.CsrfSpec::disable) // Konfiguration der Autorisierung .authorizeExchange(exchanges -> exchanges // Öffentliche Endpunkte .pathMatchers("/actuator/health", "/actuator/info").permitAll() .pathMatchers("/api/public/**").permitAll() .pathMatchers("/api/auth/**").permitAll() // Rollenspezifische Endpunkte .pathMatchers("/api/admin/**").hasRole("ADMIN") .pathMatchers(HttpMethod.DELETE, "/api/**").hasRole("ADMIN") // Alles andere erfordert Authentifizierung .anyExchange().authenticated() ) // OAuth2 Resource Server mit JWT .oauth2ResourceServer(oauth2 -> oauth2 .jwt(jwt -> jwt .jwtAuthenticationConverter(jwtAuthenticationConverter()) ) ) .build(); } @Bean public ReactiveJwtAuthenticationConverter jwtAuthenticationConverter() { JwtGrantedAuthoritiesConverter grantedAuthoritiesConverter = new JwtGrantedAuthoritiesConverter(); // Extrahiert die Rollen aus dem Claim "roles" grantedAuthoritiesConverter.setAuthoritiesClaimName("roles"); grantedAuthoritiesConverter.setAuthorityPrefix("ROLE_"); ReactiveJwtAuthenticationConverter converter = new ReactiveJwtAuthenticationConverter(); converter.setJwtGrantedAuthoritiesConverter( new ReactiveJwtGrantedAuthoritiesConverterAdapter(grantedAuthoritiesConverter) ); return converter; } } ``` ```java // TokenRelayFilter.java // Weiterleitung des Tokens an die Downstream-Services @Component public class TokenRelayFilter implements GlobalFilter, Ordered { @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { return ReactiveSecurityContextHolder.getContext() .map(SecurityContext::getAuthentication) .filter(auth -> auth instanceof JwtAuthenticationToken) .cast(JwtAuthenticationToken.class) .map(JwtAuthenticationToken::getToken) .map(jwt -> { // Reicht das Token an die Downstream-Services weiter ServerHttpRequest request = exchange.getRequest() .mutate() .header(HttpHeaders.AUTHORIZATION, "Bearer " + jwt.getTokenValue()) // Fügt aus dem Token extrahierte Benutzerinformationen hinzu .header("X-User-Id", jwt.getSubject()) .header("X-User-Email", jwt.getClaimAsString("email")) .build(); return exchange.mutate().request(request).build(); }) .defaultIfEmpty(exchange) .flatMap(chain::filter); } @Override public int getOrder() { // Nach der Authentifizierung, vor dem Routing return SecurityWebFiltersOrder.AUTHENTICATION.getOrder() + 1; } } ``` ### Frage 12: Was sind die Best Practices für Monitoring und Observability? Das Monitoring des Gateways ist entscheidend, um Performance- und Verfügbarkeitsprobleme in einer Microservices-Architektur frühzeitig zu erkennen. ```yaml # application.yml # Konfiguration der Observability management: endpoints: web: exposure: include: health,info,metrics,prometheus,gateway metrics: tags: application: api-gateway distribution: percentiles-histogram: http.server.requests: true percentiles: http.server.requests: 0.5, 0.95, 0.99 tracing: sampling: probability: 1.0 spring: cloud: gateway: metrics: enabled: true tags: path: enabled: true ``` ```java // MetricsFilter.java // Filter für eigene Metriken @Component @RequiredArgsConstructor @Slf4j public class MetricsFilter implements GlobalFilter, Ordered { private final MeterRegistry meterRegistry; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { long startTime = System.nanoTime(); String path = exchange.getRequest().getPath().value(); String method = exchange.getRequest().getMethod().name(); // Liest den Zielservice aus der Route Route route = exchange.getAttribute(ServerWebExchangeUtils.GATEWAY_ROUTE_ATTR); String routeId = route != null ? route.getId() : "unknown"; return chain.filter(exchange) .doOnSuccess(v -> recordMetrics(exchange, startTime, routeId, "success")) .doOnError(e -> recordMetrics(exchange, startTime, routeId, "error")); } private void recordMetrics( ServerWebExchange exchange, long startTime, String routeId, String outcome ) { long duration = System.nanoTime() - startTime; HttpStatusCode status = exchange.getResponse().getStatusCode(); String statusCode = status != null ? String.valueOf(status.value()) : "0"; // Timer für die Latenz Timer.builder("gateway.request.duration") .tag("route", routeId) .tag("method", exchange.getRequest().getMethod().name()) .tag("status", statusCode) .tag("outcome", outcome) .register(meterRegistry) .record(duration, TimeUnit.NANOSECONDS); // Zähler der Anfragen meterRegistry.counter( "gateway.requests.total", "route", routeId, "status", statusCode ).increment(); // Logs für langsame Anfragen if (duration > TimeUnit.SECONDS.toNanos(1)) { log.warn("Slow request: {} {} - {}ms (route: {})", exchange.getRequest().getMethod(), exchange.getRequest().getPath(), TimeUnit.NANOSECONDS.toMillis(duration), routeId); } } @Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE; } } ``` ```java // TracingFilter.java // Weitergabe des Tracing-Kontexts @Component @RequiredArgsConstructor public class TracingFilter implements GlobalFilter, Ordered { private final Tracer tracer; @Override public Mono filter(ServerWebExchange exchange, GatewayFilterChain chain) { // Erstellt oder ruft den Tracing-Span ab Span span = tracer.nextSpan() .name("gateway-request") .tag("http.method", exchange.getRequest().getMethod().name()) .tag("http.url", exchange.getRequest().getURI().toString()) .start(); // Schleust die Tracing-Header ein ServerHttpRequest request = exchange.getRequest() .mutate() .header("X-Trace-Id", span.context().traceId()) .header("X-Span-Id", span.context().spanId()) .build(); return chain.filter(exchange.mutate().request(request).build()) .doOnSuccess(v -> { HttpStatusCode status = exchange.getResponse().getStatusCode(); span.tag("http.status_code", status != null ? String.valueOf(status.value()) : "0"); span.end(); }) .doOnError(e -> { span.tag("error", e.getMessage()); span.end(); }); } @Override public int getOrder() { return Ordered.HIGHEST_PRECEDENCE + 1; } } ``` Tabelle der wesentlichen Metriken: ```text | Metrik | Beschreibung | |-----------------------------------|----------------------------------| | gateway.request.duration | Latenz pro Route/Status | | gateway.requests.total | Zähler der Anfragen | | resilience4j.circuitbreaker.state | Zustände des Circuit Breakers | | http.server.requests | Standard-HTTP-Metriken | | spring.cloud.gateway.routes | Aktive Routen | ``` > **Empfohlene Dashboards** > > Nutze Grafana mit den Dashboards für Spring Cloud Gateway und Resilience4j zur Visualisierung der Metriken. Konfiguriere Alerts auf P99-Latenz und Fehlerrate. ## Fazit Spring Cloud Gateway ist ein zentraler Baustein moderner Microservices-Architekturen. Wichtige Punkte für Interviews: **Architektur und Konzepte:** - ✅ Routes, Predicates und Filter bilden das Grundmodell - ✅ Reaktive Architektur mit WebFlux und Netty - ✅ Native Integration in das Spring-Cloud-Ökosystem **Wesentliche Funktionen:** - ✅ Dynamisches Routing nach mehreren Kriterien - ✅ Pre-/Post-Filter zur Anpassung von Anfragen und Antworten - ✅ Load Balancing mit Spring Cloud LoadBalancer **Resilienz und Sicherheit:** - ✅ Circuit Breaker mit Resilience4j und Fallback - ✅ Retry mit exponentiellem Backoff und Jitter - ✅ Zentralisierte OAuth2/JWT-Authentifizierung **Observability:** - ✅ Micrometer-Metriken mit Tags pro Route - ✅ Verteiltes Tracing mit Kontextweitergabe - ✅ Health Checks und Actuator-Endpunkte Die Beherrschung von Spring Cloud Gateway zeigt ein tiefes Verständnis für Microservices-Patterns und Skalierungsthemen. Diese Fähigkeiten sind unerlässlich, um robuste und leistungsfähige API-Gateways zu entwerfen. --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/de/blog/spring-boot/spring-cloud-gateway-interview-routing-filters