API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · Lekcja

Bulkheady i ograniczanie szybkości dla odporności

Izoluj awarie i chroń usługi downstream, korzystając z izolacji typu bulkhead oraz filtra RequestRateLimiter bramy.

Lekcja 4 z 413 kroki

Bulkheady i ograniczanie szybkości dla odporności to bezpłatna lekcja API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) na CoddyKit. To lekcja 4 z 4. Możesz przeczytać całą lekcję poniżej za darmo — a potem ćwiczyć ją interaktywnie w przeglądarce z wbudowanym edytorem kodu i tutorem AI dostępnym 24/7. To część ścieżki edukacyjnej API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway), a Twój postęp synchronizuje się między webem a aplikacją CoddyKit. Kurs API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zawiera 4 lekcji w sumie.

Części tej lekcji nie zostały jeszcze przetłumaczone i są wyświetlane po angielsku.

Containing the Blast Radius

Circuit breakers stop calls to a broken service, but a flood of traffic to one route can still starve others. Bulkheads and rate limiting keep one busy route from sinking the whole gateway.

The Bulkhead Pattern

Named after a ship's watertight compartments, a bulkhead caps how many concurrent calls a route may have. If one service slows down, only its compartment fills, sparing the rest.

Resilience4j Bulkhead Config

Resilience4j offers a bulkhead that limits concurrent calls per instance.

resilience4j:
  bulkhead:
    instances:
      orders:
        maxConcurrentCalls: 20

Why Rate Limiting Differs

A bulkhead caps concurrency; a rate limiter caps requests over time. Together they protect both fast bursts and sustained load.

The RequestRateLimiter Filter

Spring Cloud Gateway ships a RequestRateLimiter filter backed by a Redis token bucket. It rejects excess requests with HTTP 429.

filters:
  - name: RequestRateLimiter
    args:
      redis-rate-limiter.replenishRate: 10
      redis-rate-limiter.burstCapacity: 20

Replenish Rate and Burst

replenishRate is the steady tokens per second; burstCapacity is the most that can be spent in a spike. Burst should be greater than or equal to replenish.

Choosing a KeyResolver

A KeyResolver decides what to limit by, such as user, API key, or IP. Here we limit per user from a header.

@Bean
KeyResolver userKeyResolver() {
    return exchange -> Mono.just(
        exchange.getRequest().getHeaders()
            .getFirst("X-User-Id"));
}

Redis Backing Store

The limiter needs Redis so counts are shared across gateway instances. Add the reactive Redis starter.

<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-data-redis-reactive</artifactId>
</dependency>

Combining Patterns

Stack resilience filters on a route: circuit breaker first, then rate limiter, so traffic is shaped before reaching a possibly fragile backend.

filters:
  - name: CircuitBreaker
    args:
      name: ordersCB
      fallbackUri: forward:/fallback/orders
  - name: RequestRateLimiter
    args:
      redis-rate-limiter.replenishRate: 10
      redis-rate-limiter.burstCapacity: 20

Graceful Rejection

When the limit is exceeded the client gets 429. You can customize the status, but always return a clear, retryable response so clients can back off.

args:
  redis-rate-limiter.replenishRate: 5
  statusCode: TOO_MANY_REQUESTS

Observing the Limits

Watch metrics for 429 counts and bulkhead rejections. Tune the numbers based on real downstream capacity, not guesses.

Quick Check

What is the core difference between a bulkhead and a rate limiter?

Recap

You added two more resilience tools:

  • Bulkheads cap concurrent calls per route
  • RequestRateLimiter uses a Redis token bucket
  • replenishRate and burstCapacity shape traffic
  • A KeyResolver defines the limiting key

Combined with circuit breakers, retries, and fallbacks, your gateway degrades gracefully under stress.

Bezpłatny start

Ucz się API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) dzięki korepetycjom AI — za darmo

Pisz i uruchamiaj kod w przeglądarce, otrzymuj natychmiastową pomoc od korepetytora AI dostępnego 24/7 i kontynuuj naukę w sieci lub w aplikacji.

Kursy
12
Lekcje
48

Często zadawane pytania

Czy lekcja „Bulkheady i ograniczanie szybkości dla odporności” jest bezpłatna?

Tak — pełny tekst „Bulkheady i ograniczanie szybkości dla odporności” jest dostępny za darmo tutaj w sieci. Aby ćwiczyć ją interaktywnie (wbudowany edytor kodu i tutor AI dostępny 24/7) i odblokować resztę kursu API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway), przejdź na CoddyKit PRO. Kurs API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zawiera 4 lekcji w sumie.

Co nauczysz się w „Bulkheady i ograniczanie szybkości dla odporności”?

Izoluj awarie i chroń usługi downstream, korzystając z izolacji typu bulkhead oraz filtra RequestRateLimiter bramy. Ćwiczysz API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) z praktycznym kodem, który uruchamiasz bezpośrednio w przeglądarce, a tutor AI dostępny 24/7 odpowiada na Twoje pytania podczas pracy nad lekcją.

Czy potrzebuję doświadczenia, aby zacząć API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)?

Nie wymagamy żadnego doświadczenia. API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) w CoddyKit jest strukturyzowany dla początkujących i zaawansowanych użytkowników, więc możesz zacząć tutaj lub od początku i uczyć się w swoim tempie. To lekcja 4 z 4.

Ile czasu zajmuje lekcja „Bulkheady i ograniczanie szybkości dla odporności”?

Większość lekcji CoddyKit trwa około 5–10 minut. Każda lekcja to mały, interaktywny krok, dzięki czemu robisz systematyczne postępy i zawsze wracasz dokładnie do tego samego miejsca — na webie i w aplikacji.

Czy mogę pisać i uruchamiać kod w tej lekcji API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)?

Tak. Każda lekcja API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) zawiera wbudowany edytor kodu, więc piszesz i uruchamiasz prawdziwy kod bezpośrednio w przeglądarce i od razu otrzymujesz sprzężenie zwrotne od AI — bez konfiguracji na komputerze.

Wszystkie lekcje w tym kursie

  1. Circuit breaker z Resilience4j
  2. Konfiguracja ponowień i limitów czasu
  3. Obsługa błędów i mechanizmy awaryjne
  4. Bulkheady i ograniczanie szybkości dla odporności
← Powrót do API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)