Spring Cloud ile Microservices: Rate Limiting, Profiling ve Güvenlik Rehberi

Spring Cloud Gateway ile token-bucket rate limiting (Bucket4j + Redis)

Spring Cloud Gateway üzerinden istek başına kotayı token-bucket ile yönetmek için Bucket4j + Redis kombinasyonu pratiktir. Aşağıdaki Maven bağımlılığını ekleyin ve GatewayFilter olarak Redis-backed token bucket uygulayın; Redis için test komutu: redis-cli --raw MONITOR (yük altında trafik izlemek için).

<dependency>
  <groupId>com.giffing.bucket4j.spring.boot.starter</groupId>
  <artifactId>bucket4j-spring-boot-starter</artifactId>
  <version>6.0.0</version>
</dependency>

Aşağıda Gateway configuration örneği (Java 11+, Spring Boot uygulaması içinde):

@Bean
public RouteLocator customRouteLocator(RouteLocatorBuilder r) {
  return r.routes()
    .route("api_route", p -> p.path("/api/**")
      .filters(f -> f.filter(new Bucket4jGatewayFilter()))
      .uri("lb://my-service"))
    .build();
}

// Bucket4jGatewayFilter içinde RedisTemplate kullanarak token çekme/yenileme yapın

Neden: token-bucket ani trafik patlamalarında TCP kuyruğunu ve GC baskısını düşürür; ölçüm yöntemi: 1) baseline yük oluşturun (wrk -t8 -c200 -d60s http://gateway/api/xxx), 2) JFR kaydı başlatın (java -XX:StartFlightRecording=duration=60s,filename=baseline.jfr -jar app.jar), 3) rate limiting açtıktan sonra aynı yükü çalıştırıp yeni JFR alın, 4) JFR ve flamegraph ile en çok CPU/blocked stack'leri karşılaştırın. Ölçümler için hedef metrikler: p50/p95/p99 latans, kuyruk uzunluğu, Redis latency (redis-cli --latency -h host).

İstek izolasyonu ve circuit breaker tuning: Resilience4j ve thread-pool bulkhead

Microservices mimarisi içinde downstream servislerin yavaşlaması tüm zinciri etkilemesin diye Resilience4j thread-pool bulkhead ve circuit-breaker kombinasyonunu kullanın. application.yml örneği (Spring Boot config):

resilience4j:
  circuitbreaker:
    configs:
      default:
        registerHealthIndicator: true
        slidingWindowType: TIME_BASED
        slidingWindowSize: 30
        minimumNumberOfCalls: 20
        permittedNumberOfCallsInHalfOpenState: 10
        failureRateThreshold: 50
  bulkhead:
    threadpool:
      instances:
        myServiceBulkhead:
          coreThreadPoolSize: 20
          maxThreadPoolSize: 40
          queueCapacity: 100

Kod tarafında WebClient kullanıyorsanız decorator örneği:

EventPublisher publisher = ...
ThreadPoolBulkhead bulkhead = ThreadPoolBulkhead.of("myServiceBulkhead");
Supplier<Mono<Response>> decorated = Bulkhead.decorateSupplier(bulkhead, () -> webClient.get().uri("/downstream").retrieve().bodyToMono(Response.class));

Neden: time-based sliding window, çağrı hacmi ani düşüşlerinde daha dengeli tepki verir; thread-pool bulkhead queueCapacity aşılması durumunda istekler hemen reject edilip 429 döndürülür, böylece JDBC pool pinning veya uzun blocking I/O kaynaklı tüm thread'lerin tükenmesi önlenir. Profilleme: async-profiler ile blocking-stack ölçün (./profiler.sh -e alloc -d 30 -o collapsed $PID) ve thread dump'ları (jstack -l $PID) karşılaştırın; after değişiklikleri değerlendirirken p95 latans ve rejectedCount metriklerini gözleyin.

Spring Security, JWT ve Micrometer ile metrik-korelasyon; düşük kardinalite stratejileri

spring security kullanan bir API'de kullanıcı bazlı rate limiting ve izleme yaparken metrik kardinalitesini yönetmek kritik. Authentication filter içinde JWT'den userId çıkarıp Micrometer'a tag olarak ekleyin, ancak yüksek cardinality önlemek için userId yerine user_group veya user_hash (mod N) kullanın. Örnek Security filter (ServletFilter içinde Micrometer kullanımına ilişkin):

public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) {
  String token = extractJwt((HttpServletRequest) req);
  String userId = parseUserId(token);
  String userTag = "u_" + (userId.hashCode() & 0xff); // 256 bucket example
  Timer.Sample sample = Timer.start(meterRegistry);
  try {
    chain.doFilter(req, res);
  } finally {
    sample.stop(meterRegistry.timer("http.server.requests", "user_bucket", userTag, "uri", ((HttpServletRequest) req).getRequestURI()));
  }
}

Prometheus tarafı için öneri: high-cardinality etiketi scrape etmeyin; user bazlı detay için ayrı trace sistemi (Jaeger/OpenTelemetry) kullanın. Neden: Prometheus'ta çok sayıda label değeri belleği patlatır; çözüm olarak Micrometer'ın DistributionSummary ve histogram buckets kullanın, ve cardinality azaltma için bucketing örneği yukarıdaki kodda verilmiştir.

Profiling stratejisi: JFR + async-profiler, ölçüm adımları ve HikariCP tuning örneği

Doğru performans iyileştirmesi için profilleme sürecini standart hale getirin: 1) reproducible yük (Gatling veya wrk) belirleyin; 2) baseline ölçüm: JFR başlatın (java -XX:StartFlightRecording=duration=60s,filename=baseline.jfr -jar app.jar) veya async-profiler ile CPU/alloc/lock capture (./profiler.sh -d 60 -e cpu -f baseline.html $PID); 3) değişiklik uygulayın (ör. HikariCP maxPoolSize veya connectionTimeout) ve tekrar ölçün; 4) karşılaştırma: p95 latency, GC time, blocked threads sayısı. HikariCP örneği application.yml:

spring:
  datasource:
    hikari:
      maximum-pool-size: 50
      minimum-idle: 10
      connection-timeout: 30000
      validation-timeout: 5000

Somut adım: baseline çekildikten sonra maximum-pool-size'ı 50'den 30'a düşürüp aynı yükü tekrar çalıştırın; async-profiler sonuçunda 'park' veya 'io' bindikleri azaldıysa bunun anlamı queueing yönünden fayda; aynı zamanda JFR'de 'Java Application' -> 'Thread Contention' grafiğini karşılaştırın. Ölçüm mantığı: her değişiklik için en az 3 tekrar alın, medyan p95'i ve GC/tps'i raporlayın. Edge case: connection-timeout çok kısa ayarlanırsa transient DB gecikmeleri 429 yerine 500 hatalara dönebilir; bu yüzden connectionTimeout ve validationTimeout değerlerini uygulamanın SLA'sına göre calibrate edin.

Sık Sorulan Sorular

spring boot eğitimi sırasında microservices mimarisi için rate limiting nasıl öğretilmeli?

Öğretimde önce teorik token-bucket ve leaky-bucket farkını gösterin, sonra pratik: Spring Cloud Gateway + Bucket4j + Redis örneği yapın. Laboratuvarda öğrencilere wrk ile yük verip baseline JFR alınmasını, ardından rate limiting'i aktif edip async-profiler ile CPU/stack karşılaştırması yaptırın. Bu süreçte öğrencilere redis-cli --latency ve Prometheus metrik sorgularını (rate and histogram) uygulamalı gösterin.

spring security ile entegre edilmiş spring rest api'de kullanıcıya özel metrik nasıl yapılır ve Prometheus sorunları nasıl önlenir?

JWT'den doğrudan userId etiketlemek yerine user_group veya hash mod ile bucket'layın (örneğin user_hash = userId.hashCode() & 0xff). Micrometer'da timer/summary oluşturup bu bucket'ı tag olarak kullanın. Prometheus için cardinality'yi azaltmak üzere yalnızca sınırlı bucket sayısı ve histogram kullanın; detaylı user-level analiz için OpenTelemetry/Jaeger trace'lerini tercih edin.

spring boot kursu kapsamında uygulamalı profiling için hangi araçları ve komutları kullanmalıyım?

Temel set: Java Flight Recorder (JFR) ve async-profiler. Örnek komutlar: JFR baseline başlatma: java -XX:StartFlightRecording=duration=60s,filename=baseline.jfr -jar app.jar; async-profiler CPU örneği: ./profiler.sh -d 30 -e cpu -f out.svg $PID; async-profiler allocation: ./profiler.sh -d 30 -e alloc -f alloc.svg $PID. Load: wrk -t8 -c200 -d60s http://gateway/api. Karşılaştırma: p95 latans ve flamegraph'taki en sıcak stack'leri eşleştirin.