Spring Boot eğitimi: Kaynak izolasyonu ile ölçeklenebilir REST API tasarımı

Modern microservices mimarisinde bir servisin tek bir yoğun istek dalgası tüm sistemi çökertebilir. Bu makalede Spring Boot, Spring REST API, Executor izolasyonu ve bulkhead desenlerini uygulamalı olarak öğrenecek, üretimde ilk adımı atacak pratik öneriler alacaksınız.

Kaynak izolasyonu neden önemli - microservices mimarisi ve spring rest api

Microservices mimarisi içinde her servis ayrı kaynak havuzuna sahip değilse, bir servisin aşırı yüklenmesi veri tabanı bağlantılarını, JVM heap'ini veya CPU'yu tüketerek zincirleme arızalara yol açar. Spring REST API uç noktalarını sınırlamak, thread ve I/O izolasyonu sağlamakla mümkün olur; bu mekanizmalar Spring Boot'un Executor, Servlet container ve HikariCP gibi bileşenleriyle doğrudan ilişkilidir.

Kaynak izolasyonu yalnızca performans değil, servis dayanıklılığı sağlar: istek başına CPU/IO bütçesi belirlemek, bulkhead veya thread pool sınırları uygulamak, timeouting ve circuit breaker ile birleştiğinde cascading failure riskini düşürür. Ayrıca Spring Security ile doğru entegrasyon kullanıcı kaynak tüketimini yetkilendirme ve bütçelendirme bağlamında kontrol etmenizi sağlar.

Spring Boot'ta ThreadPool izolasyonu ve Executor ayarı

Bir REST uç noktasını izole etmenin en doğrudan yolu, uzun veya bloklayıcı işlerini ana servlet/işleyici thread havuzundan ayırmaktır. Aşağıdaki örnek, görevleri ayrı bir ThreadPoolTaskExecutore göndererek, gelen isteklerin Tomcat/Jetty işleyici threadlerini tıkamamasını sağlar; kod bloğu üretimde kullanacağınız temel yapılandırmayı gösterir.

Aşağıdaki AsyncConfig Java konfigürasyonunda core/max pool boyutları, queue kapasitesi ve reddetme politikası belirlenir. Bu ayarlar, p95 gecikme ve OOM riskine doğrudan etki eder; küçük değişiklikler bile sistem davranışını önemli ölçüde değiştirebilir.

package com.example.config;

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.scheduling.concurrent.ThreadPoolTaskExecutor;
import java.util.concurrent.ThreadPoolExecutor;

@Configuration
public class AsyncConfig {
    @Bean(name = "apiExecutor")
    public ThreadPoolTaskExecutor apiExecutor() {
        ThreadPoolTaskExecutor exec = new ThreadPoolTaskExecutor();
        exec.setCorePoolSize(10);
        exec.setMaxPoolSize(50);
        exec.setQueueCapacity(100);
        exec.setThreadNamePrefix("api-exec-");
        exec.setRejectedExecutionHandler(new ThreadPoolExecutor.CallerRunsPolicy());
        exec.initialize();
        return exec;
    }
...

Bu konfigürasyonda CallerRunsPolicy seçimi, iş kuyruğu dolduğunda çağıran thread'in işi kendisinin yapmasını sağlar; bu hızlı çözümün dezavantajı, istemci thread'lerinin bloklanarak gecikmeleri artırabilmesidir. Üretimde, özel bir metriğe göre otomatik ölçekleme, queue kapasitesi ve maxPoolSize değerlerini tuning ile dengelemek gerekir.

İstek bazlı sınırlandırma: Bulkhead, Timeout ve Circuit Breaker

Bulkhead deseni, servisi yatay olarak bölümlendirir: belirli bir uç nokta veya fonksiyon için sınırlı sayıda eşzamanlı iş yürütülmesine izin verir. Resilience4j veya Spring Cloud Circuit Breaker ile bulkhead, timeout ve circuit breaker katmanlarını bir arada kullanmak en etkili yaklaşımlardan biridir.

Aşağıdaki örnek, bir kontrolcü metoduna Resilience4j bulkhead anotasyonu ekleyerek aynı anda çalışabilecek çağrı sayısını sınırlar; kod bloğu basit bir kullanım gösterir ve gerçek uygulamada fallback/metrik bağlama ile tamamlanmalıdır.

package com.example.web;

import org.springframework.web.bind.annotation.*;
import io.github.resilience4j.bulkhead.annotation.Bulkhead;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.http.ResponseEntity;

@RestController
@RequestMapping("/orders")
public class OrderController {
    @Autowired
    private OrderService orderService;

    @Bulkhead(name = "orders", type = io.github.resilience4j.bulkhead.ThreadPoolBulkhead.Type.SEMAPHORE)
    @GetMapping("/{id}")
    public ResponseEntity get(@PathVariable String id) {
        return ResponseEntity.ok(orderService.getOrder(id));
    }
}

Bu anotasyonlu yaklaşım, servis içindeki kritik yolları sınırlamak için hızlı bir yöntem sağlar; ancak semaphore tipi bulkhead, bekleme kuyruğu oluşturmaz ve anlık reddetmelere yol açabilir, bu yüzden çağrı yapan tarafın uygun fallback mekanizmaları olması gerekir. Ayrıca timeouter ve circuit breaker ile kombine etmek, latency patlamalarını kontrol altına alır.

Gerçek dünya senaryosu: e-ticaret sipariş servisi

Durum: Bir e-ticaret platformunda "sipariş oluştur" API'si yoğun kampanya sırasında veri tabanı kilitlenmesi ve artan bellek kullanımı nedeniyle 503 hataları veriyordu. Servis aynı anda çok sayıda ağır işlemi (kupon hesaplama, stok doğrulama, dış ödeme API çağrısı) ana işleyici threadlerinde çalıştırıyordu.

Çözüm: Sipariş akışındaki bloklayıcı adımlar ayrı apiExecutor thread pool'una taşındı, Resilience4j bulkhead ile dış ödeme çağrıları sınırlandı ve kritik DB sorguları için ayrı bağlantı havuzları ve okuma replika yönlendirmesi uygulandı. Ölçüm: p95 gecikme %70 azaldı, 503 hata oranı kampanya sırasında %85 düştü ve uygulama JVM heap büyüme eğilimi stabilize oldu.

Bu senaryoda Micrometer + Prometheus ile iş kuyruk uzunlukları, executor activeCount ve bulkhead rejections metrikleri toplandı; Grafana dashboard'ları sorun anında hangi katmanın tıkandığını göstererek doğru müdahaleyi hızlı yaptı. Spring Security token doğrulaması da öncesinde yapılarak istek başı yetkilendirme maliyeti sınırlandırıldı.

İnce ayrıntılar ve yaygın hatalar

Thread havuzları ile çalışırken sık yapılan hata, HikariCP max pool boyutunu executor max thread sayısından küçük ayarlamaktır; bu durumda her iş DB bağlantısı beklerken thread'ler dolabilir ve deadlock ile sonuçlanır. CPU-bound işler için çok büyük thread sayısı, context switch yükünü artırır; I/O-bound işler için ise çok küçük pool trafiği boğabilir.

CallerRunsPolicy kullanımı kısa vadede reddetilen işleri azaltır ama istemci threadlerini bloke edeceği için servis gecikmelerini sistematik olarak artırabilir. Ayrıca semaphore bulkhead kullanırken dikkat: düşük semaphore sayısı fazla reddetmeye sebep olur, yüksek sayı ise izolasyon faydasını azaltır; metrik odaklı A/B test ile dengeleyin.

Uygulama adımları - küçük checklist

1. Uzun veya bloklayıcı işlemleri ayrı Executor'a taşıyın.
2. Resilience4j ile bulkhead, timeout ve circuit breaker kombinasyonu kurun.
3. Micrometer ile executor/queue/bulkhead metriklerini toplayın.
4. HikariCP ve Executor boyutlarını eş zamanlı olarak tune edin.
5. Load test ve gerçek trafik ile p95/p99 etkisini ölçün.

Bu adımları uygularken küçük iterasyonlarla başlayın: önce bir uç nokta izole edilip izleme eklensin, sonra yaygın çağrı kalıplarına göre limitler ayarlansın. Otomatik alarm ve runbook hazırlanması, acil durum müdahalesini hızlandırır.

Bu konuyu neden öğrenmelisiniz?

Kaynak izolasyonu ve Spring REST API dayanıklılığı, hem kurumsal hem de startup projelerinde talep gören bir beceridir; iş ilanlarında "microservices mimarisi", "spring cloud" ve "spring security" deneyimi ile birlikte bu tür dayanıklılık tasarımlarını bilen geliştiriciler öne çıkar.

Projeye sağladığı değer somuttur: beklenmeyen trafik patlamaları sırasında hizmet sürekliliği, daha düşük hata oranı ve öngörülebilir gecikmeler sağlar; bu da müşteri memnuniyeti ve işletme maliyetleri açısından doğrudan pozitif etki üretir.

Özet

• İstek bazlı kaynak izolasyonu, microservices mimarisinde cascading failure riskini azaltır.
• Spring Boot'ta ayrı Executor ve thread pool'ları kullanmak servlet threadlerini korur.
• Resilience4j bulkhead, timeout ve circuit breaker kombinasyonu pratik ve ölçülebilir fayda verir.
• Metrikler ve load test ile pool/queue/timeout değerlerini iteratif olarak tune edin.
• HikariCP, executor ve uygulama iş yükünü birlikte düşünmek deadlock riskini azaltır.

Sık Sorulan Sorular

Spring Boot eğitimi alırken kaynak izolasyonu neden öğretilmeli?

Öğrenmenin nedeni açık: kaynak izolasyonu, üretim trafiğinde bir servisin aşırı yüklenmesinin neden olacağı zincirleme hataları engeller ve bu beceri gerçek dünya operasyonlarında kesinti sürelerini kısaltır.

spring boot kursu sırasında bulkhead ve circuit breaker nasıl uygulanır?

Kurs uygulamalarında bulkhead için Resilience4j, circuit breaker için Spring Cloud Circuit Breaker örnekleri yapılır; küçük bir servis üzerinde semaphore/queue tip bulkhead, timeout ve fallback senaryoları birlikte test edilerek gösterilir.

spring rest api performansında en sık yapılan hata nedir?

En sık hata, bloklayıcı işleri servlet işleyici thread'lerinde çalıştırmak ve DB bağlantı havuzuyla thread havuzunu uyumsuz boyutlandırmaktır; bu, deadlock ve artan gecikmeyle sonuçlanır.