Mikroservis Mimarisi Nedir? Monolit Farkı ve Ne Zaman Seçilmeli

Mikroservis mimarisi nedir?

Mikroservis mimarisi, bir uygulamayı her biri tek bir iş yeteneğini yürüten, bağımsız yayınlanabilen ve kendi verisine sahip küçük servislere bölme yaklaşımıdır. Servisler birbirleriyle ağ üzerinden, iyi tanımlı API'ler ve olaylar aracılığıyla konuşur. Böylece bir servisi değiştirmek için tüm uygulamayı yeniden yayınlamanız gerekmez.

Bir benzetmeyle düşünün. Monolit, her şeyin tek çatı altında satıldığı büyük bir mağazadır. Mikroservis ise her tezgâhın ayrı işletildiği bir çarşıdır. Çarşıda bir tezgâh kapansa bile diğerleri çalışır. Ancak çarşıyı yönetmek, tek bir mağazayı yönetmekten daha fazla koordinasyon ister.

Bu yazıda mikroservis mimarisi nedir sorusunu sade bir dille açıyoruz. Önce tanım ve karşılaştırmayı görecek, sonra avantajları ve bedelleri tartacaksınız. Ardından küçük ekipler için neden çoğu zaman erken olduğunu, geçişin nasıl yapılacağını ve karar öncesi kontrol listesini bulacaksınız.

Monolitle kıyasla mikroservis mimarisi nedir ve fark nerede başlar?

Monolit, tüm özelliklerin tek bir kod tabanında yazıldığı ve tek parça olarak yayınlandığı uygulamadır. Mikroservis mimarisi nedir sorusunun en kısa cevabı, bu tek parçayı bağımsız parçalara ayırmaktır. Aradaki üçüncü seçenek ise modüler monolittir. Kod tek parça yayınlanır, ama içeride net sınırlarla ayrılmış modüller vardır.

Tabloyu şöyle okuyun: Sol taraf basitlik, sağ taraf özerklik sağlar. Dolayısıyla soru hangisinin daha modern olduğu değil, hangisinin sizin ekibinize ve ürününüze uyduğudur.

Bir mikroservis tam olarak neyi kapsar?

Bir mikroservis, tek bir iş yeteneğini baştan sona üstlenen küçük bir programdır. Örneğin bir e-ticaret sisteminde sipariş, stok ve ödeme ayrı servisler olabilir. Her biri kendi kodunu, kendi veritabanını ve kendi yayın hattını taşır. Başka servisler onun içini görmez, yalnızca API'sini çağırır.

Servis sınırını belirlemek, mimarinin en zor kısmıdır. Microsoft'un Azure mimari rehberi, sınırları iş alanına göre çizmeyi önerir. Buradaki anahtar kavram sınırlı bağlamdır (bounded context). Yani bir iş alanında kelimelerin tek ve net anlam taşıdığı bölgedir. Sipariş servisindeki "müşteri" ile faturalama servisindeki "müşteri" aynı alanlara sahip olmak zorunda değildir.

Boyut için sihirli bir satır sayısı yoktur. Daha doğru ölçüt şudur: Bir servisi tek bir küçük ekip anlayabiliyor, yazabiliyor ve yayınlayabiliyor mu? Cevap evetse boyut büyük olasılıkla yerindedir.

Mikroservisler birbirleriyle nasıl konuşur?

Servisler iki temel yolla iletişim kurar: senkron ve asenkron. Senkron iletişimde bir servis diğerini doğrudan çağırır ve cevabı bekler. Asenkron iletişimde ise servis bir olay yayınlar, ilgilenen servisler bunu kendi hızlarında işler. İkisinin de yeri vardır.

Fowler'ın makalesi bu konuda "akıllı uç noktalar, aptal borular" ilkesini vurgular. Yani zekâ servislerin içinde durur, iletişim hattı ise basit kalır. Olay tabanlı yaklaşımı ayrıntılı anlattığımız event-driven mimari nedir yazısına göz atabilirsiniz.

Senkron tarafta REST dışında GraphQL gibi seçenekler de vardır. İstemcinin hangi alanları istediğini kendisinin belirlediği bu yaklaşımı GraphQL nedir ve REST ile farkı yazımızda anlattık.

API gateway ve servis keşfi ne işe yarar?

API gateway, istemcilerin tek giriş kapısıdır. İstemci onlarca servisin adresini bilmek yerine yalnızca gateway'e istek gönderir. Gateway isteği doğru servise yönlendirir. Ayrıca kimlik doğrulama, kayıt tutma ve yük dağıtımı gibi ortak işleri de üstlenir.

Servis keşfi (service discovery) ise başka bir sorunu çözer. Servisler sürekli açılıp kapanır, adresleri değişir. Bu yüzden bir servisin diğerini bulması için güncel bir adres defteri gerekir. Kubernetes gibi orkestrasyon platformları bu işi sizin için yapar. Resmi belgede servis kavramı ayrıntılı açıklanır.

Azure rehberi önemli bir uyarı da yapar: Gateway'e iş kuralı koymayın. Gateway yalnızca yönlendirme ve ortak işlerle ilgilenmelidir. İş mantığı içeri sızarsa gateway, servisleri birbirine bağlayan yeni bir darboğaza dönüşür.

Her servis neden kendi verisine sahip olmalı?

Servisler aynı veritabanını paylaşırsa bağımsızlık yalnızca görünürde kalır. Bir servis tablo yapısını değiştirdiğinde diğerleri bozulur. Bu nedenle mikroservis mimarisinde her servis kendi verisini kendisi saklar. Başkası bu veriye yalnızca servisin API'si üzerinden ulaşır.

Bu seçimin bedeli veri tutarlılığıdır. Tek veritabanında bir işlem ya tamamen olur ya hiç olmaz. Birden fazla servis söz konusu olduğunda ise bu garanti kolayca sağlanamaz. Bu yüzden son tutarlılık (eventual consistency) ile yaşamayı öğrenirsiniz. Yani veriler bir anlığına farklı olabilir, ama kısa sürede uyuşur.

Pratikte bu, çift işlemeye karşı dikkat gerektirir. Aynı mesaj iki kez gelirse sonuç değişmemelidir. Bu özelliği idempotency nedir yazısında ele aldık. Mikroservislerde neredeyse her entegrasyon bu ilkeye dayanır.

Veri paylaşımı gerektiğinde de iki yol vardır. Birincisi, ihtiyaç duyan servisin diğerine API üzerinden sormasıdır. İkincisi, olaylarla gelen verinin kendi tarafında küçük bir kopyasını tutmasıdır. Azure rehberi, veri kopyalamaktan her koşulda kaçınmanın yanlış olduğunu belirtir. Önemli olan, verinin tek sahibinin hep bilinmesidir.

Mikroservisin gerçek avantajları nelerdir?

Avantajlar gerçektir, ancak her biri belirli bir koşula bağlıdır. Azure rehberi ve Fowler'ın makalesi benzer maddeleri sayar. Aşağıdaki liste bunların özetidir:

• Bağımsız yayın: Bir servisi diğerlerini beklemeden yayınlarsınız, gerekirse geri alırsınız.
• Bağımsız ölçekleme: Yalnızca yoğun çalışan servise daha fazla kaynak verirsiniz.
• Ekip özerkliği: Küçük ekipler kendi servislerini baştan sona sahiplenir.
• Hata yalıtımı: Bir servis çökse bile uygulamanın geri kalanı çalışmaya devam edebilir.
• Teknoloji esnekliği: Her servis için işe en uygun dil veya veritabanını seçebilirsiniz.
• Küçük kod tabanı: Yeni bir geliştirici tek servisi daha kısa sürede kavrar.

Burada kritik nokta şudur: Bu faydalar ancak servis sınırları doğru çizildiğinde ortaya çıkar. Sınırlar yanlışsa avantajların yerini yalnızca ek maliyet alır.

Bağımsız ölçeklemeyi bir örnekle düşünün. Kampanya günlerinde yalnızca sipariş alma yoğunlaşır, raporlama ise sakin kalır. Monolitte tüm uygulamayı çoğaltmanız gerekir. Mikroservislerde sadece sipariş servisini çoğaltırsınız. Böylece kaynakları daha isabetli kullanır, gereksiz harcamayı azaltırsınız.

Mikroservisin gizli bedelleri nelerdir?

Her servis tek başına basittir, ama bütün sistem daha karmaşıktır. Fowler'ın ifadesiyle karmaşıklık yok olmaz, yer değiştirir. Eskiden kod içinde olan bağlantılar şimdi ağın üzerindedir ve ağ her zaman güvenilir değildir.

• Ağ hataları: Uzak çağrılar yavaşlayabilir, zaman aşımına uğrayabilir veya hiç dönmeyebilir.
• Veri tutarlılığı: Birden çok servisi kapsayan işlemler tek bir garantiyle güvence altına alınamaz.
• Test zorluğu: Bağımlı servisleri birlikte denemek, tek uygulamayı denemekten zordur.
• Sürümleme: Bir servisin API'sini değiştirirken onu kullananları bozmamanız gerekir.
• Operasyonel yük: Çok sayıda servisi yayınlamak, izlemek ve güncel tutmak ek emek ister.
• Beceri ihtiyacı: Ekibin dağıtık sistem deneyimi olması gerekir.

Mikroservis mimarisi nedir sorusunu cevaplarken bu bedelleri atlamak yanıltıcı olur. Bu liste mikroservisi kötülemek için değil, kararı dürüst vermek için yazıldı. Bedelleri karşılayabilecek bir ekip için tablo olumlu olabilir. Karşılayamayacak bir ekip içinse tek parça uygulama çoğu zaman daha güvenlidir.

Bedellerin bir kısmı görünür, bir kısmı sonradan ortaya çıkar. Örneğin ilk ay her şey yolunda gider, çünkü servis sayısı azdır. Servis sayısı arttıkça sürüm uyumsuzlukları, sürekli büyüyen yapılandırma dosyaları ve uzayan hata ayıklama süreleri belirginleşir. Bu yüzden erken aşamada standartlar koymak önemlidir.

Dağıtık sistemde izleme neden şarttır?

Tek uygulamada hata olduğunda tek bir günlüğe bakarsınız. Mikroservislerde ise bir kullanıcı isteği beş altı servisten geçebilir. Hatanın nerede çıktığını bulmak için isteği baştan sona izlemek gerekir. Bu yaklaşıma dağıtık izleme (distributed tracing) denir.

Merkezi günlük toplama, metrikler ve izler birlikte gözlemlenebilirliği (observability) oluşturur. Azure rehberi bu amaçla OpenTelemetry gibi ortak çerçevelerden söz eder. Konuyu observability ve OpenTelemetry nedir yazımızda ayrıca işledik.

İzleme olmadan mikroservise geçmek, ışıksız bir bodrumda çalışmaya benzer. Sorunun olduğunu hissedersiniz, ama nerede olduğunu göremezsiniz. Bu nedenle izleme altyapısını ilk servisle birlikte kurmanızı öneririz.

İzlenecek temel göstergeler basittir: istek sayısı, hata oranı ve cevap süresi. Her servis için bu üç gösterge bir panoda dursun. Anormal bir değişim gördüğünüzde uyarı almak, kullanıcıdan önce sorunu fark etmenizi sağlar. Ayrıca günlük kayıtlarına ortak bir biçim koymak, arama ve ilişkilendirmeyi çok kolaylaştırır.

Mikroservislerde yayın süreci nasıl işler?

Servis sayısı arttıkça elle yayın yapmak sürdürülemez olur. Her servisin kendi otomatik test ve yayın hattı olmalıdır. Böylece bir servisteki değişiklik, diğerlerinden bağımsız olarak üretime çıkar. Azure rehberi de CI/CD hatlarını temel bir uygulama olarak sayar.

Bu konuyu CI/CD nedir yazımızda sürekli entegrasyon ve sürekli teslimat başlıklarıyla anlattık. Kısacası otomatik yayın hattı kurmadan mikroservise geçmeyin. Bu hat, mimarinin çalışması için bir lüks değil, ön koşuldur.

Servisler arası uyum için sözleşme testleri de işe yarar. Yani bir servisin diğerinden ne beklediğini otomatik olarak doğrulayan testler yazarsınız. Böylece bir ekip kendi servisini değiştirirken, onu kullanan servisleri bozup bozmadığını yayından önce görür.

Yayın stratejisinde küçük adımlar da önemlidir. Yeni sürümü önce az sayıda kullanıcıya açmak ve sağlığı izlemek riski düşürür. Sorun görürseniz geri dönüş yolunuz hazır olmalıdır.

Servisleri hangi dille yazmalısınız?

Mikroservislerin vaatlerinden biri, her servis için farklı teknoloji seçebilmektir. Teoride özgürlük harikadır. Pratikte ise çok fazla dil ve çerçeve, bakımı zorlaştırır. Azure rehberi bu yüzden teknoloji seçimlerini sınırlamayı ve ortak standartlar koymayı önerir.

Örneğin bir ekip, ağırlıklı olarak tek bir dil kullanıp yalnızca gerçekten farklı ihtiyaçlarda ikinci bir dile yönelebilir. Python ile Go arasındaki seçimi arka uç ve mikroservis açısından Python ve Go karşılaştırması yazımızda ele aldık. Sonuçta dil seçimi, ekibin bilgisine ve işin doğasına bağlıdır.

Dil çeşitliliğini sınırlamanın bir başka nedeni de ekip esnekliğidir. Herkes aynı iki dili biliyorsa, geliştiriciler servisler arasında kolayca yer değiştirebilir. Farklı dilde yazılmış her servis ise küçük bir bilgi adasına dönüşebilir.

Ekip büyüklüğüne göre mikroservis mimarisi nedir, hangi durumda erken olur?

Mikroservis mimarisi nedir sorusunun dürüst bir cevabı da şudur: Bu, bir ekip örgütlenme çözümüdür. Mimari, çok sayıda ekibin birbirini beklemeden çalışabilmesi için doğmuştur. Tek bir küçük ekip için ise çoğu zaman gereksiz yük getirir.

Fowler monolitle başlamayı, onu modüler tutmayı ve sorun çıktığında parçalamayı önerir. Çünkü alan belirsizken çizilen servis sınırları genellikle yanlış çıkar. Sınırı yanlış çizilmiş bir servisi taşımak, bir modülü taşımaktan çok daha pahalıdır.

• Ekip küçükse ve herkes aynı kod tabanını rahatça anlıyorsa mikroservis erkendir.
• Ürünün iş alanı henüz oturmadıysa ve sık değişiyorsa mikroservis erkendir.
• Otomatik test, yayın hattı ve izleme yoksa mikroservis erkendir.
• Tek bir yayın, ekipleri birbirine kilitliyorsa mikroservis düşünülebilir.

Bu liste bir kural değil, bir sezgi çerçevesidir. Her projede tartmanız gereken ek unsurlar olabilir.

Unutmayın, monolit ile mikroservis arasında tek yönlü bir kapı yoktur. İyi yapılandırılmış bir monolit bugün işinizi görür, ihtiyaç doğduğunda parçalanabilir. Tersine, erken parçalanmış bir sistemi geri birleştirmek çok daha zahmetlidir.

Conway yasası ekip yapısını mimariye nasıl yansıtır?

Conway yasası, bir organizasyonun ürettiği sistemin o organizasyonun iletişim yapısını yansıttığını söyler. Fowler da makalesinde bu fikre dayanır. Ekipler katmanlara göre ayrılırsa, yani biri arayüz, biri sunucu, biri veritabanı yaparsa, her küçük değişiklik üç ekibin koordinasyonunu ister.

Mikroservis yaklaşımı bunun tersini önerir. Ekipler iş yeteneğine göre örgütlenir ve her ekip kendi servisini baştan sona sahiplenir. Böylece bir özelliği tek ekip tasarlar, yazar, yayınlar ve işletir. Karar süreleri kısalır, çünkü bekleme zinciri kopar.

Bu nedenle mikroservis mimarisi nedir sorusuna yalnızca teknik bir açıdan bakmayın. Organizasyon şemanız mimarinizin ilk taslağıdır. Ekipleriniz henüz bağımsız çalışacak olgunlukta değilse servisleri ayırmak yalnızca koordinasyon sorununu ağa taşır.

Mikroservise ne zaman geçmek mantıklıdır?

Geçiş için net sinyaller vardır. İlki, ekip sayısı arttıkça birbirinin yayınını engellemesidir. İkincisi, uygulamanın yalnızca bir bölümünün diğerlerinden çok daha fazla kaynak istemesidir. Üçüncüsü, farklı bölümlerin farklı sıklıkta ve farklı riskle değişmesidir.

Örnek senaryo: Bir mağaza uygulamasında ödeme modülü nadiren değişir ama çok hassastır. Kampanya ve vitrin modülü ise her hafta değişir. Bu iki bölümü aynı yayın döngüsüne bağlamak her ikisini de yavaşlatır. Bu durumda ödeme bölümünü ayırmak makul bir ilk adım olabilir.

Ayırmadan önce sorunu ölçün. Yayın bekleme sürelerini, hata kaynaklarını ve kaynak kullanımını inceleyin. Rakamlar sizi ikna etmiyorsa, belki sorun mimaride değil, süreçtedir. Çoğu zaman daha iyi bir test düzeni veya net kod sahipliği, mikroservise geçmeden de büyük rahatlık sağlar.

Dikkat edin, geçişin gerekçesi teknik moda değil, ölçülebilir bir acı olmalıdır. Acı yoksa mikroservis yalnızca bir maliyet kalemi ekler.

Monolitten mikroservise strangler fig ile nasıl geçersiniz?

Strangler fig (boğucu incir) deseni, eski sistemi bir kerede yıkmak yerine kademeli olarak değiştirmenizi sağlar. Adını, ağaçların üzerinde büyüyüp zamanla onların yerini alan asma bitkilerinden alır. Martin Fowler, bu metaforu eski sistemlerin modernizasyonu için kullanmıştır.

1. Eski uygulamanın önüne bir yönlendirme katmanı koyun.
2. Ayrılacak ilk bölümü seçin; düşük riskli ve sınırı net olan bir iş yeteneği ideal başlangıçtır.
3. Bu bölümü yeni bir servis olarak yazın ve yönlendirme katmanından trafiği ona verin.
4. Eski koddaki karşılığını devre dışı bırakın ve izleyin.
5. Tekrar eden bu adımlarla bölümleri tek tek taşıyın.
6. Eski uygulama küçülüp görevini bitirdiğinde onu kapatın.

Bu yöntemin gücü geri dönülebilir olmasıdır. Her adım küçük olduğundan sorun çıkarsa yönlendirmeyi eski yola çevirirsiniz. Böylece büyük patlama yerine sürekli ve kontrollü bir dönüşüm yaşarsınız.

İlk taşınacak bölümü seçerken şu soruyu sorun: Hangi parça az bağımlıdır ve ayrıldığında hızlıca fayda sağlar? Kimlik doğrulama, bildirim ya da raporlama gibi çevresel işler genellikle iyi adaylardır. Çekirdek iş mantığını ise deneyim kazandıktan sonra taşıyın.

Mikroservislerde sık yapılan hatalar nelerdir?

En yaygın hata, mikroservis görünümlü bir monolit kurmaktır. Buna dağıtık monolit denir. Servisler ayrı yayınlanır, ama birbirine o kadar bağlıdır ki biri değişince hepsi değişmek zorunda kalır. Sonuçta hem monolitin hem dağıtık sistemin sorunlarını birlikte yaşarsınız.

• Paylaşılan veritabanı: Servisler aynı tabloya yazarsa bağımsızlık kalmaz.
• Aşırı parçalama: Her küçük fonksiyonu servis yapmak ağ yükünü ve karmaşıklığı patlatır.
• Gevezelik eden API'ler: İki servis sürekli birbirini çağırıyorsa sınır yanlış olabilir.
• Ortak kütüphane bağımlılığı: Servisleri aynı paylaşılan koda bağlamak değişimi riskli kılar.
• Gateway'de iş mantığı: Giriş kapısı servislerin işini üstlenmemelidir.

Azure rehberi bu kalıpları kötü uygulamalar arasında sayar. Her birinin ortak noktası, ayrılması gereken şeyleri gizlice birbirine bağlamaktır.

Docker ve Kubernetes mikroservislerde nerede devreye girer?

Konteyner (container), bir servisi bağımlılıklarıyla birlikte paketleyen taşınabilir bir birimdir. Böylece servis her ortamda aynı şekilde çalışır. Docker bu paketlemenin en bilinen yoludur. Temelleri Docker nedir yazısında bulabilirsiniz.

Çok sayıda konteyneri elle yönetmek zordur. Orkestrasyon platformları bu işi üstlenir: servisleri makinelere dağıtır, çöken olanı yeniden başlatır ve yüke göre çoğaltır. Kubernetes bu alanın bilinen aracıdır. İkisinin farkını Kubernetes ve Docker farkı yazısında açıkladık.

Önemli bir uyarı: Mikroservis için Kubernetes zorunlu değildir. Küçük başlangıçlarda daha yalın barındırma seçenekleri yeterli olabilir. Altyapı karmaşıklığını, gerçek ihtiyacınızın önüne geçirmeyin.

Konteynerler ayrıca geliştirme ortamını da basitleştirir. Yeni bir geliştirici, servisin bağımlılıklarını elle kurmadan aynı ortamı kendi makinesinde çalıştırabilir. Böylece "bende çalışıyordu" tartışmaları azalır.

Mikroservislerde güvenlik ve kimlik doğrulama nasıl çalışır?

Servis sayısı arttıkça saldırı yüzeyi de genişler. Bu yüzden güvenliği tek bir noktaya yaslamak yerine katmanlı düşünmek gerekir. Gateway, istemci kimliğini doğrulayabilir. Servisler arası trafiği ise karşılıklı TLS (mTLS) gibi yöntemlerle şifrelemek mümkündür.

Kimlik bilgisini servisler arasında taşımanın yaygın yollarından biri imzalı belirteçlerdir. Bu yapıyı JWT nedir yazısında kavramsal olarak anlattık. Azure rehberi, belirteç doğrulamasını her servisin içine gömmek yerine özel bir bileşene devretmeyi önerir.

Kısa bir not: Bu bölüm genel bir çerçevedir. Kendi sisteminiz için tehdit modelini ve uyum gerekliliklerini uzmanlarla birlikte değerlendirmelisiniz.

Servis sınırlarını nasıl çizersiniz?

Sınır çizmenin en güvenilir yolu iş alanından başlamaktır. Önce şirketin gerçekte hangi yeteneklerden oluştuğunu yazın: sipariş alma, stok tutma, ödeme tahsil etme, bildirim gönderme gibi. Ardından her yeteneğin hangi veriye ihtiyaç duyduğunu ve hangi veriyi başkalarına açtığını işaretleyin.

Birlikte değişen şeyleri aynı serviste tutun. Azure rehberi bu ilkeyi yüksek işlevsel bağlılık olarak adlandırır. Yani bir değişiklik sürekli iki servisi birden etkiliyorsa, bu iki servis büyük olasılıkla tek servis olmalıdır. Öte yandan farklı hızlarda değişen bölümleri ayırmak mantıklıdır.

• Her servis için tek cümlelik bir sorumluluk tanımı yazabiliyor musunuz?
• Servisin verisine yalnızca kendisi yazıyor mu?
• Servisi bir ekip tek başına anlayıp yayınlayabilir mi?
• Servisler arasında sürekli ve yoğun bir konuşma var mı?

Son soruya evet cevabı, sınırın muhtemelen yanlış yerde olduğunu gösterir. Bu durumda servisleri birleştirmek, parçalamaktan daha doğru bir düzeltme olabilir.

Bir servis çöktüğünde sistem nasıl ayakta kalır?

Dağıtık sistemde arızaların olacağını baştan kabul edersiniz. Fowler bunu hataya karşı tasarım olarak anlatır: Uygulama, bağımlı olduğu bir servisin çökmesine dayanabilmelidir. Bunun için birkaç temel desen kullanırsınız.

• Zaman aşımı: Cevap gelmeyen bir çağrıyı sonsuza kadar beklemezsiniz.
• Yeniden deneme: Geçici hatalarda isteği kısa bir beklemeyle tekrarlarsınız.
• Devre kesici: Sürekli hata veren servisi bir süre çağırmayı bırakır, onu rahatlatırsınız.
• Yedek davranış: Servis yoksa basitleştirilmiş bir cevap veya önbellekteki veriyle devam edersiniz.

Ancak yeniden denemeyi dikkatsiz kullanmak, zaten yorulmuş bir servisi tamamen çökertebilir. Bu nedenle denemeleri sınırlayın ve aralarına bekleme koyun. Ayrıca tekrar eden isteklerin zararsız olması için işlemleri idempotent tasarlayın.

Bir sipariş akışı mikroservislerde nasıl işler?

Örnek senaryo ile somutlaştıralım. Bir çevrimiçi mağazada kullanıcı "siparişi tamamla" der. İstek önce gateway'e gelir, gateway de sipariş servisine yönlendirir. Sipariş servisi kaydı oluşturur ve bir "sipariş oluşturuldu" olayı yayınlar.

1. Stok servisi olayı alır ve ürünü ayırır.
2. Ödeme servisi tahsilatı dener ve sonucu olay olarak bildirir.
3. Bildirim servisi kullanıcıya onay mesajı gönderir.
4. Ödeme başarısız olursa sipariş servisi kaydı iptal eder, stok servisi ayırdığı ürünü serbest bırakır.

Gördüğünüz gibi hiçbir servis diğerinin veritabanına dokunmaz. Süreç olaylar üzerinden ilerler. Ancak son adımdaki telafi mantığı, tek veritabanı işleminin yaptığı geri almanın yerini alır. Bu telafi akışlarını baştan tasarlamak, mikroservisin en çok emek isteyen işlerinden biridir.

Bu akışı izlemek için her isteğe bir izleme kimliği eklenir. Böylece bir siparişin tüm servislerdeki yolculuğunu tek ekranda görebilirsiniz.

Mikroservis hangi komşu terimlerle karışır?

Mimari dünyasında birbirine benzeyen kavramlar çoktur. Aşağıdaki tablo, en sık karıştırılanları ayırır. Her birinin ayrıntısı için ilgili yazılara bakabilirsiniz.

Arayüz tarafındaki karşılığı merak ediyorsanız micro-frontend nedir yazısına bakabilirsiniz.

Karar vermeden önce hangi kontrol listesini uygulamalısınız?

Aşağıdaki sorulara dürüstçe cevap verin. Birkaç madde eksikse önce onları tamamlamak, doğrudan mikroservise atlamaktan daha akıllıcadır.

1. Çözmek istediğiniz ölçülebilir sorun nedir ve monolit içinde çözülemiyor mu?
2. Ürünün iş alanı ve servis sınırları yeterince oturdu mu?
3. Her servis için otomatik test ve yayın hattı kurabilecek misiniz?
4. Merkezi günlük, metrik ve dağıtık izleme hazır mı?
5. Her servisin kendi verisine sahip olmasını ve son tutarlılığı kabul ediyor musunuz?
6. Ekibin dağıtık sistem deneyimi var mı, yoksa öğrenme süresini bütçelediniz mi?
7. İlk adımı küçük ve geri alınabilir tutan bir geçiş planınız var mı?

Mikroservis mimarisi nedir sorusunu kendi projenize uyarladığınızda çoğu maddeye hayır diyorsanız, modüler monolit güçlü bir seçimdir. Sınırları kodda netleştirir, geçişi ileride kolaylaştırır ve bugün operasyon yükünüzü düşük tutar.

Sonuç olarak hangi yolu seçmelisiniz?

Özetle, mikroservis mimarisi nedir sorusunun cevabı bağımsız, küçük ve kendi verisine sahip servisler kümesidir. Bu yapı, çok ekipli ve hızlı değişen büyük sistemlerde parlar. Küçük ekiplerde ve belirsiz alanlarda ise çoğu zaman gereksiz bir yüktür.

Bu konular size yabancıysa endişelenmeyin. Yazılım mimarisi kararları net bir ihtiyaç analiziyle başlar. Talha Aslan ve ekibi olarak projenizin ölçeğine uygun mimariyi birlikte değerlendirmek için özel yazılım geliştirme hizmetimizi inceleyebilirsiniz. Bu yazı mühendislik danışmanlığı yerine geçmez, bağlamınıza göre karar verin.

Kaynak olarak Martin Fowler'ın Microservices makalesini, Microsoft Azure Architecture Center mikroservis rehberini ve Strangler Fig Application yazısını öneririz. Servis keşfi için Kubernetes resmi Service belgesine göz atabilirsiniz.