Spring Boot API Gateway: Cache, Circuit Breaker ve Güvenlik Stratejileri

Mikroservislerde API Gateway katmanı sıkça darboğaz, hatalı çağrı patlaması ve kimlik doğrulama sorunları üretir. Bu makalede Spring Boot, Spring Cloud ve Spring Security kullanarak gateway tarafında cache, circuit breaker ve fallback stratejilerini nasıl uygulayacağınızı öğreneceksiniz.

API Gateway ve cache stratejileri ile Spring Cloud microservices

API Gateway, client isteklerini karşılayan ve autentikasyon, yönlendirme, rate limiting gibi çapraz kesen sorumlulukları üstlenen merkezi bir bileşendir; Spring Cloud Gateway bu katmanı Spring ekosistemine entegre eder. Gateway'de request caching uygulamak, backend microservice'lere giden tekrar eden çağrıları azaltır ve spring rest api gecikmesini düşürür çünkü cache'den hızlı yanıt döner.

Nasıl çalışır? Gateway, aynı key (ör. HTTP yöntem + yol + query) ile gelen istekleri önce cache'e bakarak yanıtlayabilir; cache miss olduğunda isteği ilgili spring mvc/spring rest api endpoint'ine iletir ve sonucu cache'e koyar. Bunun önemi, backend servislerin CPU ve DB yükünü azaltmak; ayrıca burst anlarında circuit breaker tetiklenmeden önce sistemin dayanmasını sağlamaktır.

Kod örneği: Spring Cache ile istek düzeyinde önbellekleme

Aşağıdaki Java örneği, bir servis metoduna @Cacheable ekleyerek product detaylarını cache'e alır; bu, gateway değil de service tarafı cache'lemesi yapan durumlar için tipiktir ve spring boot eğitimi sırasında sık gösterilir. İlk olarak neden servis tarafında cache kullanmak isteyebilirsiniz: kullanıcı bazlı varyantlar, cache invalidation kontrolü ve dağıtık cache (Caffeine/Redis) seçimi daha kolay yönetilir.

@Service
public class ProductService {
  private final ProductRepo repo;
  public ProductService(ProductRepo repo) { this.repo = repo; }
  @Cacheable(value = "product", key = "#id", unless = "#result == null")
  public Product getProduct(Long id) {
    return repo.findById(id).orElse(null);
  }
}

Bu örnek, cache anahtarını açıkça belirler ve null sonuçları cache'e koymaz; böylece yanlış pozitifler engellenir. Ayrıca dağıtık cache kullanıyorsanız (Redis) TTL ve evict stratejilerini mutlaka tasarlayın, çünkü uzun süreli cache staleness yaratır.

Spring Cloud Gateway: Circuit Breaker ve fallback uygulama

Gateway'de Circuit Breaker (örneğin Resilience4j kullanan filter) eklemek, bir downstream servis hataya geçtiğinde çağrıyı kısa devre yaparak sistem geneline yayılmasını engeller; Spring Cloud Gateway filtreleri ile fallback URI'ye yönlendirme kolaydır. Bu, microservices mimarisi içinde cascade failure -yani bir servisin hatasının zincirleme diğerlerini döndürmesini- önlemek için kritiktir.

Aşağıdaki application.yml örneği bir route için CircuitBreaker ve Retry filtrelerini gösterir; bu yapı spring cloud ve spring boot kursu uygulamalarında gateway tampona entegre edilir.

spring:
  cloud:
    gateway:
      routes:
      - id: product-route
        uri: lb://product-service
        predicates:
        - Path=/api/products/**
        filters:
        - name: CircuitBreaker
          args:
            name: productCB
            fallbackUri: forward:/fallback/product
        - name: Retry
          args:
            retries: 2

Bu konfigürasyon, iki retry deneyip başarısızlıkta fallback'e yönlendirir ve circuit breaker isimli bir ölçüm ile açıp kapama davranışlarını kontrol eder. Neden böyle? Çünkü otomatik retry'ler kısa süreli geçici hataları kapatırken, circuit breaker uzun süren hatalarda backend'i korur ve sistem kararlılığını iyileştirir.

Gerçek dünya senaryosu: e-ticaret checkout'ta gecikme patlaması

Bir e-ticaret platformunda checkout akışı, ödeme servisinin anlık yavaşlamasıyla tıkanmıştı; sonuç olarak ürün satın alma oranı düşüyor ve DB iş yükü artıyordu. Problem: Checkout servisine gelen paralel istekler ödemeyi doğrulamak için ödeme mikroservisine ardışık çağrılar yapıyor, ödeme servisi yavaşlayınca tüm pipeline etkileniyordu.

Çözüm: Gateway tarafında kullanıcı-agnostik geçici veriler için 30s TTL ile cache uygulandı, ödeme servisi için circuit breaker konfigüre edildi ve fallback'te geçici 'sorun yaşıyoruz, tekrar deneyin' mesajı gösterildi; backend tarafında ise payment servisine kuyruklama (bulkhead) uygulandı. Ölçülen sonuçlar: hatalı checkout sayısı %63 azaldı, p99 latency 420ms'den 180ms'e düştü ve DB bağlantı yükü %40 azaldı.

Edge case ve best practice: cache invalidation, Vary ve güvenlik

Cache uygularken en yaygın hata kullanıcıya özel yanıtları yanlış cache'lemek; bunun önüne geçmek için Vary başlıklarını ve cache anahtarına authorization token bağlı parçaları dikkatle ekleyin veya sadece anonim kaynakları cache'leyin. Ayrıca Spring Security ile entegre edilmiş gateway'de, token doğrulaması yapmadan önce cache'e güvenmeyin; kimlik doğrulama sonrası cache control politikalarını uygulamak daha güvenlidir.

Bir diğer incelik, stale-while-revalidate stratejisidir: kısa TTL ile arka planda yenileme yapıp kullanıcıya eski veriyi vermek çoğu kullanıcı deneyimini korur; ancak finansal işlemler gibi güçlü tutarlılık gerektiren alanlarda bu yaklaşım yanlış olabilir. Bu yüzden microservices mimarisi içinde hangi endpoint'lerin cache'e uygun olduğunu iş kurallarıyla netleştirin.

Gözlemlenebilirlik: metrikler, log ve trace korelasyonu

Uygulanan cache ve circuit breaker politikalarının etkisini görmek için Micrometer metrikleri (cache.hit, cache.miss, circuitbreaker.state) ve distribue tracing (OpenTelemetry/Sleuth) kullanın; Spring Boot ve Spring Cloud entegrasyonları bu ölçümleri kolayca Micrometer endpoint'lerine taşır. Neden önemli? Çünkü yanlış yapılandırılmış cache veya çok agresif circuit breaker, görünmez performans bozulmalarına yol açar; metrikler bu olayı erken gösterir.

Uygulamada pratik: gateway'den gelen trace id'yi backend servislere taşımak, bir isteğin path'ini end-to-end izlemeyi sağlar; ayrıca dashboard'larda cache hit ratio ve circuit breaker open sürelerini takip ederek SLA etkilerini aylık olarak raporlayabilirsiniz.

Bu konuyu neden öğrenmelisiniz?

Bu konuyu öğrenmek, microservices mimarisi içinde yaygın karşılaşılan gecikme ve dayanıklılık sorunlarını çözme becerisi kazandırır; iş ilanlarında Spring Cloud, Spring Boot ve spring rest api deneyimi sıkça talep edilir.

Spring framework eğitimi veya java spring eğitimi sırasında bu stratejileri bilmek, gerçek projelere doğrudan değer katar; bir geliştirici olarak hem performans hem de güvenlik tarafında daha etkili tasarımlar yapabilirsiniz.

Özet

• Gateway katmanında cache ve circuit breaker, mikroservis yükünü azaltıp dayanıklılığı artırır.
• Servis tarafı @Cacheable ve dağıtık cache TTL ile tutarlılık dengesi kurun.
• Circuit breaker ve retry politikalarını Spring Cloud Gateway filtreleriyle uygulayın.
• Gözlemlenebilirlik için Micrometer ve trace id korelasyonunu ihmal etmeyin.
• Cache invalidation ve user-specific response'larda Vary/anahtar tasarımına dikkat edin.

Frequently Asked Questions

spring rest api cache nasıl uygulanır gateway tarafında mı servis tarafında mı daha uygun?

Gateway tarafı, anonim ve kısa ömürlü kaynaklar için hızlı bir filtreleme sağlar; ancak kullanıcıya özel veya tutarlılık gerektiren verilerde servis tarafı @Cacheable ve dağıtık cache daha uygundur. Mimari karar, veri tutarlılığı, TTL gereksinimi ve cache invalidation maliyetine göre verilmeli.

spring boot kursu kapsamında circuit breaker ve spring cloud örnekleri bulunur mu?

Birçok ileri seviye spring boot eğitimi ve spring cloud içeren kurslar, circuit breaker, retry ve gateway filtreleri konularını pratik örneklerle öğretir; kurs seçerken hands-on örnek ve observability (Micrometer, tracing) içerip içermediğine bakın.

spring security ile gateway'de cache kullanırken nelere dikkat etmeliyim?

Öncelikle kimlik doğrulama yapılmadan önce hassas verileri cache'e koymayın, cache anahtarına kullanıcı id veya scope ekleyin ve token bazlı cache'lemeyi sınırlayın; ayrıca cache erişimini ve temizlemeyi güvenlik politikalarına dahil edin.