API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) · Lektion

Felhantering och fallback-mekanismer

Implementera anpassad felhantering och definiera fallback-mekanismer för kontrollerad degradering när tjänster inte är tillgängliga.

Lektion 3 av 411 steg

Felhantering och fallback-mekanismer är en gratis lektion i API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit. Detta är lektion 3 av 4. Ni kan läsa hela lektionen gratis nedan och sedan öva praktiskt i webbläsaren med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt. Den ingår i lärvägen för API-gateway och reverse proxy (Nginx + Spring Cloud Gateway), och Era framsteg synkroniseras mellan webben och CoddyKit-appen. Kursen i API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) innehåller totalt 4 lektioner.

Introduktion till motståndskraftig felhantering

I en mikrotjänstarkitektur kan tjänster sluta fungera. En API-gateway behöver robust felhantering och reservmekanismer för att säkerställa att hela systemet förblir stabilt och användarvänligt.

I den här lektionen undersöker vi hur Spring Cloud Gateway hjälper dig att hantera fel på ett smidigt sätt och tillhandahålla alternativa svar när backend-tjänster inte är tillgängliga.

Standardfel i gatewayen

Som standard tillhandahåller Spring Cloud Gateway generiska felsvar när en routad tjänst inte kan nås eller returnerar ett fel. Dessa innehåller ofta standardiserade HTTP-statuskoder, till exempel 500 Internal Server Error och 503 Service Unavailable, samt enkel JSON.

Även om dessa svar fungerar är standardmeddelandena vanligtvis inte användarvänliga och kan avslöja interna detaljer. Anpassning är avgörande för en bra användarupplevelse.

Anpassa felsvar

För att förbättra användarupplevelsen kan vi anpassa gatewayens felsvar. Det gör att vi kan:

  • Visa tydliga och varumärkesanpassade felmeddelanden.
  • Dölja känsliga interna feldetaljer.
  • Returnera konsekventa fel format från alla API:er.

Spring Cloud Gateway bygger på Spring WebFlux och gör det möjligt att implementera egna komponenter av typen ErrorWebExceptionHandler.

Exempel på egen felhanterare

Vi skapar en egen felhanterare som fångar upp fel och returnerar ett förenklat JSON-svar. Den här hanteraren ersätter standardsidan för fel.

Kör koden och försök öppna /fail. Då visas vårt anpassade meddelande!

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.boot.web.reactive.error.ErrorWebExceptionHandler;
import org.springframework.context.annotation.Configuration;
import org.springframework.core.annotation.Order;
import org.springframework.core.io.buffer.DataBuffer;
import org.springframework.http.HttpStatus;
import org.springframework.http.MediaType;
import org.springframework.http.server.reactive.ServerHttpResponse;
import org.springframework.web.server.ServerWebExchange;
import reactor.core.publisher.Mono;
import java.nio.charset.StandardCharsets;

@SpringBootApplication
public class GatewayApplication {
    public static void main(String[] args) {
        SpringApplication.run(GatewayApplication.class, args);
    }

    @Bean
    public RouteLocator routes(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("nonexistent_service", r -> r.path("/fail/**")
                .uri("http://localhost:9999")) // Route to a non-existent service
            .build();
    }
}

@Configuration
@Order(-1) // Ensure this handler runs before default ones
class CustomJsonErrorWebExceptionHandler implements ErrorWebExceptionHandler {

    @Override
    public Mono<Void> handle(ServerWebExchange exchange, Throwable ex) {
        ServerHttpResponse response = exchange.getResponse();
        response.setStatusCode(HttpStatus.INTERNAL_SERVER_ERROR);
        response.getHeaders().setContentType(MediaType.APPLICATION_JSON);

        String errorBody = "{\"status\":500, \"message\":\"Our service is temporarily unavailable. Please try again!\"}";
        DataBuffer buffer = response.bufferFactory().wrap(errorBody.getBytes(StandardCharsets.UTF_8));
        return response.writeWith(Mono.just(buffer));
    }
}

Förstå reservmekanismer

En reservmekanism tillhandahåller en alternativ väg eller ett alternativt svar när en primär tjänst slutar fungera eller blir otillgänglig. I stället för att visa ett rått fel kan gatewayen hantera situationen genom att:

  • Returnera ett standardsvar.
  • Omdirigera till en statisk felsida.
  • Anropa en särskild reservtjänst.

Reservlösningar är avgörande för motståndskraft och för att förhindra kedjefel.

Strategier för reservlösningar i gatewayen

Spring Cloud Gateway har främst stöd för reservlösningar genom sin integrering med circuit breakers, till exempel Resilience4j, som vi tog upp i den föregående lektionen. När en circuit breaker löser ut kan den anropa en reservlösning i stället för att misslyckas direkt.

Ett vanligt sätt att definiera reservlösningen är att använda metoden setFallbackUri() i circuit breaker-filtret, ofta med en forward:-URI som mål.

Implementera en enkel reservroute

Den enklaste reservlösningen är att vidarebefordra begäran till en annan URI i själva gatewayen. Det kan vara en statisk HTML-sida, en enkel Spring-controller-metod eller till och med en annan intern route.

Prefixet forward: i fallbackUri talar om för gatewayen att hantera begäran internt utan att göra ett nytt externt HTTP-anrop.

Konfigurera en reservroute

Så här konfigurerar du en route med en reservlösning. Om backend-tjänsten för routen /api/** slutar fungera, till exempel på grund av att en circuit breaker öppnas, vidarebefordrar gatewayen begäran till vår lokala endpoint /fallback.

Försök öppna /api/hello när localhost:9000 är nere.

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.gateway.route.RouteLocator;
import org.springframework.cloud.gateway.route.builder.RouteLocatorBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@SpringBootApplication
@RestController // For our simple fallback endpoint
public class GatewayApplication {
    public static void main(String[] args) {
        SpringApplication.run(GatewayApplication.class, args);
    }

    @Bean
    public RouteLocator routes(RouteLocatorBuilder builder) {
        return builder.routes()
            .route("backend_service", r -> r.path("/api/**")
                .filters(f -> f.circuitBreaker(config -> config
                    .setName("myCircuitBreaker")
                    .setFallbackUri("forward:/fallback"))) // Fallback URI
                .uri("http://localhost:9000")) // A service that might fail
            .build();
    }

    // This method acts as the fallback service
    @GetMapping("/fallback")
    public String fallback() {
        return "Service is currently unavailable. Please try again later!";
    }
}

Reservlösning via en särskild tjänst

I mer komplexa scenarier kan du konfigurera fallbackUri så att den pekar på en särskild mikrotjänst. Den här reservtjänsten kan:

  • Visa utförliga felsidor.
  • Tillhandahålla cachade data eller standarddata.
  • Logga detaljerad information om fel.

Det här tillvägagångssättet centraliserar logiken för felhantering och håller gatewayens konfiguration renare.

Testa dina kunskaper

Vilka av följande är fördelar med att implementera anpassad felhantering och reservmekanismer i en API-gateway?

Lektionssammanfattning

I den här lektionen lärde vi oss hur viktigt det är med robust felhantering och reservmekanismer i Spring Cloud Gateway. Vi undersökte hur man kan:

  • Anpassa standardsvar vid fel med ErrorWebExceptionHandler.
  • Implementera enkla reservlösningar med setFallbackUri("forward:") och circuit breakers.
  • Förstå fördelarna med särskilda reservtjänster i avancerade scenarier.

De här teknikerna är viktiga för att bygga motståndskraftiga och användarvänliga mikrotjänstapplikationer.

Gratis att börja

Lär dig API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) med en AI-lärare – gratis

Skriv och kör riktig kod i webbläsaren, få omedelbar hjälp av en AI-lärare dygnet runt och fortsätt där du slutade – på webben eller i appen.

Kurser
12
Lektioner
48

Vanliga frågor

Är lektionen ”Felhantering och fallback-mekanismer” gratis?

Ja – hela texten till ”Felhantering och fallback-mekanismer” kan läsas gratis här på webben. Om Ni vill öva interaktivt med en inbyggd kodredigerare och en AI-handledare som är tillgänglig dygnet runt och låsa upp resten av kursen i API-gateway och reverse proxy (Nginx + Spring Cloud Gateway), kan Ni uppgradera till CoddyKit PRO. Kursen i API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) innehåller totalt 4 lektioner.

Vad lär jag mig i ”Felhantering och fallback-mekanismer”?

Implementera anpassad felhantering och definiera fallback-mekanismer för kontrollerad degradering när tjänster inte är tillgängliga. Ni övar på API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) med praktisk kod som körs direkt i webbläsaren, medan en AI-handledare som är tillgänglig dygnet runt svarar på Era frågor under lektionen.

Behöver jag någon erfarenhet för att börja lära mig API-gateway och reverse proxy (Nginx + Spring Cloud Gateway)?

Du behöver inga förkunskaper. Utbildningen i API-gateway och reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit är upplagd för allt från nybörjare till avancerade elever, så att du kan börja här eller från början och gå fram i din egen takt. Detta är lektion 3 av 4.

Hur lång tid tar lektionen ”Felhantering och fallback-mekanismer”?

De flesta CoddyKit-lektioner tar cirka 5–10 minuter. Varje lektion är kort och interaktiv, så att du gör stadiga framsteg och kan fortsätta precis där du slutade – på webben eller i appen.

Kan jag skriva och köra kod i den här API-gateway och reverse proxy (Nginx + Spring Cloud Gateway)-lektionen?

Ja. Varje API-gateway och reverse proxy (Nginx + Spring Cloud Gateway)-lektion innehåller en inbyggd kodredigerare, så att du kan skriva och köra riktig kod direkt i webbläsaren och få omedelbar AI-feedback – utan lokal installation.

Alla lektioner i den här kursen

  1. Circuit breakers med Resilience4j
  2. Konfiguration av omförsök och tidsgränser
  3. Felhantering och fallback-mekanismer
  4. Bulkheads och hastighetsbegränsning för motståndskraft
← Tillbaka till API-gateway och reverse proxy (Nginx + Spring Cloud Gateway)