API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) · leksjon

Konfigurering av nye forsøk og tidsavbrudd

Konfigurer automatiske nye forsøk ved forbigående feil, og angi tidsavbrudd for å hindre at langvarige forespørsler blokkerer ressurser.

Leksjon 2 av 412 trinn

Konfigurering av nye forsøk og tidsavbrudd er en gratis leksjon i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit. Dette er leksjon 2 av 4. Du kan lese hele leksjonen gratis nedenfor – og deretter øve praktisk i nettleseren med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt. Den er en del av læringsløpet i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway), og fremdriften din synkroniseres mellom nettet og CoddyKit-appen. Kurset i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) inneholder totalt 4 leksjoner.

Bygge robuste gateways

I mikrotjenester kan tjenester feile eller bli trege. For å holde applikasjonene våre i gang uten problemer må vi bygge inn robusthet.

  • Robusthet betyr at systemet kan gjenopprette seg etter feil og fortsette å fungere.
  • Spring Cloud Gateway tilbyr verktøy som gjør API-gatewayen mer robust.
  • To viktige strategier for robusthet er tidsavbrudd og nye forsøk.

Forhindre trege svar med tidsavbrudd

En timeout er en grense for hvor lang tid en operasjon kan bruke. Hvis operasjonen ikke fullføres innen denne tiden, stoppes den automatisk.

  • Timeouts hindrer forespørsler i å bli hengende på ubestemt tid.
  • De frigjør ressurser (som nettverkstilkoblinger og tråder) som ellers ville vært bundet opp av en treg eller ikke-svarende tjeneste.
  • I en gateway sørger timeouts for at en treg backend-tjeneste ikke gjør hele gatewayen eller andre forespørsler tregere.

Konfigurere ReadTimeout

Spring Cloud Gateway lar Dem konfigurere spesifikke timeouts for ruter. Filteret ReadTimeout brukes vanligvis til å begrense hvor lenge gatewayen venter på et svar fra backend-tjenesten etter at tilkoblingen er opprettet.

  • Denne timeouten brukes separat for hver rute.
  • Den bidrar til å hindre at én treg backend påvirker gatewayens generelle ytelse.
  • Verdien angis vanligvis i millisekunder.

Eksempel på ReadTimeout-konfigurasjon

Slik kan De konfigurere en ReadTimeout for en bestemt rute i application.yml. Dette eksempelet angir en lesetimeout på 5 sekunder for forespørsler til /service-a/**:

Husk at dette er en del av konfigurasjonen til Spring Boot-applikasjonen.

spring:
  cloud:
    gateway:
      routes:
        - id: service_a_route
          uri: http://localhost:8081
          predicates:
            - Path=/service-a/**
          filters:
            - ReadTimeout=5000

Håndtere midlertidige feil med retries

Retries innebærer at en forespørsel som har mislyktes, sendes på nytt automatisk i håp om at den lykkes ved neste forsøk.

  • De egner seg godt ved midlertidige feil: forbigående problemer som nettverksforstyrrelser eller en kortvarig omstart av en tjeneste.
  • Retries bør brukes med forsiktighet, særlig for ikke-idempotente operasjoner (handlinger som gir forskjellige resultater hvis de utføres flere ganger).
  • Spring Cloud Gateway kan konfigureres til å prøve forespørsler til backend-tjenester på nytt automatisk.

Retry GatewayFilter

Spring Cloud Gateway tilbyr et Retry-filter som aktiverer automatiske nye forsøk for mislykkede forespørsler. De kan konfigurere flere deler av retry-logikken:

  • retries: Det maksimale antallet nye forsøk.
  • statuses: HTTP-statuskoder som skal utløse et nytt forsøk (for eksempel 503 for Service Unavailable).
  • methods: HTTP-metoder som kan forsøkes på nytt (for eksempel GET og PUT).

Eksempel på retry-konfigurasjon

La oss konfigurere et Retry-filter. Dette eksempelet prøver forespørsler på nytt opptil tre ganger hvis backend-tjenesten returnerer en 5XX-feil eller 404, og gjelder spesifikt for GET-forespørsler til /service-b/**:

spring:
  cloud:
    gateway:
      routes:
        - id: service_b_route
          uri: http://localhost:8082
          predicates:
            - Path=/service-b/**
          filters:
            - name: Retry
              args:
                retries: 3
                statuses: 
                  - SERVER_ERROR
                  - NOT_FOUND
                methods:
                  - GET

Demo av enkel retry-logikk

Spring Cloud Gateway håndterer retries gjennom konfigurasjon, men grunnideen er å gjenta en løkke til operasjonen lykkes eller det maksimale antallet forsøk er nådd. Her er et enkelt Java-program som demonstrerer en retry-løkke:

public class RetryDemo {
  private static int attempt = 0;

  public static boolean simulateBackendCall() {
    System.out.println("Attempt " + (++attempt));
    return attempt < 3; // Fails for first 2 attempts
  }

  public static void main(String[] args) {
    int maxRetries = 2;
    for (int i = 0; i <= maxRetries; i++) {
      if (!simulateBackendCall()) {
        System.out.println("Success!");
        return;
      }
      System.out.println("Failed. Retrying...");
      try { Thread.sleep(100); } catch (InterruptedException e) {}
    }
    System.out.println("Max retries reached. Operation failed.");
  }
}

Kombinere timeouts og retries

Timeouts og retries brukes ofte sammen:

  • En timeout kan utløse et nytt forsøk hvis forespørselen ikke fullføres innen den angitte tiden.
  • Hvis en forespørsel får timeout, kan gatewayen deretter forsøke på nytt, i håp om at neste forsøk går raskere eller at tjenesten svarer.
  • Det er avgjørende å konfigurere dette nøye for å unngå endeløse løkker eller unødvendige forsinkelser. Et nytt forsøk kan for eksempel gjøres *etter* en read-timeout, eller en global timeout kan omfatte alle nye forsøk.

Beste praksis for robusthet

Ta hensyn til følgende beste praksis når De implementerer timeouts og retries:

  • Idempotens: Prøv bare idempotente operasjoner på nytt (for eksempel GET og PUT), med mindre De har spesifikk logikk for å håndtere ikke-idempotente operasjoner (for eksempel POST).
  • Eksponentiell backoff: Innfør stadig lengre forsinkelser mellom nye forsøk for å unngå å overbelaste en tjeneste som allerede har problemer.
  • Circuit breakers: Kombiner med circuit breakers (omtalt i leksjon 10.1) for å slutte å prøve tjenester på nytt når det er tydelig at de er nede.
  • Overvåking: Overvåk antallet nye forsøk og timeouts for å identifisere tjenester med vedvarende problemer.

Rask sjekk av gatewayens robusthet

De konfigurerer en Spring Cloud Gateway-rute for en backend-tjeneste som av og til opplever korte nettverksforstyrrelser, noe som fører til feilen 503 Service Unavailable. De vil at gatewayen automatisk skal prøve forespørselen på nytt noen ganger før den gir opp. Hvilket filter og hvilken konfigurasjon vil best oppnå dette?

Oppsummering: timeouts og retries

Vi har sett på hvordan Timeouts og Retries er grunnleggende for å bygge robuste API-gateway-er med Spring Cloud Gateway.

  • Timeouts hindrer forespørsler i å bli hengende og frigjør ressurser.
  • Filteret ReadTimeout konfigurerer ventetiden på svar fra backend-tjenester.
  • Retries sender forespørsler automatisk på nytt ved midlertidige feil.
  • Filteret Retry gir detaljert kontroll over nye forsøk, statuser og HTTP-metoder.
  • Ved å kombinere dette med beste praksis kan De bygge robuste mikrotjenestearkitekturer.
Gratis å komme i gang

Lær deg API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) med en AI-veileder – gratis

Skriv og kjør ekte kode i nettleseren, få umiddelbar hjelp fra en AI-veileder som er tilgjengelig døgnet rundt, og fortsett der du slapp – på nettet eller i appen.

Kurs
12
Leksjoner
48

Ofte stilte spørsmål

Er leksjonen «Konfigurering av nye forsøk og tidsavbrudd» gratis?

Ja – hele teksten i «Konfigurering av nye forsøk og tidsavbrudd» er gratis å lese her på nettet. For å øve interaktivt med en innebygd kodeeditor og en AI-veileder som er tilgjengelig døgnet rundt, og for å låse opp resten av API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-kurset, kan du oppgradere til CoddyKit PRO. Kurset i API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) inneholder totalt 4 leksjoner.

Hva lærer jeg i «Konfigurering av nye forsøk og tidsavbrudd»?

Konfigurer automatiske nye forsøk ved forbigående feil, og angi tidsavbrudd for å hindre at langvarige forespørsler blokkerer ressurser. Du øver på API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) med praktisk kode som du kjører direkte i nettleseren, mens en AI-veileder som er tilgjengelig døgnet rundt, svarer på spørsmålene dine mens du jobber deg gjennom leksjonen.

Trenger jeg erfaring for å begynne med API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)?

Ingen tidligere erfaring er nødvendig. API-gateway og reverse proxy (Nginx + Spring Cloud Gateway) på CoddyKit er lagt opp for både nybegynnere og viderekomne, så De kan begynne her eller helt fra start og lære i Deres eget tempo. Dette er leksjon 2 av 4.

Hvor lang tid tar leksjonen «Konfigurering av nye forsøk og tidsavbrudd»?

De fleste CoddyKit-leksjoner tar omtrent 5–10 minutter. Hver leksjon er kort og interaktiv, slik at De gjør jevne fremskritt og kan fortsette akkurat der De slapp – både på nettet og i appen.

Kan jeg skrive og kjøre kode i denne API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-leksjonen?

Ja. Alle API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)-leksjoner har en innebygd kodeeditor, slik at De kan skrive og kjøre ekte kode direkte i nettleseren og få umiddelbar tilbakemelding fra AI – uten lokal konfigurering.

Alle leksjonene i dette kurset

  1. Circuit breakers med Resilience4j
  2. Konfigurering av nye forsøk og tidsavbrudd
  3. Feilhåndtering og fallback-mekanismer
  4. Skottisolasjon og hastighetsbegrensning for robusthet
← Tilbake til API-gateway og reverse proxy (Nginx + Spring Cloud Gateway)