Spring Boot: Blocking -> Reactive Entegrasyonu ve Kaynak İzolasyonu Rehberi

Monolitik veya yarı-microservice Spring uygulamalarında blocking I/O, thread havuzlarını tıkar ve beklenmedik gecikmelere neden olur. Bu yazıda, Spring MVC ve Spring WebFlux karışık senaryolarında nasıl kademeli geçiş yapılacağını, kaynak izolasyonu stratejilerini ve spring rest api tasarımına etkilerini adım adım göreceksiniz.

Kaynak izolasyonu ve thread havuzu yönetimi - neden önemli

Blocking çağrılar bir uygulamada CPU'dan çok thread kaynağını tüketir: JDBC sorguları, üçüncü taraf HTTP istemcileri veya dosya I/O'su uzun süren bloklama kaynaklarıdır. Spring MVC kullanan bir controller, her istek için bir Tomcat/Netty iş parçacığı (thread) kullanıyorsa, kısa sürede thread pool tükenir ve ek istekler kuyruklanıp zaman aşımına uğrar.

Bu nedenle, spring framework eğitimi ve özellikle spring boot eğitimi kapsamında geliştiricilerin thread havuz sınırları, HikariCP ayarları (maximumPoolSize, connectionTimeout, maxLifetime) ve HTTP istemci zaman aşımı parametreleri gibi altyapı konfigürasyonlarını bilmeleri gerekir. Ölçülebilir metriklere dayalı olarak - örneğin thread kullanım yüzdesi, p95 gecikme - izolasyon seviyesini belirlemek en sağlıklısıdır.

Blocking bileşenleri kademeli reactive akışa almak

Aşağıdaki örnek, blocking bir JDBC çağrısını Spring WebFlux içinde güvenli şekilde çalıştırmak için Mono.fromCallable ve Schedulers.boundedElastic() kullanır. Öncesinde bu kodun amacını açıkladım: blocking iş parçacığını event-loop'tan ayırmak ve connection pool yığılımını önlemek.

Örnek kod bloğu blocking repository çağrısını reactive sarmalarken nasıl görünür gösterir. Bu yaklaşım, spring mvc ile birlikte progressive migration (kademeli geçiş) yaparken, servisleri bir anda tamamen reactive yapmak yerine kademeli geçişe olanak tanır. Aşağıdaki kod sadece tek bir fikir sunar; gerçek projede hata yönetimi ve timeout eklenmelidir:

    // Controller veya Service içinde
    public Mono getOrderReactive(String id) {
        return Mono.fromCallable(() -> orderRepository.findById(id))
                   .subscribeOn(Schedulers.boundedElastic())
                   .map(this::toDto);
    }

Bu yapının seçilme nedeni: event-loop benzeri thread'leri blocking çağrılara maruz bırakmamak ve JVM üzerindeki reaktif katmanın tepki verme yeteneğini korumaktır. Ancak boundedElastic veya özel bir bounded thread pool kullanırken connection pool boyutlarını (HikariCP) ve eşzamanlı blocking iş sayısını uyumlu tutmak gerekir; aksi halde kaynak çakışması devam eder.

Gerçek dünya senaryosu: E-ticaret microservices'de Sipariş Servisi

Bir e-ticaret şirketinde sipariş servisi, ödeme ve stok servisleriyle senkron çağrılar yapıyor, JDBC tabanlı eski bir depo erişimi kullanıyordu ve ani kampanya yüklerinde thread pool tüketimi yüzünden hizmetler cevap veremez hale geliyordu. Müşteri şikayetleri ve artan 500 hata oranı üzerine ekip, microservices mimarisi hedefiyle kademeli bir plan uyguladı.

Uygulanan çözüm: 1) API Gateway üzerinde rate limiting, 2) sipariş servisinde blocking repository çağrılarını boundedElastic ile sarmalama ve transactional outbox kullanarak sipariş eventlerini asenkron yayınlama, 3) Spring Cloud ile mesajlaşma (Kafka) kullanıp ödeme doğrulamasını async hale getirme ve 4) Spring Security ile token bazlı kısa ömürlü yetkilendirme. İzleme tarafında Prometheus ve Grafana ile p95 ve thread-usage dashboard'ları kuruldu.

Ölçülen sonuçlar: kampanya haftasında p95 gecikme 1.2s'den 350ms'e düştü; 500 hata oranı %4'ten %0.5'e indi; thread pool saturation (doluluk) zirvede %85 yerine %30 olarak gözlendi. Bu somut metrikler müdahalenin etkisini gösterir ve spring cloud ile microservices mimarisi adaptasyonunun değerini kanıtlar.

Dağıtım, izleme ve spring cloud ile sağlıklı rollout

Kademeli reactive geçişte dağıtım stratejisi kritik: Canary veya blue-green deploy ile küçük trafik dilimleri yeni davranışı hitap ederken geri dönüş (rollback) kolay olur. Spring Cloud Config, Consul veya Kubernetes ConfigMaps ile yapılandırma yönetimi ve feature toggle'lar (özellikle trafik yönlendirme) işleri kolaylaştırır.

İzleme kısmında ise uygulama içi metrikler (Micrometer), thread pool metrikleri, JDBC pool metrikleri ve message lag (Kafka) gibi göstergeler mutlaka takip edilmeli. Spring Boot actuator, Prometheus exporter ve Grafana panelleri kurularak hangi endpoint'in blocking çağrılar yüzünden tıkandığı hızlıca tespit edilebilir; böylece müdahale zamanını ve etkisini ölçebilirsiniz.

Köşe durumlar ve best practice: timeouts, backpressure ve transactional outbox

Edge case: Blocking kodu boundedElastic'e taşıdığınızda pool boyutunu sonsuz büyütmek cazip gelebilir ancak bu bellek ve DB connection tüketimini artırır; oluşan yeni engel connection pool (HikariCP) tükenmesidir. Bu yüzden uygulamanın maxConcurrency, HikariCP max pool boyutu ve bounded thread pool sınırları birlikte planlanmalı, ayrıca DB tarafında query timeout konulmalıdır.

Aşağıdaki application.yml örneği, Resilience4j timeout ve retry ile temel koruma kurallarını gösterir. Önce ne yaptığını açıklıyorum: hedef, dış sistem çağrıları için kısa timeout ve sınırlı retry kuralı koyarak sistemin çabukçe degrade olmasını önlemek. Kod bloğunun ardından neden böyle yapılandırdığımızı açıklayacağım.

    resilience4j:
      retry:
        instances:
          paymentService:
            max-attempts: 2
            wait-duration: 200ms
      timelimiter:
        instances:
          paymentService:
            timeout-duration: 1s

Neden bu şekilde: çok uzun timeout veya yüksek retry sayısı, downstream sorunları tüm servis ağınıza yayar; kısa timeout + düşük retry ile hatayı hızlı degrada etmek ve fallback mekanizmalarıyla güvenli yanıtlar döndürmek hedeflenir. Ayrıca transactional outbox pattern ile veritabanı ve mesaj yayını arasındaki atomicity sağlanır; böylece retry sırasında duplicate event kontrolü yapılır.

Bu konuyu neden öğrenmelisiniz?

Bu konuyu öğrenmek, modern Java uygulamalarında artan istek yükünü ve üçüncü taraf bağımlılıklarını yönetmek için gereklidir; spring boot eğitimi veya java spring eğitimi arayanlar için hem backend mimari bilgisi hem de production-ready pratikler sağlar.

İş ilanlarında microservices mimarisi, spring cloud bilgisi ve spring rest api tasarımı sıkça talep edilir; bu yetenekler hem sistem güvenilirliğini artırır hem de ekip içinde daha stratejik rollere geçişi kolaylaştırır.

Özet

• Blocking I/O'yu event-loop'tan ayırmak için bounded thread pool kullanın.
• HikariCP ve thread pool ayarlarını birlikte planlayın, metriklerle doğrulayın.
• Kademeli geçişte boundedElastic + transactional outbox pattern faydalıdır.
• Resilience4j ile kısa timeout ve sınırlı retry politikası uygulayın.
• Spring Cloud ve observability araçları ile rollout'u ölçümlü yapın.

Sık Sorulan Sorular

Spring Boot eğitimi sırasında reactive programlama öğretilir mi?

Birçok spring boot eğitimi programı hem Spring MVC hem de Spring WebFlux temel kavramlarını kapsar; ancak kurs içeriğine göre reactive örneklerin uygulamalı derinliği değişir, gerçek projelerde boundedElastic veya özel thread pool kullanımına dair pratik gereklidir.

spring rest api performansı için hangi thread havuzu ayarları önemlidir?

İzlenecek temel ayarlar: uygulama server thread sayısı (Tomcat/Netty), HikariCP maximumPoolSize ve connectionTimeout; ayrıca reactive kademeli geçişte boundedElastic boyutu ile DB pool uyumu kritik rol oynar.

spring cloud ile microservices mimarisi kurarken transactional outbox gerekli mi?

Transactional outbox, veri ve mesaj entegrasyonunda atomikliği sağlar ve distributed transaction ihtiyacını ortadan kaldırarak event kayıplarını veya duplicate event sorunlarını ciddi oranda azaltır; özellikle ödeme veya sipariş gibi kritik alanlarda önerilir.

spring security ile spring rest api güvenliğinde en sık yapılan hata nedir?

En sık hata, token süreleri ve refresh politikasının yanlış ayarlanmasıdır; çok uzun token ömrü güvenlik açığı oluştururken çok kısa ömür kullanıcı deneyimini bozar, ayrıca auth ve resource servisleri arasındaki token doğrulama caching'i göz ardı edilmemeli.