Monolit mi Mikroservis mi? Karar Kriterleri

Monolit, uygulamanın tamamının tek bir çalıştırılabilir birim olarak dağıtıldığı yapıdır. Mikroservis mimarisinde ise uygulama, kendi başına dağıtılabilen ve genellikle kendi veri deposuna sahip parçalara bölünür. Aralarındaki seçim teknik bir moda değil, ekip ve ölçek gerçeğine dayanmalıdır.

Karar verilirken sorulacak soru şudur: mevcut yapı hangi somut sorunu üretiyor? Sorun tanımlanmadan yapılan bölme, var olan karmaşıklığı azaltmaz, yalnızca ağ üzerine dağıtır.

Mikroservisin görünmeyen maliyetleri

Tek süreç içindeki fonksiyon çağrısı ile ağ üzerinden yapılan çağrı arasında temel bir fark vardır: ikincisi başarısız olabilir, gecikebilir ve yeniden denenmesi gerekebilir. Bu fark, kodun her katmanına yansır.

Ağ çağrıları zaman aşımı, yeniden deneme ve devre kesici gerektirir.
İşlem bütünlüğü tek veritabanı işlemiyle sağlanamaz; telafi mantığı yazılır.
Hata ayıklama tek günlük dosyasından çıkar, dağıtık izleme altyapısı gerekir.
Dağıtım, sürüm uyumu ve yapılandırma yönetimi ayrı bir uzmanlık haline gelir.
Yerel geliştirme ortamında tüm sistemi ayağa kaldırmak zorlaşır.

Bu maliyetler küçük ekiplerde geliştirme hızını doğrudan düşürür. Üç kişilik bir ekibin sekiz servisi ayrı ayrı sürdürmesi, kazandığı esneklikten daha fazla zaman götürür.

Monolitin gerçek sınırları

Monolit, kod tabanı büyüdükçe değil, sınırlar belirsizleştikçe sorun çıkarır. İyi bölümlenmiş bir monolit yüz binlerce satırda da yönetilebilir kalır. Sorun genellikle şu belirtilerle görünür hale gelir:

Küçük bir değişiklik ilgisiz modüllerde hataya yol açıyor.
Tek bir ekibin dağıtımı diğer ekipleri bekletiyor.
Uygulamanın yalnızca bir bölümü yoğun kaynak tüketiyor, ancak tamamı birlikte ölçeklenmek zorunda kalıyor.
Test süresi, günde birkaç kez dağıtım yapmayı imkansız kılıyor.

Ayrışma kararının ölçütleri

Bölme kararı çoğunlukla teknik değil örgütsel bir ihtiyaçtan doğar. Birbirinden bağımsız çalışan ekiplerin birbirini beklememesi, mikroservisin en somut faydasıdır. Ekip sayısı tek haneli kaldığı sürece bu fayda büyük ölçüde teorik kalır.

İkinci geçerli ölçüt, kaynak profili belirgin biçimde farklılaşan bileşenlerin varlığıdır. Görüntü işleme ya da rapor üretme gibi işler ana uygulamadan çok farklı kaynak tüketiyorsa, bu bileşeni ayırmak ölçeklenmeyi ucuzlatır.

Üçüncü ölçüt, farklı teknoloji ihtiyacıdır. Bir bileşen başka bir dilde çok daha verimli yazılabiliyorsa, ayrı servis haline getirmek bu tercihi mümkün kılar.

Ara yol: modüler monolit

Modüler monolit, tek dağıtım birimini korurken kod içinde net sınırlar kurar. Her modülün kendi arayüzü olur ve diğer modüllere yalnızca bu arayüz üzerinden erişilir. Veritabanı tabloları da modül sahipliğine göre ayrılır.

PHP10 satır

src/
  Siparis/      // kendi servisleri, kendi tabloları
    SiparisServisi.php
  Odeme/
    OdemeServisi.php
  Bildirim/
    BildirimServisi.php

// modüller arası erişim yalnızca açık arayüzden
$siparis->olustur($sepet);  // Odeme modülü tablolara doğrudan dokunmaz

Bu yapı iki fayda sağlar. Sınırlar netleştiği için değişikliğin etkisi sınırlanır; ayrıca ileride gerçekten ayrılması gereken bir modül çıkarsa, sınır zaten çizilmiş olduğu için ayırma işlemi çok daha ucuz olur.

Geçiş nasıl yapılır?

Var olan bir monoliti tek seferde bölmek yüksek riskli bir iştir. Kademeli yaklaşımda yeni işlev ayrı serviste yazılır, eski işlev ise parça parça taşınır. Trafik önce eski koda gider, taşınan bölüm hazır olduğunda yönlendirme yeni servise çevrilir.

Geçişin her adımında geri dönüş yolu bulunmalıdır. Yeni serviste sorun çıktığında yönlendirmenin eski koda geri alınabilmesi, riski yönetilebilir seviyede tutar.

Kontrol listesi

Bölme kararı somut bir soruna dayandırılır.
Ekip sayısı ve dağıtım sıklığı ölçüt olarak değerlendirilir.
Ağ çağrılarının hata ve gecikme maliyeti hesaba katılır.
Önce modüler monolit denenir.
Geçiş kademeli yapılır ve her adımda geri dönüş yolu bırakılır.