Monolit uygulama mikroservislere adım adım nasıl ayrıştırılır

Geçişe karar vermeden önce sorulacak sorular

Monolitten mikroservise geçiş, kodu parçalara bölmekten önce bir karar sorunudur. Monolit yavaş yayına çıkıyor, ekipler birbirinin kodunu bozuyor ya da bir modülün ölçeklenmesi için tüm uygulamayı kopyalamak gerekiyor diye hemen bölmek doğru değildir. Önce acının kaynağını ayırın: sorun mimariden mi, yoksa test eksikliğinden, yayın sürecinden ya da ekip yapısından mı geliyor? İyi modüllere ayrılmış bir monolit çoğu zaman yeterli çözümdür ve dağıtık sistemin getirdiği ağ gecikmesi, tutarsızlık ve operasyon yükünü hiç taşımaz.

Geçişi haklı kılan işaretler genellikle şunlardır: • Farklı ekipler aynı kod tabanında sürekli çakışıyor ve yayın takvimi birbirine bağımlı. • Sistemin yalnızca küçük bir bölümü yoğun yük alıyor ve onu ayrı ölçeklemek gerekiyor. • Bazı bölümler farklı teknoloji ya da farklı değişim hızı istiyor. • Bir hata tüm uygulamayı düşürüyor ve etki alanı daraltılmak isteniyor.

Bu işaretlerin hiçbiri yoksa geçiş maliyeti kazancı aşabilir. Karar aşamasında ekibin hazırlığını da değerlendirin: otomatik test, sürekli entegrasyon hattı, izleme ve günlük toplama altyapısı olmadan servis sayısını artırmak sorunları çoğaltır.

Servis sınırları nasıl belirlenir?

Geçişin en kritik adımı, servislerin nereden bölüneceğini bulmaktır. Yanlış çizilen sınır, servisler arasında sürekli çağrı ve ortak veri ihtiyacı doğurur; sonuçta dağıtık bir monolit ortaya çıkar. Sınırları teknik katmanlara (arayüz, iş mantığı, veri erişimi) göre değil, iş yeteneklerine göre çizin: sipariş, ödeme, stok, müşteri profili gibi.

Bu iş için alan odaklı tasarımdaki sınırlı bağlam (bounded context) kavramı yaygın kullanılır. Pratikte şu çalışma yapılır: iş uzmanlarıyla birlikte süreçler haritalanır, hangi kavramın hangi bölümde ne anlama geldiği netleştirilir (örneğin "müşteri" kavramı satışta başka, faturalamada başka alanlar taşır) ve bu anlam farklarının değiştiği yerler aday sınır olur. Koddaki bağımlılık grafiği de güçlü bir kanıttır: birlikte değişen sınıflar aynı serviste, nadiren birlikte değişenler ayrı serviste durmalıdır.

İlk adım için en az bağımlılığı olan, iş değeri net ve hata durumunda zararı sınırlı bir bölüm seçilir. Ödeme gibi kritik bir parçayla başlamak yerine bildirim, raporlama ya da kimlik doğrulama gibi kenar yetenekler genellikle iyi bir deneme alanıdır.

Kademeli ayrıştırma teknikleri

Başarılı geçişler büyük patlama yeniden yazımıyla değil, kademeli ilerleyerek yapılır. En bilinen yöntem, yeni servisin eski sistemin çevresinde büyütülüp trafiğin adım adım ona yönlendirildiği boğucu asma (strangler fig) yaklaşımıdır. Uygulamada önüne bir yönlendirme katmanı, örneğin API ağ geçidi konur; belirli yollar yeni servise, geri kalanı monolite gider. Yeni servis stabil olduğunda ilgili kod monolitten silinir.

Sık kullanılan yardımcı teknikler: • Önce monolit içinde modül sınırlarını netleştirmek ve modüller arası çağrıları tek bir arayüze indirmek. • Yeni servisi önce gölge modda çalıştırıp çıktısını eski sistemle karşılaştırmak. • Özellik bayraklarıyla trafiği küçük bir kullanıcı grubundan başlatarak artırmak. • Eski sisteme geçişi koruyan bir anti-bozulma katmanı koyup yeni servisin eski modellerle kirlenmesini önlemek.

Her adımda geri dönüş yolu bırakın. Yönlendirmeyi eski sisteme çevirebildiğiniz sürece risk yönetilebilir kalır.

Veriyi ayrıştırmak neden en zor kısımdır?

Kod bölmek göreceli olarak kolaydır; zor olan ortak veritabanını bölmektir. Monolitte tablolar arası birleştirme ve tek işlemde tutarlılık alışkanlığı vardır. Servisler ayrılınca her servisin kendi verisinin sahibi olması gerekir; aksi halde ortak şema üzerinden gizli bağımlılık kalır.

Genel yol şudur: önce servisin kullandığı tabloları belirleyin, ardından başka servislerin o tablolara doğrudan eriştiği yerleri arayüz çağrısına çevirin. Sonra veriyi ayrı şemaya, en sonunda ayrı veritabanına taşıyın. Geçiş sürecinde eski ve yeni veri deposunu senkron tutmak için değişiklik veri yakalama ya da çift yazma gibi yöntemler kullanılır; her biri tutarsızlık riski taşıdığından yalnız geçici olmalıdır.

Birleştirme sorgularının yerini artık servis çağrıları ya da okuma için kopyalanmış veri alır. Birden fazla servisi kapsayan iş akışlarında tek işlemli tutarlılık yerine olaylarla yürüyen saga benzeri düzenler ve sonunda tutarlılık kabul edilir. Bu da iş tarafıyla konuşulması gereken bir karardır: örneğin sipariş kabul edildikten kısa süre sonra stok düşümünün görünmesi iş için kabul edilebilir mi?

Servisler arası iletişim ve operasyon

Servisler ayrıldığında iletişim biçimi artık tasarım kararıdır. Anlık yanıt gereken sorgularda eşzamanlı çağrı (REST, gRPC) uygundur; ancak zincirleme çağrılar gecikmeyi ve hata yayılımını büyütür. Bir olayın birden çok tarafı ilgilendirdiği durumlarda mesaj kuyruğu ya da olay akışı üzerinden eşzamansız iletişim bağımlılığı gevşetir. Zaman aşımı, yeniden deneme, devre kesici ve tekrar gönderilen isteğe karşı idempotent işlem tasarımı baştan düşünülmelidir.

Operasyon tarafında gereken asgari altyapı: • Servisler boyunca bir isteği izleyebilen dağıtık izleme ve ortak istek kimliği. • Merkezi günlük toplama ve servis bazlı sağlık göstergeleri. • Her servis için bağımsız yayın hattı ve sürüm uyumluluğu kuralları. • Sürüm değişikliklerinde eski istemcileri bozmayan sözleşme yönetimi.

Bu yetenekler yoksa geçişi ertelemek ve önce bunlara yatırım yapmak çoğu zaman daha sağlıklıdır.

Örnek bir geçiş akışı

Örneğin bir e-ticaret monoliti düşünelim: sipariş, stok, ödeme, kampanya ve bildirim modülleri tek uygulamada. Ekip yayın sıklığının düştüğünden ve kampanya dönemlerinde sistemin tamamının yavaşladığından yakınıyor.

Adımlar şöyle ilerleyebilir. Önce iş uzmanlarıyla yetenek haritası çıkarılır ve bildirim modülü en az bağımlılığı olan aday olarak seçilir. Monolit içinde bildirim kodu tek bir arayüzün arkasına alınır. Sonra bu arayüzün arkasına yeni bildirim servisi yazılır, gölge modda çalıştırılıp çıktıları eski modülle karşılaştırılır. Fark kalmayınca trafik özellik bayrağıyla küçük bir gruptan başlayarak yeni servise kaydırılır; eski kod silinir. Kampanya modülü için de benzer süreç işletilir; ancak yoğun yük bu modülden geldiği için servisi ayrı ölçeklenebilir olarak dağıtmak asıl kazancı verir. Sipariş ve ödeme gibi çekirdek alanlara en son, ekip tecrübe kazandıktan ve operasyon altyapısı oturduktan sonra geçilir.

Her aşamanın sonunda ölçüm yapın: yayın sıklığı, değişikliğin canlıya çıkma süresi, olay sayısı ve geri dönüş oranı geçişin gerçekten fayda sağlayıp sağlamadığını gösterir.

Sık yapılan hatalar

Geçişlerde tekrar eden hatalar şunlardır: tüm sistemi birden yeniden yazmaya girişmek, servisleri teknik katmanlara göre bölmek, ortak veritabanını bırakıp yalnız kodu ayırmak, çok küçük servisler üretip iletişim yükünü patlatmak ve izleme altyapısını sona bırakmak. Bir diğer hata, ekip yapısını değiştirmemektir: servis sahipliği net değilse servisler ayrılsa da bağımlılık ve bekleme sürer. Servisin yaşam döngüsünden sorumlu ekibi baştan belirleyin.

Mindset programlarında bu konu, karar çerçevesi ve hazırlık değerlendirmesinden alan analizine, kademeli ayrıştırma tekniklerinden veri ayrıştırma stratejilerine ve servisler arası entegrasyona uzanan modüllerle ele alınır; operasyon, ölçüm ve yol haritası da programın son modülünde yer alır.