Mikroservis mi Monolit mi

Ekip toplantısında birisi "bunu mikroservise bölsek daha iyi olmaz mı" diyor ve odadaki herkes başını sallıyor. Altı ay sonra ortada on iki servis, on iki ayrı yayın hattı, tek bir isteğin dört servise uğradığı bir çağrı zinciri ve hangi servisin neden yavaşladığını kimsenin bilemediği bir sistem oluyor. Mikroservis mi monolit mi sorusunun cevabı moda değil, ekibinin büyüklüğü, alan bilgisinin olgunluğu ve operasyonel kapasitenle ilgilidir.

Bu rehberde iki mimarinin gerçek farkını, monolitin hangi durumlarda doğru cevap olduğunu, mikroservise geçmenin gerçekten anlamlı olduğu senaryoları, kimsenin baştan söylemediği operasyonel maliyetleri, "dağıtık monolit" denen en kötü sonucun nasıl oluştuğunu, modüler monolit denen ortadaki yolu ve kararı verirken bakman gereken somut göstergeleri anlatacağım.

İki Mimarinin Temel Farkı#

Monolit, tüm işlevlerin tek bir uygulama olarak derlendiği, dağıtıldığı ve çalıştırıldığı mimaridir. Mikroservis mimarisinde ise sistem, kendi veritabanına sahip, bağımsız yayınlanabilen küçük servislere bölünür ve bu servisler ağ üzerinden haberleşir. Ayrım kod organizasyonuyla değil, yayın ve çalışma sınırıyla ilgilidir: aynı depoda duran iyi ayrılmış modüller hâlâ monolittir, çünkü birlikte yayınlanırlar.

Bu tek fark, her şeyi değiştirir:

Tabloya bakınca mikroservisin üstün göründüğü tek satır ölçekleme ve ekip bağımsızlığıdır. Diğer her satırda bedel ödersin. Bu yüzden doğru soru "hangisi daha modern" değil, "bu iki satırın getirisi, diğer beş satırın maliyetini karşılıyor mu" sorusudur.

Monolit Ne Zaman Doğru Cevaptır#

Küçük ve orta ölçekli ekiplerin büyük çoğunluğu için monolit yalnızca kabul edilebilir değil, açıkça daha iyi seçimdir. Sebebi basittir: monolitte modüller arası çağrı bir fonksiyon çağrısıdır ve başarısız olmaz; mikroservis mimarisinde aynı çağrı ağ üzerinden gider, zaman aşımına uğrayabilir, yarıda kesilebilir ve senin bunun için kod yazman gerekir.

Monolitin doğru cevap olduğu durumların işaretleri şunlardır:

1. Ekip on kişiden küçük ve herkes kodun büyük kısmına aşina.
2. Alan sınırları henüz net değil; hangi işlevin nereye ait olduğu tartışılıyor.
3. Ürün hâlâ hızlı değişiyor, sınırlar her ay yeniden çiziliyor.
4. Ölçek sorunu yok ya da tek bir bileşende yoğunlaşmış durumda.
5. Nöbet tutan, dağıtık sistem işletebilecek bir operasyon kapasiten yok.

Üçüncü madde en kritiğidir. Servis sınırlarını yanlış çizersen, düzeltmek için servisleri birleştirmen ya da veriyi taşıman gerekir; bu, monolitte bir dosyayı taşımaktan kat kat pahalıdır. Alanı tanımadan sınır çizmek, mikroservise geçen ekiplerin en pahalı hatasıdır.

Monolit demek "kötü yapılandırılmış" demek değildir. İyi bir monolit de Twelve-Factor App ilkelerine uyar: durumsuzdur, yapılandırmasını ortamdan alır, yatay ölçeklenir. Tek fark, birlikte yayınlanmasıdır.

Mikroservise Geçiren Gerçek Sebepler#

Mikroservisin çözdüğü sorunlar gerçektir ama sanıldığından dardır. Sahada geçişi haklı çıkaran sebepler genellikle şu üçünden biridir.

Ekipler birbirini bekliyor. Kırk geliştiricinin aynı depoda çalıştığı bir yerde yayın kuyruğu, birleştirme çakışmaları ve "senin değişiklik testleri kırdı" tartışmaları günün önemli bir kısmını yer. Servis sınırları, aslında ekip sınırlarıdır; asıl kazanç teknik değil örgütseldir.

Bir bileşen diğerlerinden çok farklı ölçekleniyor. Görüntü işleme, rapor üretme ya da öneri motoru gibi bir bileşen ana uygulamanın on katı kaynak tüketiyorsa, tümünü birlikte ölçeklemek pahalıdır. Bu durumda o tek bileşeni ayırmak, sistemin tamamını bölmekten çok daha akıllıcadır.

Farklı teknoloji zorunluluğu. Ana uygulaman PHP ile yazılmışken makine öğrenmesi bileşeninin Python olması gerekiyorsa, ayrı servis doğal bir sınırdır.

Bu üçünde de dikkat edilecek nokta aynıdır: geçiş hepsini birden bölmek anlamına gelmez. En sağlıklı yol, ana uygulamayı yerinde bırakıp yalnızca acıyan parçayı ayırmaktır. Bu yaklaşım seni tek hamlede on iki servisli bir sisteme mahkûm etmez ve her adımda geri dönebilirsin.

# Tek bileşeni ayırmak: ana uygulama duruyor, yalnızca ağır iş ayrıldı
services:
  uygulama:
    image: registry.firmaniz.com/app:2.3.0
    environment:
      RAPOR_SERVISI_URL: http://rapor:8080
      RAPOR_ZAMAN_ASIMI_MS: "2000"    # sınır: yavaşlık yayılmasın
    depends_on: [db, rapor]

  rapor:
    image: registry.firmaniz.com/rapor:1.0.4
    deploy:
      replicas: 3        # yalnızca bu bileşen ayrı ölçekleniyor

  db:
    image: postgres:16
    volumes:
      - dbdata:/var/lib/postgresql/data

volumes:
  dbdata:

Mikroservisin Gizli Maliyetleri#

Mikroservise geçen ekiplerin çoğu, kod bölme işini tahmin ettikleri sürede bitirir ve ardından hiç hesaba katmadıkları bir maliyetle karşılaşır. Bunlar teknik olarak çözülebilir sorunlardır ama her biri zaman ve süregelen bakım ister.

Ağ, güvenilmez bir çağrı yöntemidir. Monolitteki hesapla() fonksiyonu her zaman döner; ağ üzerinden yapılan aynı çağrı zaman aşımına uğrayabilir, yarıda kesilebilir ya da yavaşlayarak çağıranı da kilitleyebilir. Her servis çağrısına zaman aşımı, yeniden deneme ve devre kesici mantığı yazman gerekir. Zaman aşımı koymayı unutulan tek bir çağrı, bir servisin yavaşlamasını tüm sisteme yayar.

Veri artık tek yerde değildir. Monolitte iki tabloyu tek bir işlemle güncelleyip tutarlılığı garanti edersin. İki servise bölündüğünde bu garanti kaybolur; "sipariş oluştu ama stok düşmedi" durumunu ele alan telafi mantığını sen yazmak zorunda kalırsın.

Hata ayıklama zorlaşır. Tek yığın izi yerine dört servise dağılmış parçalar vardır. Bağıntı kimliği (correlation id) her isteğe eklenmeli ve tüm servisler onu loglarına yazmalıdır; yoksa bir kullanıcının şikâyetini izlemek imkânsız hale gelir.

Yerel geliştirme karmaşıklaşır. Tek uygulamayı çalıştırmak yerine yedi servisi ve bağımlılıklarını ayağa kaldırman gerekir. Docker Compose bunu yönetilebilir kılar ama makine kaynağı ve kurulum süresi yine de artar.

Operasyonel yük servis sayısıyla çarpılır. Her servis için yayın hattı, izleme, alarm, log toplama ve nöbet kapsamı gerekir. Bu yükü karşılayamayan ekiplerde servisler zamanla bakımsız kalır. Güvenilirliği ölçülebilir kılmak için SLO ve hata bütçesi yaklaşımı burada neredeyse zorunlu hale gelir.

Dağıtık Monolit: En Kötü İkisi#

En sık düşülen tuzak, sistemi servislere bölüp bağımsızlığı sağlayamamaktır. Ortaya çıkan yapıya dağıtık monolit denir ve iki mimarinin de dezavantajlarını bir araya getirir: monolitin sıkı bağlılığı ile mikroservisin ağ karmaşıklığı aynı anda oradadır, avantajların hiçbiri yoktur.

Bu duruma düştüğünü gösteren belirtiler nettir:

Üçüncü satır en belirleyicisidir. İki servis aynı tabloya yazıyorsa şema değişikliği ikisini birden etkiler, yani bağımsız yayın imkânsızdır. Mikroservisin tanımı gereği her servis kendi verisinin tek sahibidir ve diğerleri o veriye yalnızca o servisin arayüzü üzerinden erişir. Bu kural çiğnendiği anda elde kalan şey, ağ üzerinden konuşan bir monolittir.

Bu tabloya düşmenin en yaygın sebebi, bölmeye teknik katmanlardan başlamaktır: "veri servisi", "iş mantığı servisi", "arayüz servisi". Bu bölme her özellik değişikliğinde üç servise dokunmayı gerektirir. Doğru bölme iş alanlarına göredir: sipariş, ödeme, kargo, kullanıcı. O zaman bir özellik çoğunlukla tek servis içinde kalır.

Modüler Monolit: Ortadaki Yol#

Son yıllarda giderek yaygınlaşan yaklaşım, mikroservisin disiplinini monolitin sadeliğiyle birleştirmektir. Modüler monolitte tek bir uygulama yayınlarsın ama kod, net sınırları olan modüllere ayrılır: her modülün kendi arayüzü vardır, diğerlerinin iç yapısına erişemez ve tercihen kendi tablolarına sahiptir.

src/
  siparis/          # yalnızca kendi tablolarını okur
    api.ts          # dışarıya AÇIK arayüz
    dahili/         # dışarıdan erişilemez
  odeme/
    api.ts
    dahili/
  kargo/
    api.ts
    dahili/
  paylasilan/       # yalnızca gerçekten ortak olan şeyler

Kural şudur: bir modül başka bir modülün yalnızca api katmanını çağırabilir, dahili klasörüne asla dokunamaz. Bu kuralı incelemeye bırakmak yeterli değildir; otomatik olarak zorlamak gerekir. En basit haliyle bir CI kontrolü bile işe yarar:

# Bir modülün başka modülün dahili klasörüne erişimini yasakla
if grep -rn --include='*.ts' -E "from ['\"].*/(siparis|odeme|kargo)/dahili" src/ \
   | grep -v -E "^src/(siparis|odeme|kargo)/"; then
  echo "HATA: modül sınırı ihlali — yalnızca api katmanı çağrılabilir" >&2
  exit 1
fi

Modüler monolitin en büyük getirisi, kararı ertelemene izin vermesidir. Sınırlar kodda net olduğu için, ileride bir modülü gerçekten ayırman gerektiğinde iş, dolanmış bir kod tabanını sökmek değil, zaten belirli olan sınırı ağ üzerinden geçirmek olur. Alan bilgisi olgunlaşana kadar en düşük riskli yol budur.

Geçiş Kararını Nasıl Vermelisin#

Kararı sezgiye değil birkaç somut göstergeye bağla. Aşağıdaki soruların cevapları, hangi yöne gitmen gerektiğini fikirden bağımsız olarak gösterir.

1. Ekipler birbirini bekliyor mu? Yayın kuyruğu ve birleştirme çakışmaları günlük iş akışını gerçekten bozuyorsa örgütsel bir sınıra gelmişsindir.
2. Ölçek sorunu tek bir bileşende mi yoğunlaşıyor? Öyleyse tümünü bölme, o bileşeni ayır.
3. Alan sınırların net mi? Son altı ayda hangi işlevin nereye ait olduğu tartışıldıysa, sınırlar henüz oturmamıştır; bölme erken olur.
4. Operasyonel kapasiten var mı? Servis başına izleme, alarm, yayın hattı ve nöbet kapsamı sağlayamıyorsan, servis sayısını artırmak güvenilirliği düşürür.
5. Şu anki acın ne? "Mikroservis daha modern" bir acı değildir. Yavaş yayın, birbirini bekleyen ekipler, orantısız kaynak tüketimi acıdır.

Karar verdiysen geçişi tek hamlede yapma. En düşük riskli yöntem, monolitin önüne bir yönlendirme katmanı koyup belirli yolları yeni servise taşımak ve trafiği kademeli çevirmektir:

# Yalnızca /rapor yolu yeni servise, gerisi monolite
location /rapor/ {
    proxy_pass http://rapor_servisi;
    proxy_connect_timeout 2s;
    proxy_read_timeout 10s;
    # Yeni servis hata verirse monolite geri düş
    proxy_intercept_errors on;
    error_page 502 503 504 = @monolit;
}

location @monolit {
    proxy_pass http://monolit;
}

location / {
    proxy_pass http://monolit;
}

Bu yapı sana geri dönüş imkânı bırakır: yeni servis beklediğin gibi davranmazsa yönlendirmeyi kaldırırsın ve sistem çalışmaya devam eder. Aynı kademeli açma mantığını bir bayrakla da yönetebilirsin; feature flag ile güvenli yayın yazısında bunun nasıl kurulduğunu anlattım.

Sıkça Sorulan Sorular#

Küçük bir ekip için mikroservis mantıklı mı#

Genellikle değil. Beş kişilik bir ekipte servis sayısı arttıkça her kişiye düşen operasyonel yük hızla büyür ve asıl kazanç olan ekip bağımsızlığı zaten yoktur, çünkü herkes her yere dokunuyordur. Bu ölçekte doğru cevap iyi modüllere ayrılmış tek bir uygulamadır; gerçekten farklı ölçeklenen bir bileşen varsa yalnızca onu ayırmak yeterlidir.

Mikroservis performansı artırır mı#

Doğrudan artırmaz, çoğu durumda tek bir isteğin gecikmesini az da olsa artırır, çünkü fonksiyon çağrısının yerini ağ çağrısı alır. Kazanç, darboğaz oluşturan bileşeni bağımsız ölçekleyebilmektir. Yani sistem genelinde kapasiteyi artırırsın ama tek isteğin yolculuğu kısalmaz; bu ayrım karar verirken önemlidir.

Monolitten mikroservise nasıl geçilir#

Tek hamlede değil, parça parça. En sık kullanılan yöntem, monolitin önüne bir yönlendirme katmanı koyup belirli yolları yeni servise aktarmak ve trafiği kademeli çevirmektir. İlk ayrılacak parça olarak en az bağımlılığı olan ve en çok acı veren bileşeni seç; veriyi de birlikte taşımayı planla, çünkü tabloyu paylaşmaya devam edersen bağımsızlık sağlanmaz.

Servisler arasında veritabanı paylaşılabilir mi#

Teknik olarak mümkündür ama yaptığın an mikroservis olmaktan çıkarsın. Ortak tablo, şema değişikliğini tüm paylaşan servisleri etkileyen bir olaya çevirir ve bağımsız yayını imkânsız kılar. Bir servisin başka bir servisin verisine ihtiyacı varsa, ya o servisin arayüzünden istemeli ya da ihtiyacı olan alt kümenin kendi kopyasını olay akışıyla tutmalıdır.

Kaç servis fazla sayılır#

Sabit bir sayı yok ama pratik bir ölçüt var: her servisin bakımından sorumlu, o servisi tanıyan bir sahibi olmalı. Servis sayısı ekip sayısını belirgin biçimde aşıyorsa sahipsiz servisler ortaya çıkar ve bunlar zamanla güncellenmeyen, kimsenin dokunmak istemediği riskli parçalara dönüşür. Servis sayısını değil, taşıyabildiğin operasyonel yükü ölçüt al.

Modüler monolit gerçekten bir çözüm mü#

Evet ve çoğu ekip için en isabetli başlangıç noktasıdır. Mikroservisin sınır disiplinini kazanırsın ama ağ, dağıtık tutarlılık ve çoklu yayın hattı maliyetini ödemezsin. Üstelik ileride bir modülü gerçekten ayırman gerektiğinde iş çok daha kolay olur, çünkü sınır zaten çizilmiştir. Tek şart, modül sınırlarını otomatik bir kontrolle zorlamandır; yalnızca iyi niyete bırakılan sınırlar zamanla erir.

Kapanış#

Bu kararı verirken aklında tutman gereken şey şu: mikroservis bir hedef değil, belirli bir sorunun bedeli ağır bir çözümüdür. Ekipler birbirini bekliyorsa, tek bir bileşen orantısız ölçekleniyorsa ve bu yükü işletecek operasyonel kapasiten varsa anlamlıdır. Bunlar yoksa iyi modüllere ayrılmış tek bir uygulama hem daha hızlı geliştirilir hem daha kolay işletilir. Sınırları kodda net tut, gerektiğinde tek bir parçayı ayır ve her adımda geri dönebileceğin bir yol bırak.

Hangi mimariyi seçersen seç, üzerinde çalıştıracağın altyapının esnek olması gerekir: tek uygulamayı rahatça çalıştıracağın VDS paketlerinden başlayabilir, servis sayısı arttıkça kaynağı esnetebileceğin bulut sunucu çözümüne geçebilirsin. Yalnızca web uygulaması çalıştıracaksan kurumsal hosting paketlerimiz de yeterli olur; işletim, izleme ve güncelleme yükünü devretmek istersen sunucu yönetimi hizmetimize göz atabilirsin.