Mikroservis ve Monolit Mimari: Farklar ve Doğru Seçim

İki mimarinin ortak zemini

Monolit mimaride uygulama tek bir dağıtım birimidir: kullanıcı arayüzüne hizmet eden katman, iş kuralları ve veri erişimi aynı kod tabanında derlenir, tek süreç olarak çalışır ve genellikle tek bir veritabanını paylaşır. Siparişte küçük bir değişiklik bile bütün uygulamanın yeniden derlenip yeniden dağıtılmasını gerektirir.

Mikroservis mimarisinde ise uygulama, her biri kendi sürecinde çalışan, bağımsız olarak dağıtılabilen küçük servislerden oluşur. Martin Fowler ve James Lewis'in tanımında bu servisler iş yeteneklerine göre ayrılır, birbirleriyle HTTP tabanlı API'ler ya da mesajlaşma gibi hafif yollarla konuşur ve her biri kendi verisini yönetir.

İkisi de aynı amaca hizmet eder: iş kurallarını çalışan yazılıma dönüştürmek. İyi tasarlanmış bir monolit de modüllere ayrılmıştır; fark, modüller arasındaki sınırın bir fonksiyon çağrısı mı yoksa ağ üzerinden yapılan bir çağrı mı olduğudur. Bu tek fark, test, dağıtım, veri tutarlılığı ve ekip organizasyonunda zincirleme sonuçlar doğurur.

Temel farklar: ölçüt ölçüt

• Dağıtım: Monolit / tek paket, tek yayın; küçük bir değişiklik tüm uygulamayı yeniden yayınlatır. Mikroservis / her servis kendi takviminde yayınlanır; ödeme servisindeki düzeltme katalog servisini beklemez.
• Ölçekleme: Monolit / uygulamanın tamamı çoğaltılır, yoğunluk yalnız bir modülde olsa bile. Mikroservis / yalnız yük altındaki servis çoğaltılır.
• Veri: Monolit / genellikle tek veritabanı; tablolar arası birleştirme ve işlem bütünlüğü kolaydır. Mikroservis / her servisin kendi verisi vardır; servisler arası tutarlılık çoğu zaman nihai tutarlılık ve telafi adımlarıyla sağlanır.
• Hata davranışı: Monolit / bir modüldeki bellek sızıntısı bütün süreci düşürebilir. Mikroservis / hata tek servisle sınırlı kalabilir, ama zincirleme çağrılarda bir servisin yavaşlığı diğerlerine yayılır; zaman aşımı ve devre kesici gibi desenler gerekir.
• Teknoloji: Monolit / tek dil ve çatı. Mikroservis / servis başına farklı dil ya da veritabanı seçilebilir; bu özgürlük bakım yükünü de çoğaltır.
• Test ve hata ayıklama: Monolit / uçtan uca test tek uygulamada çalışır, hata ayıklayıcı tek süreçte ilerler. Mikroservis / bir isteğin izini sürmek için dağıtık izleme, merkezi log ve korelasyon kimliği gerekir.
• Ekip yapısı: Monolit / ekipler aynı kod tabanında çalışır, birleştirme ve sürüm koordinasyonu artar. Mikroservis / her servisin sahibi bir ekiptir; ekip kendi servisini geliştirir ve işletir.
• İşletme yükü: Monolit / tek dağıtım hattı, tek izleme ekranı. Mikroservis / konteyner orkestrasyonu, servis keşfi, API geçidi, servis başına dağıtım hattı ve gözlemlenebilirlik altyapısı gerekir.

Monolit hangi durumda doğru seçimdir?

Ürün yeniyse, iş alanı henüz netleşmemişse ve ekip küçükse monolit çoğu zaman daha hızlı ilerletir. Fowler'ın “önce monolit” yaklaşımı tam olarak bu gerekçeye dayanır: servis sınırlarını baştan doğru çizmek zordur, sınırları servisler arasında taşımak ise bir kod tabanı içinde taşımaktan çok daha pahalıdır.

• Ürün-pazar uyumu aranırken hızlı deney yapmak gerekiyorsa
• Tek bir ekip uygulamanın tamamından sorumluysa
• İş kuralları sıkı işlem bütünlüğü istiyorsa, örneğin stok düşümü ile siparişin aynı anda kesinleşmesi
• Kurumda konteyner, otomatik dağıtım ve izleme altyapısı henüz olgun değilse

Burada kritik nokta “modüler monolit” kurmaktır. Örneğin bir e-ticaret uygulamasında katalog, sepet, ödeme ve kargo modülleri aynı uygulamada durur ama birbirlerinin tablolarına doğrudan erişmez, yalnız tanımlı arayüzler üzerinden konuşur. Bu disiplin korunursa ileride bir modülü servise ayırmak mümkün olur; korunmazsa kod “büyük çamur topu” haline gelir ve ayrıştırılamaz.

Mikroservis hangi durumda öne çıkar?

Mikroservis, teknik bir tercih olmaktan çok örgütsel bir ölçek sorununa yanıttır. Birden fazla ekip aynı kod tabanında birbirini bekliyorsa, yayın takvimleri sürekli çakışıyorsa ve uygulamanın belirli bölümleri çok farklı yük profillerine sahipse bağımsız servisler gerçek kazanç sağlar.

• Farklı iş alanlarına ayrılmış, kendi yayın ritmine ihtiyaç duyan birden fazla ekip varsa
• Bir bölüm, örneğin arama ya da bildirim, diğerlerinden çok daha yoğun yük alıyorsa
• Bir bölümün arızasının tüm sistemi durdurması kabul edilemiyorsa
• Kurumda otomatik test, sürekli teslimat ve izleme kültürü yerleşmişse

Bu koşullar yoksa mikroservis, monolitin sorunlarını çözmeden ağ gecikmesi, dağıtık veri tutarlılığı ve işletme yükü gibi yeni sorunlar ekler. Sık görülen sonuç “dağıtık monolit”tir: servisler ayrı dağıtılıyor gibi görünür ama birlikte yayınlanmak zorundadır, çünkü aynı veritabanını paylaşırlar ya da birbirlerinin iç yapısına bağımlıdırlar.

Karar ölçütleri: kendinize sormanız gereken sorular

Mimari seçimi moda ya da teknoloji merakı üzerinden değil, somut sorular üzerinden yapın.

• Ekip sayısı ve sınırları: Uygulamayı geliştiren ekipler birbirinin değişikliğini bekliyor mu?
• Alan sınırları: İş alanında birbirinden bağımsız değişen bölümler net olarak görülebiliyor mu? Alan Odaklı Tasarım'daki sınırlı bağlam (bounded context) çalışması bu soruya yanıt verir.
• Veri bağımlılığı: Bölümler aynı verilere yoğun biçimde yazıyor mu? Yazıyorsa ayrıştırma pahalı olur.
• İşletme olgunluğu: Konteyner orkestrasyonu, merkezi log, metrik ve dağıtık izleme kurulu mu?
• Yük profili: Ölçekleme ihtiyacı uygulamanın tamamında mı, yoksa belirli bölümlerde mi?
• Değişim hızı: Hangi bölümler sık değişiyor, hangileri yıllardır dokunulmadan duruyor?

Yanıtların çoğu monolitten yanaysa modüler monolitle devam etmek ve modül sınırlarını sıkılaştırmak akılcıdır. Yanıtlar karışıksa ilk adım bütün sistemi bölmek değil, en çok sorun çıkaran tek bir bölümü ayırmaktır.

Monolitten mikroservise kademeli geçiş

Var olan bir monoliti tek seferde yeniden yazmak yüksek risklidir. Yaygın yaklaşım, Strangler Fig deseniyle kademeli ayrıştırmadır: monolitin önüne bir yönlendirme katmanı konur, yeni servis devreye girdikçe ilgili istekler ona yönlendirilir ve eski kod parça parça emekliye ayrılır.

Örnek bir akış şöyle ilerler: • Alan analizi yapılır ve bağımsız değişen bölümler belirlenir • İlk dilim olarak riski düşük ama değeri görünür bir bölüm seçilir, örneğin bildirim gönderimi • Monolitin önüne yönlendirme katmanı ya da API geçidi konur • Yeni servis yazılır, kendi veri deposu oluşturulur ve veri taşınır • Trafik kademeli olarak yeni servise aktarılır, metrik ve loglar karşılaştırılır • Monolitteki eski kod kaldırılır ve bir sonraki dilime geçilir

Sık yapılan hatalar arasında veritabanını ayırmadan servisleri ayırmak, servisleri teknik katmanlara göre bölmek (bir “veritabanı servisi”, bir “iş kuralı servisi”), gözlemlenebilirlik altyapısını sonraya bırakmak ve servisler arasında uzun senkron çağrı zincirleri kurmak yer alır.

Mindset programlarında bu konular

Mikroservis Mimarisi programı servis sınırlarını çizme, servisler arası iletişim, veri yönetimi ve tutarlılık, dayanıklılık desenleri, API geçidi ve servis ağı ile gözlemlenebilirlik başlıklarını ele alır. Monolittan Mikroservise Geçiş Stratejisi programı ise karar çerçevesi ve hazırlık değerlendirmesiyle başlar, alan analizi, kademeli ayrıştırma teknikleri ve veri ayrıştırma stratejileriyle devam eder.

Kademeli geçişi ayrıntılı çalışmak isteyenler için Strangler Fig ile Monolitten Mikroservise Kademeli Geçiş programı yönlendirme katmanı, cephe deseni ve ilk dilim seçimini işler. Servis sınırlarının temelini oluşturan sınırlı bağlam ve dil birliği kavramları Domain-Driven Design (DDD) Temelleri programında yer alır.