Technical Tutorials

Yüksek verimli sistemler inşa etmek sadece daha fazla trafiği işlemekle ilgili değildir; trafiğin kırılmadan, ani artışlara dayanabilmesiyle ilgilidir. Reaktif mikroservislerde, kararlılık için iki kavuşmazdır: backpressure (geri baskı) ve esneklik. Sıkça birlikte anılsalar da farklı amaçlar güderler. Backpressure, tüketici aşırı yük altında kaldığında kaynağı yavaşlatma mekanizmasıdır, esneklik ise sistemin kaynakları talebe göre dinamik olarak ölçeklendirme yeteneğidir. Bu rehber, Project Reactor kullanarak modern Java tabanlı servislerde her ikisinin de pratik olarak nasıl uygulanacağını ele alır.

Backpressure Stratejilerini Anlama

Backpressure, bir üretici ile tüketici arasındaki bir iletişim protokolüdür. Reaktif bir akışta, tüketici üreticiden belirli sayıda öğe ister. Tüketici veriyi yeterince hızlı işleyemiyorsa, daha az öğe isteyerek üreticiyi fiilen kısar. Bu, bellek tükenmesini ve çöp toplama (garbage collection) patlamalarını önler.

Reactive Streams spesifikasyonunda dört ana backpressure stratejisi vardır: UNBOUNDED, ERROR, MISS ve CONFLATE. Çoğu yüksek verimli finansal veya veri boru hatlarında, yalnızca en son değerin önemli olduğu durum güncellemeleri için genellikle CONFLATE tercih edilir, oysa UNBOUNDED tüm öğeleri bellekte tamponlamayı gerektirdiğinden risklidir.

Java'da Backpressure Uygulama

Project Reactor kullanarak pratik bir örneğe bakalım. Burada hızlı bir üretici ve yavaş bir tüketici simüle ediyoruz. Varsayılan olarak Reactor sınırlı backpressure uygular. Bunu onBackpressureBuffer veya onBackpressureDrop operatörlerini kullanarak açıkça kontrol edebiliriz.

import reactor.core.publisher.Flux;
import java.time.Duration;
import java.util.concurrent.atomic.AtomicLong;

public class BackpressureExample {
    public static void main(String[] args) {
        AtomicLong counter = new AtomicLong();

        // Fast Producer: Emits 10,000 items per second
        Flux<Long> fastProducer = Flux.interval(Duration.ofMillis(1))
            .map(i -> counter.incrementAndGet())
            .limitRate(10000);

        // Slow Consumer: Processes 1 item per second
        Flux<Long> slowConsumer = fastProducer
            // Apply backpressure strategy: Buffer up to 100 items, drop the rest
            .onBackpressureBuffer(100, item -> {
                System.out.println("Dropping item due to buffer overflow: " + item);
            })
            .delayElements(Duration.ofMillis(1000))
            .doOnNext(item -> System.out.println("Processing: " + item))
            .take(10); // Take only 10 items for demonstration

        fastProducer.subscribe(slowConsumer);
    }
}

Bu örnekte, tampon taşarsa taşma işleyicisi çağrılır ve öğe düşürülür. Bu, tüketici iş parçacığının (thread) bloke olmamasını ve sistemin yanıt verici kalmasını sağlar.

Otomatik Ölçekleme ile Esneklik İnşa Etme

Backpressure mevcut altyapınızı korur, ancak esneklik başlangıçta yeterli altyapıya sahip olduğunuzu garanti eder. Kubernetes ortamında bu genellikle Horizontal Pod Autoscaler (HPA) ile sağlanır. Ana metrik genellikle CPU kullanımı veya istek kuyruğu boyutu gibi özel metriklerdir.

Ancak, reaktif uygulamalarda genellikle sabit boyutlu iş parçacığı havuzları (thread pool) bulunur. Reaktif bir servisi esnek hale getirmek için, bloke edici olmayan kodunuzun iş parçacıklarını bloke etmediğinden emin olmalısınız. Bir iş parçacığı bloke olursa, pod'unuzun etkin kapasitesi azalır ve aynı yükü işlemek için daha fazla pod ölçeklendirmeniz gerekir, bu da verimsizdir.

Her zaman bloke edici olmayan I/O'yu tercih edin. Örneğin, reaktif bir yığında veritabanı erişimi için JDBC yerine R2DBC kullanın. Bu, küçük bir olay döngüsü (event loop) iş parçacığı sayısının devasa miktarda eşzamanlı bağlantıyı işlemesine olanak tanır.

İzleme ve Ayarlama

Ölçemediğinizi optimize edemezsiniz. Reaktif akışlarınızı izlemek için enstrümantasyon (instrument) yapın:

Backpressure Sinyalleri: request(n)'in ne sıklıkla küçük sayılarla çağrıldığını veya tampon taşmasının ne sıklıkla gerçekleştiğini izleyin.
İş Parçacığı Havuzu Doygunluğu: Olay döngüsü iş parçacıklarınız doymuşsa, uygulamanız muhtemelen bloke edici I/O yapıyordur.
Gecikme Yüzdelikleri: Sistemin yük altında bozulmaya başladığını tespit etmek için P99 gecikmesini izleyin.

Sonuç

Backpressure ve esnekliği uygulamak tek seferlik bir görev değil, ayarlama ve izlemenin sürekli bir sürecidir. Reaktif çerçevenizde varsayılan backpressure stratejileriyle başlayın, sisteminizi yük altında izleyin ve tampon boyutlarını ile ölçeklendirme politikalarını buna göre ayarlayın. Bu iki kalıbı birleştirerek, yalnızca hızlı değil, aynı zamanda yüksek verimlilik koşullarında dayanıklı ve sağlam mikroservisler inşa edersiniz.