0Pricing
API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) · บทเรียน

กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน

แยกความล้มเหลวและปกป้องบริการปลายทางด้วยการแยกแบบกำแพงกั้นและตัวกรอง RequestRateLimiter ของเกตเวย์

กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน เป็นบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

บางส่วนของบทเรียนนี้ยังไม่ได้รับการแปล และแสดงเป็นภาษาอังกฤษ

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.

คำถามที่พบบ่อย

บทเรียน “กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ให้อัปเกรดเป็น CoddyKit PRO คอร์ส API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน”

แยกความล้มเหลวและปกป้องบริการปลายทางด้วยการแยกแบบกำแพงกั้นและตัวกรอง RequestRateLimiter ของเกตเวย์ คุณปฏิบัติ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน

บทเรียน “กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) นี้ได้ไหม

ได้ บทเรียน API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway) ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. เซอร์กิตเบรกเกอร์ด้วย Resilience4j
  2. การตั้งค่าการลองใหม่และหมดเวลา
  3. การจัดการข้อผิดพลาดและทางเลือกสำรอง
  4. กำแพงกั้นและการจำกัดอัตราเพื่อความทนทาน
← กลับไปที่ API Gateway & Reverse Proxy (Nginx + Spring Cloud Gateway)