Fejlhåndtering og fallbacks
Implementér tilpasset fejlhåndtering, og definér fallback-mekanismer til kontrolleret funktionalitet, når tjenester er utilgængelige.
Fejlhåndtering og fallbacks er en gratis API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-lektion på CoddyKit. Dette er lektion 3 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway), og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-kurset indeholder 4 lektioner i alt.
Introduktion til robust fejlhåndtering
I en mikroservicearkitektur kan tjenester svigte. En API-gateway har brug for robust fejlhåndtering og reservemekanismer for at sikre, at hele systemet forbliver stabilt og brugervenligt.
I denne lektion undersøger du, hvordan Spring Cloud Gateway hjælper dig med at håndtere fejl på en hensigtsmæssig måde og levere alternative svar, når backend-tjenester ikke er tilgængelige.
Standardfejl i gatewayen
Som standard leverer Spring Cloud Gateway generiske fejlsvar, når en routet tjeneste ikke kan nås eller returnerer en fejl. De indeholder ofte standardiserede HTTP-statuskoder (f.eks. 500 Internal Server Error og 503 Service Unavailable) samt grundlæggende JSON.
Selvom disse svar fungerer teknisk, er standardmeddelelserne normalt ikke brugervenlige og kan afsløre interne oplysninger. Tilpasning er afgørende for en god brugeroplevelse.
Tilpasning af fejlsvar
For at forbedre brugeroplevelsen kan vi tilpasse fejlsvarene fra gatewayen. Det giver os mulighed for at:
- Levere tydelige fejlmeddelelser med eget brand.
- Skjule følsomme interne fejloplysninger.
- Returnere ensartede fejlformater på tværs af alle API'er.
Spring Cloud Gateway er bygget på Spring WebFlux og giver os mulighed for at implementere brugerdefinerede ErrorWebExceptionHandler-komponenter.
Eksempel på brugerdefineret fejlhåndtering
Lad os oprette en brugerdefineret fejlhåndtering, der opfanger fejl og returnerer et forenklet JSON-svar. Denne fejlhåndtering erstatter standardsiden med fejl.
Kør denne kode, og prøv at tilgå /fail. Du får vist vores brugerdefinerede meddelelse!
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));
}
}Forståelse af reservemekanismer
En reservemekanisme leverer en alternativ sti eller et alternativt svar, når en primær tjeneste svigter eller bliver utilgængelig. I stedet for at vise en rå fejl kan gatewayen håndtere situationen elegant ved at:
- Returnere et standardsvar.
- Omdirigere til en statisk fejlside.
- Kaldes en dedikeret reservetjeneste.
Reservemekanismer er afgørende for robusthed og for at forhindre kaskaderende fejl.
Strategier for reservemekanismer i gatewayen
Spring Cloud Gateway understøtter primært reservemekanismer gennem integrationen med kredsløbsafbrydere (f.eks. Resilience4j, som vi gennemgik i den forrige lektion). Når en kredsløbsafbryder udløses, kan den i stedet for at mislykkes helt kalde en reservemekanisme.
En almindelig måde at definere denne reservemekanisme på er at bruge metoden setFallbackUri() i filteret til kredsløbsafbryderen, ofte med en forward:-URI som mål.
Implementering af en simpel reservemekanismerute
Den simpleste reservemekanisme er at videresende anmodningen til en anden URI i selve gatewayen. Det kan være en statisk HTML-side, en simpel Spring-controller-metode eller endda en anden intern rute.
Præfikset forward: i fallbackUri fortæller gatewayen, at anmodningen skal håndteres internt uden at foretage endnu et eksternt HTTP-kald.
Konfiguration af en reservemekanismerrute
Sådan konfigurerer du en rute med en reservemekanisme. Hvis backend-tjenesten for ruten /api/** svigter (f.eks. fordi en kredsløbsafbryder åbnes), videresender gatewayen anmodningen til vores lokale endepunkt /fallback.
Prøv at tilgå /api/hello, når localhost:9000 er nede.
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!";
}
}Reservemekanisme til en dedikeret tjeneste
I mere komplekse scenarier kan du konfigurere fallbackUri til at pege på en dedikeret mikroservice. Denne "reservetjeneste" kan:
- Levere omfattende fejlsider.
- Levere cachede data eller standarddata.
- Logge detaljerede fejloplysninger.
Denne tilgang centraliserer logikken til fejlhåndtering og holder gatewayens konfiguration mere overskuelig.
Test din viden
Hvilke af følgende er fordele ved at implementere brugerdefineret fejlhåndtering og reservemekanismer i en API-gateway?
Opsummering af lektionen
I denne lektion lærte vi, hvor vigtig robust fejlhåndtering og reservemekanismer er i Spring Cloud Gateway. Vi undersøgte, hvordan man kan:
- Tilpasse standardsvar ved fejl ved hjælp af
ErrorWebExceptionHandler. - Implementere simple reservemekanismer ved hjælp af
setFallbackUri("forward:")sammen med kredsløbsafbrydere. - Forstå fordelene ved dedikerede reservetjenester i avancerede scenarier.
Disse teknikker er afgørende for at bygge robuste og brugervenlige mikroserviceapplikationer.
Lær API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) med en AI-underviser — gratis
Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.
- Kurser
- 12
- Lektioner
- 48
Ofte stillede spørgsmål
Er lektionen “Fejlhåndtering og fallbacks” gratis?
Ja — hele teksten til “Fejlhåndtering og fallbacks” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-kurset, skal du opgradere til CoddyKit PRO. API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-kurset indeholder 4 lektioner i alt.
Hvad lærer jeg i “Fejlhåndtering og fallbacks”?
Implementér tilpasset fejlhåndtering, og definér fallback-mekanismer til kontrolleret funktionalitet, når tjenester er utilgængelige. Du øver dig i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.
Skal jeg have erfaring for at begynde på API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)?
Der kræves ingen tidligere erfaring. API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 3 af 4.
Hvor lang tid tager lektionen “Fejlhåndtering og fallbacks”?
De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.
Kan jeg skrive og køre kode i denne API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-lektion?
Ja. Alle API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.
Alle lektioner i dette kursus
- Circuit breakers med Resilience4j
- Konfiguration af retries og timeouts
- Fejlhåndtering og fallbacks
- Bulkheads og rate limiting for robusthed