MICROSERVICE NEDİR?

Neden bazı sistemler tek bir küçük hata yüzünden saatlerce yere serilir, bazıları ise bir servis çökse bile çalışmaya devam eder? Bu sorunun cevabı çoğu zaman mimari tercihte saklıdır. Microservice, son on yılın en çok konuşulan kavramlarından biri oldu; ancak her ekibin ona ihtiyacı yok. Doğru zamanda doğru sınırı çizmek, yazılım ömrü boyunca ödeyeceğiniz teknik faturayı belirler.

Microservice Tanımı: Küçük, Bağımsız, Sorumluluk Sahibi

Microservice, tek bir iş yeteneğine odaklanan, kendi veri deposuyla çalışan ve diğer servislerle ağ üzerinden iletişim kuran küçük bir uygulama birimidir. Burada anahtar kelime "bağımsız"dır: bir microservice kendi başına geliştirilir, kendi başına test edilir, kendi başına dağıtılır.

Tanımı somutlaştırmak için bir e-ticaret örneği düşünelim. Sepet, ödeme, stok, kullanıcı yönetimi, kargo takibi — her biri ayrı bir servistir. Sepet servisi çöktüğünde stok sorgusu çalışmaya devam eder. Bu izolasyon, mimarinin en güçlü vaadidir. ilgili çevrimiçi kaynak konuya derinlemesine bir bakış sağlar.

Monolit ile Aradaki Sınır Nasıl Çizilir?

Monolit kötü bir kelime değildir. Aslında çoğu başarılı ürün hayatına monolit olarak başlar. Sınırı çizmek için şu üç soruyu sormak gerekir:

• Deployment frekansı: Farklı modüller farklı hızlarda mı değişiyor? Ödeme ayda bir, kampanya motoru günde üç kez güncelleniyorsa ortak bir deploy döngüsü ikisini de yavaşlatır.
• Ölçek profili: Bir modül diğerlerinden 50 kat daha fazla yük alıyor mu? Tüm monoliti dikey büyütmek pahalı bir çözümdür.
• Takım sayısı: Aynı kod tabanına 8'den fazla geliştirici dokunuyorsa merge çakışmaları ve regresyon korkusu sürecin doğal parçası olur.

Bu üç sorudan en az ikisine net "evet" diyebiliyorsanız sınırın bir tarafından diğerine geçmeyi düşünebilirsiniz. Üçüne de "hayır" diyorsanız monolit hâlâ en ucuz, en hızlı seçenektir.

Hangi Şartlarda Anlamlıdır?

Microservice mimarisi şu koşullarda gerçek değer üretir:

1. Birden fazla bağımsız takım paralel çalışıyor ve birbirinin deploy döngüsünü beklemek istemiyorsa.
2. Sistemin bazı bölümleri çok farklı teknolojiler gerektiriyorsa — örneğin tavsiye motoru Python, ödeme akışı .NET, gerçek zamanlı bildirim Go.
3. Servislerden biri kritik (ödeme, kimlik) ve diğerlerinden bağımsız bir SLA hedefine ihtiyaç duyuyorsa.
4. Trafik dağılımı homojen değilse ve dar bir bölümün ayrı ölçeklenmesi maliyet avantajı yaratıyorsa.
5. Domain sınırları belirgin, iş tarafı tarafından da net konuşulabilen alanlara ayrılmışsa (DDD'deki "bounded context" kavramı tam burada işe yarar).

Ne Zaman Overkill Olur?

Microservice ücretsiz değildir; her servis için ayrı CI/CD, ayrı log toplama, ayrı izleme, ayrı veri tutarlılığı sorunu vardır. Şu durumlarda mimariyi parçalamak fayda yerine yük getirir:

• Takım 5 kişiden küçükse — her geliştiriciye 2-3 servisin operasyonu düşer, kod yazma süresi azalır.
• Ürün hâlâ "ne yaptığını" aramaktaysa — domain sınırları belirsizken çizilen servis sınırları altı ay sonra yanlış çıkar ve yeniden çizim çok pahalıdır.
• Trafik düşükse — bir tane orta seviye sunucu tüm yükü taşıyabiliyorsa dağıtık sistem sadece gecikme ekler.
• Ekipte DevOps, observability, container orkestrasyonu deneyimi yoksa — production'da gece üçte dağıtık bir hatayı debug etmek monolitten kat kat zordur.

Pratik kural: "Distributed monolith" tuzağına dikkat. Servisleri ayırıp aralarına senkron HTTP çağrıları zinciri kurarsanız, hem monolitin tek-failure özelliğini hem de dağıtık sistemin karmaşıklığını aynı anda elde edersiniz — iki dünyanın en kötü hâli.

İletişim Modeli: Senkron mu Asenkron mu?

Servisler arası konuşma şekli mimarinin kaderini belirler. İki ana yaklaşım vardır:

• Senkron (REST, gRPC): İstek-yanıt modeli. Hızlı geliştirilir, debug edilmesi kolaydır, ancak çağrı zinciri uzadıkça gecikme ve hata olasılığı çarpan etkisiyle büyür.
• Asenkron (mesaj kuyrukları, event bus): Servisler birbirinin anlık varlığına bağımlı değildir. Daha dayanıklıdır ancak eventual consistency'yi kabul etmek gerekir.

Olgun mimariler genelde ikisini birlikte kullanır: kullanıcıya yanıt dönmesi gereken yerlerde senkron, arka plan işlerinde ve servisler arası koordinasyonda asenkron.

Veri Yönetimi: En Sık Yanılgı Burada

"Her servisin kendi veritabanı olmalı" ilkesi söylendiği kadar kolay uygulanmaz. Çünkü ortak veriye ihtiyaç duyan iş kuralları her zaman çıkar. Üç temel desen vardır:

1. Saga pattern: Birden fazla servisi etkileyen iş akışları için adım adım kompanzasyon mantığı.
2. Event sourcing: Değişiklikleri durum yerine olay olarak saklamak; her servis kendi okuma modelini kurar.
3. CQRS: Yazma ve okuma modellerini ayırmak; rapor ve sorgu yükünü ana iş akışından koparmak.

Bu desenleri uygulamadan servisleri ayırırsanız, sonunda servisler birbirine yine bağlı kalır — sadece bağ ağ üzerinden ve daha kırılgan şekilde kurulmuş olur.

.NET Tarafında Pratik Başlangıç

Microservice kavramını .NET dünyasında somut araçlarla görmek, teorik bilgiyi pekiştirmenin en hızlı yoludur. ASP.NET Core minimal API'ler, gRPC desteği, MassTransit, RabbitMQ entegrasyonu ve YARP gateway gibi parçaların bir arada nasıl kullanıldığını öğrenmek için .NET microservices eğitimi kapsamındaki içeriklerden yararlanabilirsiniz.

Mimari Kararını Nasıl Vermeli?

Karar bir tasarım toplantısında verilmez; ürünün hayat döngüsüyle birlikte olgunlaşır. Önerilen yol şudur:

• İyi modüllendirilmiş bir monolitle başlayın. Domain sınırlarını kodda net çizin, bağımlılıkları gevşek tutun.
• Acı veren noktaları gözlemleyin: hangi modül en sık deploy oluyor, hangisi en çok ölçek istiyor, hangisi diğerlerinden bağımsız evrilmek istiyor.
• İlk servisi tam o acı noktasından çıkarın — "çünkü modaydı" gerekçesiyle değil, ölçülebilir bir kısıttan dolayı.
• Her ayırma kararından sonra observability altyapısını (log, metric, trace) bir adım önde tutun.

Microservice bir hedef değildir; belirli ölçek, takım ve domain koşullarında ortaya çıkan bir cevaptır. Soruyu doğru sorduğunuzda cevabın ne zaman "evet" ne zaman "henüz değil" olduğunu kendiniz görürsünüz. Konuyu .NET ekosistemindeki uygulamalı örneklerle derinleştirmek için .NET microservice eğitim sayfasını inceleyebilirsiniz.