Spring Boot'ta Adaptif Throttling ile Microservices kaynak bütçelendirme

Microservice'ler artan trafikte birbirlerinin kaynaklarını tüketerek servis kalitesini bozabilir; özellikle checkout, ödeme veya oturum açma gibi kritik API'lerde bu sorun sık görülür. Bu makalede Spring Boot tabanlı bir sistemde adaptif throttling, per-client bütçe ve izleme uygulamasının nasıl kurgulanacağını göreceksiniz ve ilk adımları atabilecek örnekleri bulacaksınız.

Neden adaptif throttling microservices mimarisi için önemli?

Monolitik değil, dağıtık bir sistemde bir servisin yüksek yükü diğer servislerin yanıt sürelerini doğrudan etkiler; basit sabit rate-limitler çoğu zaman yetersizdir çünkü kullanıcı profilleri, IP paylaşımları ve peak zamanlar dinamik olarak değişir. Adaptif throttling, istemci başına dinamik bütçelendirme, burst toleransı ve servis durumuna bağlı ayarlamalarla çalışır; bu sayede hem adil paylaşım sağlanır hem de kritik yollar korunur.

Spring Cloud ve Spring Security ile birlikte, API Gateway veya servis kenarında uygulanan adaptif throttling stratejileri spring rest api taleplerini kontrol ederken kimlik doğrulamayı ve metrik toplama süreçlerini bozmamalıdır; bunun için Bucket4j, Resilience4j, Micrometer ve Spring Actuator sık kullanılan araçlardır.

Temel bileşenler: rate limiter, bulkhead ve izleme

Etkin bir çözüme üç ana bileşen gerekir: - per-client rate limiter (token-bucket veya leaky-bucket), - resource bulkhead (ayrı thread pool veya connection pool sınırları) ve - izleme/metrik hattı (Micrometer + Prometheus). Bu bileşenler birlikte çalıştığında bir istemcinin kısa süreli burst'ü servis katmanında yığılmaya dönüşmez.

Pratikte Spring MVC veya Spring WebFlux içinde uygulama kenarında (filter/interceptor veya WebFilter) rate-limit kontrolleri yapılır; backend kaynakları için ise HikariCP maksimum bağlantı, DB sorgu zaman aşımı ve spesifik thread pool'lar (ExecutorService) ile bulkhead uygulanır. Bu kombinasyon, spring boot eğitimi veya spring boot kursu kapsamında öğrenilmesi gereken merkezi konulardandır.

Spring Boot implementasyonu: adaptif throttling ve spring rest api

Aşağıdaki kısa kod örneği, servlet filter düzeyinde her API anahtarı için token-bucket kullanan bir yaklaşımı gösterir; örnek Bucket4j kitaplığını kullanır ve 429 döndürerek fazla isteği reddeder. Bu kod gerçek proje için temel bir şablon olup, prod ortamda dağıtık state (Redis) veya Gateway entegrasyonu önerilir.

public class ApiKeyRateFilter implements javax.servlet.Filter {
  private final java.util.concurrent.ConcurrentHashMap buckets = new java.util.concurrent.ConcurrentHashMap<>();
  private io.github.bucket4j.Bucket bucketFor(String k) {
    return buckets.computeIfAbsent(k, key ->
      io.github.bucket4j.Bucket4j.builder()
        .addLimit(io.github.bucket4j.Bandwidth.classic(60, io.github.bucket4j.Refill.intervally(60, java.time.Duration.ofMinutes(1))))
        .build()
    );
  }
  public void doFilter(javax.servlet.ServletRequest req, javax.servlet.ServletResponse res, javax.servlet.FilterChain chain) throws java.io.IOException, javax.servlet.ServletException {
    javax.servlet.http.HttpServletRequest r = (javax.servlet.http.HttpServletRequest)req;
    String key = r.getHeader("X-API-KEY");
    if (key==null) { ((javax.servlet.http.HttpServletResponse)res).sendError(401); return; }
    if (bucketFor(key).tryConsume(1)) chain.doFilter(req,res); else ((javax.servlet.http.HttpServletResponse)res).sendError(429);
  }
}

Bu örnek, neden böyle yazıldığını birkaç cümleyle özetler: basit bir ConcurrentHashMap lokal state sağlar, burst'ları sınırlandırmak için token-bucket metodu kullanılır ve 401/429 durum kodları ile istemci bilgilendirilir. Prod için dikkat edilmesi gerekenler: çoklu instance ortamında state paylaşılımı (Redis, Hazelcast), API anahtarı doğrulamasını Spring Security ile entegre etmek ve metrikleri Micrometer ile kaydetmektir.

Gerçek dünya senaryosu: e-ticaret checkout microservice

Bir e-ticaret platformunda checkout servisi, Black Friday kampanyasında düzensiz trafik nedeniyle sık sık DB bağlantılarını tüketiyor ve ödeme sağlayıcı hatalarına yol açıyordu; sonuçta diğer iş akışları (katalog, sepet) da etkilendi. Sorun: IP paylaşımları ve mobil uygulama kullanıcılarının yoğun burst'ü birlikte işlemeye çalışmasıydı.

Uygulanan çözüm: API Gateway seviyesinde per-client (API key) throttling + checkout servisi içinde bulkhead (sınırlı thread pool) + önceliklendirme (kritik ödeme çağrılarına ayrılmış küçük havuz). İzleme Micrometer/Prometheus ile kuruldu ve 2 hafta A/B test sonuçları gösterdi: tail latency (p99) checkout için %45 azalma, köpüklenmiş hatalar (DB connection timeout) sayısında %70 düşüş ve toplam başarısız ödeme oranında belirgin iyileşme. Bu somut ölçümler, adaptif throttling'in operasyonel değeri olduğunu gösterdi.

Test, izleme ve actuator ile metrik hattı

Kısa bir uygulama yapılandırması, Actuator ve Prometheus için gerekli olan minimal ayarları gösterir; metrikler olmadan adaptif kuralların etkisini doğrulamak zor olur. Aşağıdaki YAML, actuator endpointlerini ve Prometheus ihracını etkinleştirir.

management:
  endpoints:
    web:
      exposure:
        include:
          - health
          - info
          - prometheus
          - metrics
  metrics:
    export:
      prometheus:
        enabled: true
endpoints:
  web:
    base-path: /actuator

Bu yapılandırma, Micrometer + Prometheus entegrasyonu için temel hatı oluşturur; metriklerde özellikle request count, request latency (percentiles), bucket tüketimi ve connection pool kullanımı izlenmelidir. Uyarı: yüksek etiket kardinalitesi (örneğin kullanıcı başına yüksek sayıda farklı label) Prometheus performansını bozabilir; etiketleri dikkatle seçin.

İncelikler ve sık karşılaşılan hatalar

Edge case: aynı IP altında birden fazla kullanıcı (NAT) olduğunda IP bazlı sınırlama masum kullanıcıları da cezalandırır; bu yüzden API anahtarı, JWT subject veya kullanıcı kimliğine dayalı limitleme tercih edilmelidir. Ayrıca burst toleransı verirken backend (DB, message broker) için yedek plan olarak circuit breaker ve retry politikaları eş zamanlı kurulmalıdır.

Yaygın hata: sadece rate limiter koyup thread pool veya connection pool sınırlarını değiştirmemek; bu durumda istekler reddedilmese bile eşzamanlı bekleyen thread sayısı artar ve GC/heap baskısı ortaya çıkar. Best practice: limitleme, bulkhead ve backpressure (HTTP 429 + Retry-After) kombinasyonunu kullanmak ve testleri yük testleriyle (k6, Gatling) doğrulamaktır.

Bu konuyu neden öğrenmelisiniz?

Adaptif throttling ve kaynak bütçelendirme, modern microservices mimarisi içinde stabiliteyi sağlayarak iş sürekliliği ve müşteri deneyimini korur; iş ilanlarında spring boot ve microservices tecrübesi olan mühendisler sıkça talep görülür.

Bu beceri, bir spring boot eğitimi veya java spring eğitimi kapsamında sizi ekiplerde kritik yol sorunlarını çözebilen pozisyona taşır; ayrıca spring rest api'lerde güvenli ve izlenebilir davranışlar tasarlama yeteneği projelere doğrudan değer katar.

Özet

• Adaptif throttling, statik limitlerden daha adil ve etkili bir kaynak kontrolü sağlar.
• Per-client token-bucket, bulkhead ve metrik hattı birlikte kullanılmalıdır.
• Spring Boot içinde filter/interceptor ile uygulama kenarında kontrol sağlanır.
• Prod ortamda state paylaşımı ve etiket kardinalitesi gibi operasyonel detaylar kritik önemdedir.
• Test ve gözleme dayalı ayarlamalar (A/B ve yük testleri) kesin sonuç verir.

Sık Sorulan Sorular

spring boot microservices için en iyi throttling yöntemi nedir?

En iyi yöntem uygulamanın ihtiyaçlarına göre değişir; genelde per-client token-bucket (Bucket4j), servis içi bulkhead (ayrı thread pool veya connection sınırları) ve gateway seviyesinde ek kontrollerin birleşimi en dengeli sonucu verir.

spring rest api için rate limiting production ortamda nasıl ölçeklenir?

Tek-instance saklanan state yerine dağıtık bir depolama (Redis, Hazelcast) veya API Gateway entegrasyonu kullanın; ayrıca metrikleri Prometheus ile toplayıp düşük kardinaliteli etiketlerle izleyin.

spring security ile API anahtarı bazlı throttling nasıl entegre edilir?

Önce Spring Security ile API anahtarını doğrulayın, sonra kimlik bilgisine dayalı bir key üretip (örneğin subject veya client-id) rate limiter'a iletin; böylece NAT/IP sorunlarından kaçınırsınız.