Mikroservis mi, modüler monolit mi? Sınırı çizmek için pratik bir çerçeve

Bir ürün büyümeye başladığında mimari tartışması genellikle aynı cümleyle açılır: “Bunu mikroservislere ayırmalı mıyız?” Soru yerindedir, ancak tek başına eksiktir. Çünkü mikroservis, klasörleri çoğaltan bir kod organizasyonu değil; dağıtım, veri sahipliği, gözlemlenebilirlik ve ekip çalışması için yeni bir işletim modelidir.

Bu nedenle doğru başlangıç noktası “kaç servisimiz olmalı?” değildir. Daha faydalı soru şudur: Hangi iş alanı, diğerlerinden bağımsız değişmeye ve çalışmaya gerçekten hazır? Cevap net değilse, modüler bir monolit çoğu zaman daha hızlı, daha anlaşılır ve daha geri alınabilir bir ilk adımdır.

Modüler monolit neyi çözer?

Modüler monolit, tek bir dağıtılabilir uygulama içinde açık sınırları olan alan modülleri kurar. Kimlik, arama, sipariş, bildirim ya da doküman yönetimi gibi alanların her biri kendi uygulama kurallarına ve mümkün olduğunca kendi veri erişimine sahiptir. Modüller arası çağrılar, rastgele tablo erişimi yerine tanımlı arayüzlerden yapılır.

Buradaki “monolit” kelimesi dağınık bir kod tabanı anlamına gelmez. Hedef; tek deploy kolaylığını korurken, ileride ayrıştırılabilecek sınırları şimdiden görünür kılmaktır. Aynı süreçte çalışan iki modül arasında ağ gecikmesi, sürüm uyumsuzluğu veya dağıtık işlem maliyeti yoktur. Buna karşılık sınır ihlalleri erken fark edilmezse modülerlik zamanla sadece klasör yapısına dönüşür.

Bu yüzden modüler monolit, mimari kararı ertelemek değil; kararı daha iyi kanıtla vermek için alan açmaktır.

Servis sınırını belirleyen beş soru

Bir modülü bağımsız servise dönüştürmeden önce aşağıdaki sorulara somut örneklerle cevap vermek gerekir.

1. İş kuralının sahibi belli mi?

Bir servis tek bir teknik katmanı değil, anlamlı bir iş yeteneğini sahiplenmelidir. Örneğin “bildirim” modülü e-posta gönderme kodundan ibaret değildir; teslimat tercihleri, tekrar deneme kuralları, şablonlar ve gönderim geçmişi gibi kendi kurallarına sahiptir. Buna karşılık “ortak yardımcılar” veya “veritabanı erişimi” genellikle servis sınırı değildir.

İsimlendirme iyi bir testtir: Sınırı bir fiil ya da iş sonucu ile anlatmak mümkün mü? Mümkün değilse, ayrıştırılan şey muhtemelen henüz bir alan değildir.

2. Veri sahipliği paylaşılmadan kurulabilir mi?

Mikroservislerde en zor karar genellikle ağ değil veridir. Her servis kendi verisinin sahibi olmalıdır; başka bir servisin tablolarına doğrudan yazmak, dağıtık monolitin en kısa yoludur. Birden fazla alanın aynı kaydı aynı işlem içinde değiştirmesi gerekiyorsa, önce bu işlemin gerçekten tek adımda tamamlanması gerekip gerekmediğini anlamak gerekir.

Bazı akışlarda nihai tutarlılık kabul edilebilir. Örneğin bir kayıt oluşturulduktan sonra arama indeksinin veya bildirimin birkaç saniye sonra güncellenmesi kullanıcı deneyimini bozmayabilir. Buna karşılık kimlik, yetkilendirme ya da parasal durum gibi alanlarda tutarlılık beklentisi daha yüksek olabilir. Kararı teknoloji tercihi değil, işin hata toleransı belirlemelidir.

3. Değişim hızı gerçekten farklı mı?

İki modül aynı sürümle, aynı ekip tarafından ve aynı sıklıkta değişiyorsa onları ayırmak dağıtım hızını artırmayabilir. Ayrı bir servis ancak kendi sürüm ritmine, kendi risk profiline veya bağımsız yayın ihtiyacına sahipse anlamlıdır.

Bu noktada tahmin yerine geçmişe bakmak faydalıdır: Son birkaç sürümde hangi alan değişti? Hangi değişiklikler diğer modüllerin testini, derlemesini veya yayını bekledi? Ayrı bir yayın takvimi ihtiyacı düzenli biçimde görünmüyorsa, servis sınırı henüz olgunlaşmamış olabilir.

4. Ölçek ve hata yalıtımı gerçek bir ihtiyaç mı?

Bir modülün diğerlerinden çok daha fazla CPU, bellek veya ağ kullanması iyi bir ayrıştırma işaretidir. Ancak “ileride çok büyür” varsayımı tek başına yeterli değildir. Önce ölçüm, darboğaz ve maliyet görünür olmalıdır.

Benzer şekilde hata yalıtımı da somut senaryolara dayanmalıdır. Ağır bir raporlama işi geciktiğinde oturum açma akışını etkiliyor mu? Dosya işleme kuyruğu geride kaldığında ana işlemler devam edebiliyor mu? Cevap evetse, bağımsız kaynak sınırları ve farklı ölçekleme politikaları değer üretebilir.

5. Ekip bu servisi çalıştırabilecek mi?

Her yeni servis; pipeline, yapılandırma, gizli anahtar yönetimi, sağlık kontrolü, loglama, metrik, trace, alarm ve sürüm uyumluluğu demektir. Bu yük çoğu zaman ilk geliştirme maliyetinden daha kalıcıdır. Küçük bir ekipte üç ayrı servis için üç ayrı operasyon yüzeyi yaratmak, iş kuralı kazanımını kolayca gölgede bırakabilir.

Bu nedenle servis sayısı ekip sahipliğiyle birlikte büyümelidir. Bir sınırın teknik olarak mümkün olması, onu bugün ayırmanın ekonomik olduğu anlamına gelmez.

Ayrıştırmaya hazırlanmak için beklemek gerekmez

Modüler monolit seçmek, gelecekteki servislere kapıyı kapatmaz. Tam tersine, doğru uygulandığında güvenli bir çıkarma hattı oluşturur:

• Modülün dışarıya sunduğu komutları ve sorguları açık arayüzlerde toplayın.
• Başka modüllerin iç veriye erişmesini engelleyin; ihtiyaç duyulan bilgiyi sahip modül sunsun.
• Alan olaylarını iş kuralının yanında tanımlayın; olay yayınını güvenilir kılmak için outbox gibi desenleri değerlendirin.
• İzleme, kimlik doğrulama ve hata sözleşmelerini tüm uygulamada tutarlı hale getirin.
• Ayrıştırma günü geldiğinde önce bir okuyucu veya asenkron tüketiciyle başlayın; kritik bir işlemi tek seferde dağıtık hale getirmeyin.

Bu hazırlıkların değeri yalnızca gelecekte mikroservise geçmek değildir. Tek uygulamada bile bağımlılıkları azaltır, testleri kolaylaştırır ve yeni geliştiricilerin alanı anlamasını hızlandırır.

Kararı yeniden gözden geçirmek için sinyaller

Mimari karar kalıcı bir etiket olmamalı. Aşağıdaki sinyaller düzenli hâle geldiğinde servisleşmeyi tekrar değerlendirmek anlamlıdır: ilgisiz değişikliklerin birbirini yayınlamayı engellemesi, bir modülün sürekli kaynak tüketiminde “gürültülü komşu” olması, ayrı erişim veya denetim gereksinimlerinin doğması ya da bir ekibin belirli bir alanın uçtan uca sahibi hâline gelmesi.

Bu sinyaller görülmeden mikroservise geçmek çoğu zaman dağıtık sistem sorunlarını erken satın almaktır. Görüldükten sonra geç kalmak ise modül sınırlarının yeterince görünür olmamasından kaynaklanır.

Sağlam yaklaşım bir mimariyi slogan olarak seçmek değil, her sınırı iş değeri ve operasyon maliyetiyle gerekçelendirmektir. Mikroservisler doğru sınırda güçlü bir araçtır; modüler monolit ise o sınırı bulmak için güvenli bir çalışma alanı sağlar.