Technical Tutorials

Modern yazılım dünyasında, monolitik uygulamalar giderek dağıtık mimarilere yer açıyor. Yatay ölçeklenebilirlik, hata toleransı veya bağımsız dağıtım döngüleri ihtiyacıyla şekillenen dağıtık sistemler, kurumsal düzeydeki uygulamaların omurgası haline gelmiştir. Ancak, birden fazla sunucu, veri merkezi veya bulut bölgesi üzerinde uzanan sistemler oluşturmak, tek süreçli uygulamalarda bulunmayan benzersiz bir karmaşıklık seti getirir. Bu yazıda, geliştiricilerin dağıtık mimariler tasarlarken uyması gereken temel ilkeler, yaygın desenler ve kritik zorluklar ele alınmaktadır.

Temel Ödünleşimler: CAP Teoremi

Belirli teknolojilere dalmadan önce, dağıtık bilişimin teorik kısıtlamalarını, özellikle CAP teoremiyle somutlaşan kavramları anlamak gerekir. CAP; Tutarlılık (Consistency), Erişilebilirlik (Availability) ve Bölünme Toleransı (Partition Tolerance) kelimelerinin baş harflerinden oluşur. Teorem, bir dağıtık sistemin herhangi bir anda bu üç özelliğin yalnızca ikisini garanti edebileceğini belirtir.

Tutarlılık: Her okuma işlemi, en son yazma işlemini veya bir hatayı alır.
Erişilebilirlik: Her istek, en son yazma işlemini içerme garantisi olmaksızın, hata içermeyen bir yanıt alır.
Bölünme Toleransı: Sistem, düğümler arasındaki ağda istenilen sayıda mesajın düşürülmesi veya gecikmesi durumunda çalışmaya devam eder.

Pratikte, ağ bölünmeleri kaçınılmazdır. Bu nedenle, çoğu dağıtık sistem CP (Tutarlılık ve Bölünme Toleransı) ile AP (Erişilebilirlik ve Bölünme Toleransı) arasında seçim yapmak zorundadır. Örneğin, finansal işlem sistemleri genellikle tutarlılığı öncelerken, sosyal medya akışları kullanıcıların içeriği her zaman görebilmesini sağlamak için (içerik biraz eski olsa bile) erişilebilirliği önceler.

Çekirdek Mimari Desenler

Ölçeklenebilirlik ve dayanıklılık elde etmek için mimarlar birkaç temel desen kullanır. Bunların en yaygın ikisi Mikroservisler ve Olay Odaklı Mimari'dir.

Mikroservis Mimarisi

Mikroservisler, bir uygulamayı birbirleriyle gevşek bağlı, her biri kendi sürecinde çalışan ve genellikle HTTP/REST veya gRPC gibi hafif mekanizmalar aracılığıyla iletişim kuran küçük hizmetler koleksiyonuna ayırır. Bu, ekiplerin hizmetleri bağımsız olarak geliştirmesini, dağıtmasını ve ölçeklendirmesini sağlar.

Basit bir sipariş işleme hizmetini ele alalım. Kullanıcı kimlik doğrulaması, ürün kataloğu ve sipariş karşılama işlemlerini tek bir monolitik yapı yerine bunlar ayrı ayrı ele alınır. Aşağıda, bir mikroservisin API'sini nasıl sunduğuna dair kavramsal bir temsil bulunmaktadır:

// Sipariş Hizmeti için Node.js Express Örneği
const express = require('express');
const app = express();

app.post('/orders', async (req, res) => {
    const { userId, productId, quantity } = req.body;
    
    // 1. Envanter Hizmeti üzerinden stok doğrulaması yapın (HTTP/gRPC ile)
    const isAvailable = await checkInventory(productId, quantity);
    
    if (!isAvailable) {
        return res.status(400).json({ error: 'Yetersiz stok' });
    }

    // 2. Siparişi Oluşturun
    const order = await createOrderInDatabase({ userId, productId, quantity });
    
    // 3. Mesaj Göndericisine Olay Yayınlama
    await publishToEventBus('order.created', order);

    res.json({ orderId: order.id });
});

Olay Odaklı Mimari

Hizmetlerin gevşek bağlı hale getirilmesi, olay odaklı desenlerle daha da artırılır. Doğrudan eşzamanlı çağrılar yerine, hizmetler bir mesaj göndericisine (Kafka veya RabbitMQ gibi) olaylar yayınlar. Diğer hizmetler bu olaylara abone olur ve buna göre tepki verir. Bu, sistem dayanıklılığını artırır; envanter hizmeti kapalıyken, sipariş hizmeti hala siparişleri kabul edebilir ve hizmet kurtarıldığında bunları daha sonra işleyebilir.

Başarısızlık Yönetimi: Dayanıklılık Desenleri

Dağıtık bir ortamda başarısızlık bir "eğer" meselesi değil, "ne zaman" meselesidir. Ağ gecikmesi, sunucu çökmesi ve bağımlılık hataları rutin halindedir. Geliştiriciler aşağıdaki gibi dayanıklılık desenlerini uygulamalıdır:

Direnç Kesiciler (Circuit Breakers): Başarısız bir hizmete yapılan çağrıları geçici olarak durdurarak zincirleme hataları önler ve hizmetin toparlanmasına olanak tanır.
Üstel Geri Çekilme ile Yeniden Denemeler: Sistemi aşırı yüklememek için artan gecikmelerden sonra başarısız istekleri tekrar denemek.
Önbellekleme: Aşağı akış hizmetlerindeki yükü azaltmak ve gecikmeyi düşürmek için sık okunan verileri yerel olarak depolamak.

Sonuç

Dağıtık sistem mimarisi, eşsiz bir ölçeklenebilirlik ve esneklik sunar ancak tasarımı için titiz bir yaklaşım gerektirir. CAP teoremini anlamak, mikroservisler ve olay odaklı desenlerden yararlanmak ve sağlam dayanıklılık stratejileri uygulamak suretiyle geliştiriciler, yalnızca güçlü değil, aynı zamanda kaçınılmaz başarısızlıklar karşısında da dayanıklı sistemler inşa edebilir. Teknoloji gelişmeye devam ettikçe, bu temel ilkelerine bağlı kalmak, yazılımın bir sonraki nesilini inşa etmeyi hedefleyen her kıdemli mühendis için temel önemini koruyacaktır.