Mikroservis Mimarisi Nedir? Monolith'ten Mikroservise Geçiş Rehberi

Kısaca: Mikroservis mimarisi, bir uygulamayı bağımsız geliştirilip dağıtılabilen küçük servislere bölme yaklaşımıdır. Faydası; ekiplerin bağımsız çalışması, bileşenlerin ayrı ölçeklenmesi ve hataların izole edilmesidir. Bedeli ise dağıtık sistem karmaşıklığıdır: ağ gecikmesi, veri tutarlılığı, izleme, dağıtım ve operasyon yükü. Bu yüzden çoğu proje için doğru soru “mikroservise nasıl geçeriz?” değil, **“gerçekten ihtiyacımız var mı?”**dır. Çoğu zaman iyi düzenlenmiş bir modüler monolit ile başlamak ve gerekirse parça parça ayırmak daha sağlıklıdır.

Son güncelleme: Eylül 2026

Mikroservis mimarisi nedir?

Monolitik bir uygulamada tüm işlevler (kullanıcı, sipariş, ödeme, bildirim vb.) tek bir kod tabanında ve tek bir dağıtım biriminde yer alır. Mikroservis mimarisinde ise her iş alanı ayrı bir servistir: kendi kodu, çoğu zaman kendi veritabanı ve kendi dağıtım süreci vardır; servisler birbirleriyle API veya mesajla konuşur.

Önce monolit: yaygın bir tavsiye

Yazılım mimarisinin tanınmış isimlerinden Martin Fowler'ın “Monolith First” yazısındaki temel görüş şu: yeni bir projeye mikroservisle başlamak yerine monolitle başlayın. Gerekçeler:

• Erken aşamada hız ve öğrenme önceliklidir; mikroservisin getirdiği ek yük (Fowler'ın deyişiyle “mikroservis primi”) bunu yavaşlatır.
• Servis sınırlarını doğru çizmek deneyim gerektirir; servisler arasında işlev taşımak, monolit içinde yapmaktan çok daha zordur.
• Fowler, sıfırdan mikroservisle başlayan projelerin çoğunun ciddi sorun yaşadığını gözlemlediğini belirtiyor. (Yazı 2015 tarihli ve yazar bulguları kesin değil, deneyime dayalı olarak sunuyor; yine de yaygın bir referans.)

Bu, mikroservisin kötü olduğu anlamına gelmez; doğru zamanda ve doğru gerekçeyle kullanılması gerektiği anlamına gelir.

Örnek: Amazon Prime Video'nun izleme servisi

2023'te Prime Video ekibinin, ses/görüntü kalite izleme servisini dağıtık mikroservislerden tek bir uygulamaya taşıyarak altyapı maliyetini %90'dan fazla düşürdüğü haberi geniş yankı buldu (The Stack). Önemli ayrıntı: bu değişiklik yalnızca o izleme servisi içindi, tüm Prime Video'yu kapsamıyordu; darboğaz, servisler arası veri aktarımı ve orkestrasyon maliyetiydi. Ders: mimari, iş yüküne göre seçilir; “mikroservis her zaman daha iyi” ya da “monolit her zaman daha iyi” yoktur.

Ne zaman mikroservise geçmeli?

Şu işaretlerin birkaçı birlikte varsa değerlendirin:

1. Birden çok ekip aynı kod tabanında birbirini bloke ediyor; dağıtımlar sıraya giriyor.
2. Uygulamanın bazı parçaları çok farklı ölçekleme ihtiyacı duyuyor (örneğin görüntü işleme veya arama, diğer parçalardan katbekat fazla yük alıyor).
3. Farklı teknoloji veya güvenlik gereksinimleri var (örneğin ödeme modülü ayrı izolasyon istiyor).
4. Hata yayılımı sorun: bir modülün çökmesi tüm sistemi düşürüyor.
5. Organizasyon, servisleri kendi başına işletebilecek olgunlukta (CI/CD, izleme, nöbet süreçleri var).

Şu durumda beklemeniz akıllıca olur: küçük ekip, ürün-pazar uyumu henüz netleşmemiş, iş alanı sınırları belirsiz, operasyon deneyimi sınırlı. Bu durumda mikroservis maliyeti faydasından büyük olur.

Alternatif: modüler monolit

Modüler monolit, tek bir dağıtım biriminde ama net sınırlı modüllerle (sipariş, ödeme, kullanıcı gibi) çalışır. Modüller birbirinin veritabanı tablolarına doğrudan erişmez, tanımlı arayüzler üzerinden konuşur. Faydası: mikroservisin en değerli özelliği olan sınır disiplinini basit operasyonla verir ve ileride bir modülü ayrı servise çıkarmayı kolaylaştırır. Birçok ekip için en akılcı orta yoldur.

Geçiş stratejisi: strangler fig deseni

Mevcut monoliti bir gecede yeniden yazmak çok risklidir. Yaygın yaklaşım strangler fig (boğucu incir) desenidir: monolitin önüne bir yönlendirme katmanı (API gateway/reverse proxy) konur; yeni veya ayrılacak işlevler yeni servise yazılır, ilgili trafik oraya yönlendirilir, monolit zamanla küçülür.

Adımlar:

1. Sınırları belirleyin. İş alanlarına (domain) göre; “hangi veri kime ait?” sorusuyla başlayın. En az bağımlı ve en çok değer üretecek parçayı seçin.
2. Gözlemlenebilirliği önce kurun. Log, metrik ve dağıtık izleme olmadan ayrıştırma kör uçuştur.
3. İlk servisi ayırın. Kenar bir işlevle (bildirim, raporlama, arama) başlayıp deneyim kazanın.
4. Veriyi ayırın. Servis kendi verisine sahip olsun; ortak veritabanına doğrudan erişim, “dağıtık monolit” tuzağıdır.
5. Yönlendirmeyi kademeli değiştirin. Trafiği yüzde yüzde yeni servise taşıyın, geri dönüş planı bulundurun.
6. Eski kodu kaldırın. Ayrılan işlevi monolitten silmeyi unutmayın.

Temel bileşenler

• API Gateway: İstemciler için tek giriş noktası; kimlik doğrulama, hız sınırlama, yönlendirme.
• Servis keşfi: Servislerin birbirini dinamik bulması (Kubernetes gibi platformlarda genellikle yerleşik).
• Mesaj kuyruğu / olay akışı (Kafka, RabbitMQ vb.): Servisler arası asenkron iletişim; birbirine gevşek bağımlılık. Dağıtık işlemlerde saga deseni ile telafi adımları tanımlanır.
• Dayanıklılık desenleri: Zaman aşımı, yeniden deneme (retry) ve devre kesici (circuit breaker); bir servisin yavaşlaması zincirleme arızaya dönüşmesin.
• Dağıtık izleme ve merkezi log: Bir isteğin servisler arası yolunu izlemek (OpenTelemetry vb.), merkezi log analizi.
• Konteyner ve orkestrasyon: Docker ve Kubernetes; CI/CD ile otomatik dağıtım, mavi-yeşil veya canary yayın.

Dikkat edilecek tuzaklar

1. Dağıtık monolit: Servisler ayrı ama sıkı bağımlı; biri değişince hepsi etkileniyor. Bağımsızlık kazanılmamışsa ayrıştırma yalnızca karmaşıklık ekler.
2. Çok küçük servisler (nano-servis): Her fonksiyonu ayrı servis yapmak, iletişim yükünü artırır.
3. Ortak veritabanı: Servisler aynı tabloya yazarsa sınır kalmaz.
4. Test ve ortam karmaşıklığı: Uçtan uca testler ve yerel geliştirme ortamı zorlaşır.
5. Ağ ve gecikme varsayımı: Yerel fonksiyon çağrısı, ağ çağrısına dönüşür; hata ve gecikme yönetimi gerekir.
6. Maliyet: Altyapı, izleme araçları ve operasyon emeği artar.
7. Organizasyon uyumsuzluğu: Servis sınırları ile ekip sınırları uyumlu değilse hız artmaz.

Karar için kontrol listesi

• Ürün-pazar uyumu netleşti mi?
• Birden çok ekip aynı kodda birbirini engelliyor mu?
• Belirli parçalar farklı ölçek/güvenlik/teknoloji ihtiyacı duyuyor mu?
• CI/CD, izleme, log ve nöbet süreçleri var mı?
• Servis sınırlarını iş alanı üzerinden tanımlayabildik mi?
• Modüler monolit yeterli olamaz mı?

Cevapların çoğu “hayır” ise, monolit ya da modüler monolitle devam edin.

Aktaş Digital ne sağlıyor?

Web uygulamaları, SaaS platformları ve kurumsal sistemlerde mimariyi gereksinime göre belirliyoruz: çoğu projede önce modüler ve iyi test edilmiş bir çekirdek, ihtiyaç olduğunda ayrılabilir parçalar. Web Uygulamaları ve SaaS Platform Geliştirme hizmetlerimizde mimari danışmanlık da veriyoruz; SaaS rehberimizde MVP'den ölçeklemeye yol haritasını da ele aldık. Mevcut sisteminiz için teklif formundan bize ulaşabilirsiniz.

Sık Sorulan Sorular

Mikroservis mimarisi monolitten daha mı iyi?

Hayır, farklıdır. Küçük ekip ve erken aşama ürünler için monolit çoğu zaman daha verimlidir; çok ekipli ve farklı ölçek ihtiyaçları olan büyük sistemlerde mikroservis avantaj sağlayabilir.

Mikroservise geçiş ne kadar sürer?

Sistemin büyüklüğüne ve bağımlılıklarına bağlıdır; tek seferde değil, aylar-yıllar sürebilen kademeli bir süreçtir. Strangler fig ile küçük parçalarla ilerlenir.

Her servisin ayrı veritabanı mı olmalı?

Servis bağımsızlığı için evet, her servis kendi verisine sahip olmalı; ancak bu, veri tutarlılığı ve raporlama açısından ek tasarım gerektirir.

Kubernetes şart mı?

Şart değil; ancak çok sayıda servisin dağıtımı, ölçeklenmesi ve izlenmesi için yaygın bir platformdur. Az sayıda servisle daha basit çözümler yeterli olabilir.

Modüler monolit gelecekte mikroservise dönüştürülebilir mi?

Evet; modüller arası net sınırlar ve arayüzler, ilerideki ayrıştırmayı belirgin biçimde kolaylaştırır.

Sonuç

Mikroservis, bir hedef değil bir araçtır. Sınırları net, ekipleri bağımsız, operasyon olgunluğu yüksek organizasyonlar için güçlüdür; diğerleri için modüler monolit çoğu zaman daha hızlı, ucuz ve güvenlidir. Geçiş gerekiyorsa kademeli ilerleyin ve gözlemlenebilirliği en başta kurun.