Mikroservis mimarisine geçiş, monolit uygulamayı klasörlere bölmek veya her modülü ayrı container’a koymak değildir. Servis sınırları iş yeteneklerine göre belirlenmeli; her servis bağımsız dağıtılabilmeli, kendi verisinin sahibi olmalı ve diğer servislerin arızasına karşı kontrollü davranmalıdır. Bu koşullar oluşmadan yapılan erken parçalama, geliştirme hızından çok ağ, veri tutarlılığı ve operasyon yükü getirir.
Bu rehber, çalışan bir monolitten kademeli geçişi ele alır. Bounded context analizi, ilk servis seçimi, Strangler Fig yaklaşımı, veri ayrıştırma, mesajlaşma, gözlemlenebilirlik ve geri alma planını birlikte kuracağız. Mimari ilkeler için Microsoft Azure Architecture Center mikroservis rehberini birincil kaynak olarak kullanabilirsiniz.
Önce mikroservise gerçekten ihtiyaç var mı?
Mikroservis, küçük ekip veya düşük değişim hızına sahip uygulamada otomatik bir iyileştirme değildir. Bağımsız ölçekleme ihtiyacı, birbirinden farklı yayın döngüleri, net ekip sahipliği veya belirli bir iş alanındaki yoğun değişim gibi ölçülebilir nedenler yoksa modüler monolit daha düşük maliyetli olabilir.
Şu sorulara kanıtla cevap verin:
- Hangi modül diğerlerinden bağımsız daha sık değişiyor veya ölçekleniyor?
- Tek bir deploy tüm uygulamayı gereksiz yere riske atıyor mu?
- Servisleri uçtan uca sahiplenebilecek ekipler var mı?
- Merkezi log, metric, trace ve otomatik dağıtım altyapısı hazır mı?
- Ağ hataları, eventual consistency ve mesaj tekrarları yönetilebilir mi?
Bu yanıtlar belirsizse önce modular monolith mimarisini güçlendirmek, daha sonra doğal sınırları dışarı çıkarmak daha güvenli olabilir.
Servis sınırlarını iş alanına göre belirleme
Servisleri controller, veritabanı tablosu veya teknik katman başına ayırmayın. “Kullanıcı servisi”, “sipariş servisi” gibi adlar bile yeterli değildir; her sınırın kendi iş kuralları, dili, sahibi ve veri sorumluluğu açık olmalıdır. Domain-driven design içindeki bounded context kavramı bu ayrımı kurmaya yardımcı olur.
Bir servis adayı:
- Tek ve anlaşılır bir iş yeteneğini kapsamalı,
- Başka servisle birlikte zorunlu deploy gerektirmemeli,
- İç uygulama ayrıntılarını API veya event sözleşmesine sızdırmamalı,
- Kendi verisini değiştiren tek yetkili bileşen olmalı,
- Bağımsız test ve geri alma sınırına sahip olmalıdır.
Çok küçük servisler daha fazla ağ çağrısı, dağıtım paketi ve operasyon yükü yaratır. Microsoft’un sınır belirleme rehberi de şüphe durumunda daha kaba taneli servislerle başlamanın, sonradan bölmekten genellikle daha yönetilebilir olduğunu vurgular.
İlk çıkarılacak servisi seçme
İlk aday, monolitin en kritik ödeme çekirdeği olmak zorunda değildir. Sınırları net, değişim değeri yüksek ve geri alma yolu basit bir iş alanı seçin. Bildirim, raporlama veya medya işleme gibi yan etkileri ayrılabilen modüller bazı projelerde uygun pilot olabilir; ancak gerçek seçim kendi domain ve trafik verinize dayanmalıdır.
Strangler Fig yaklaşımında yeni servis ile monolit bir süre birlikte çalışır. Proxy veya yönlendirme katmanı, seçilen isteği yeni servise aktarır; başarısızlıkta kontrollü biçimde eski akışa dönülebilir. AWS’nin resmî Strangler Fig rehberi bu kademeli geçişin risk ve sınırlamalarını açıklar.
Pilot servis için başarı ölçütleri
“Servis yayına çıktı” tek başına başarı ölçütü değildir. Önceden şu göstergeleri seçin: hata oranı, p95/p99 gecikme, mesaj kuyruğu yaşı, deploy ve rollback süresi, veri uzlaşmazlığı sayısı ve operasyon çağrıları. Gerçek değerleri izleme sisteminden alın; varsayımsal başarı yüzdeleri üretmeyin.
API ve event sözleşmelerini tasarlama
Senkron REST/gRPC çağrısı anlık cevap gereken işlemlerde; event veya queue ise gevşek bağlı ve gecikmeye toleranslı akışlarda kullanılabilir. Her çağrıyı event’e çevirmek ya da her servisi zincirleme HTTP çağrısına bağlamak yeni bir bağımlılık ağı oluşturur.
Sözleşmelerde şunları açıkça tanımlayın:
- Versiyonlama ve geriye uyumluluk süresi
- Timeout, retry ve idempotency davranışı
- Hata kodları ve güvenli hata gövdesi
- Kimlik doğrulama ile servis yetkilendirmesi
- Event şeması, üretici ve tüketici sahipliği
- Correlation ID ve izleme bağlamı
Asenkron işlerin yeniden deneme ve başarısızlık yönetimi için Laravel Queue sistemi rehberindeki idempotency ve failed job yaklaşımını uygulayabilirsiniz.
Veriyi servisler arasında ayırma
Bağımsız servislerin aynı tabloları doğrudan yazması, kodu ayırsa bile veri katmanında monoliti sürdürür. Her servis kendi şemasının veya veri deposunun sahibi olmalıdır. Diğer servisler bu veriye API, event veya yalnızca okuma amacıyla üretilmiş ayrı bir görünüm üzerinden erişmelidir.
Tek transaction içindeki işlem birden fazla servise ayrıldığında klasik ACID transaction sınırı kaybolabilir. Saga, outbox ve eventual consistency gibi desenler burada devreye girer. Bunlar ücretsiz çözüm değildir: telafi işlemleri, duplicate mesajlar, sıralama ve uzlaşma süreçleri ayrıca tasarlanmalıdır.
Sipariş oluşturuldu
→ Outbox kaydı aynı yerel transaction içinde yazıldı
→ Event güvenilir biçimde yayınlandı
→ Stok servisi idempotency key ile işledi
→ Başarısızlıkta retry veya telafi akışı çalıştıGüvenilirlik: timeout, retry ve circuit breaker
Dağıtık sistemde ağ çağrısı başarısız olabilir, gecikebilir veya cevap gelmesine rağmen istemci timeout yaşayabilir. Her istemciye sonsuz retry eklemek zincirleme yük oluşturur. Retry yalnızca geçici hatalarda, sınırlı sayıda ve jitter içeren backoff ile kullanılmalıdır.
Circuit breaker, sürekli başarısız servise çağrıları geçici olarak keser. Bulkhead yaklaşımı ise bir servisin kaynak tüketiminin diğer akışları çökertmesini önler. Fallback sonucu iş açısından yanıltıcıysa “başarılı gibi” cevap vermek yerine açık ve izlenebilir hata döndürün.
Gözlemlenebilirlik ve güvenlik
Tek uygulamadaki stack trace yerine istek artık birden fazla servis ve queue üzerinden geçer. Merkezi loglama, metric ve distributed tracing geçişin ön koşulu olmalıdır. Her servis aynı correlation ID’yi taşımalı; loglarda parola, token ve gereksiz kişisel veri bulunmamalıdır.
Servisler arası trafiği “iç ağda” olduğu için güvenilir saymayın. En az ayrı kimlik, kısa ömürlü secret/sertifika, en az yetki, rate limit ve audit izi planlayın. Genel uygulama kontrolleri için Laravel güvenlik kontrol listesini genişletebilirsiniz.
Dağıtım ve geri alma planı
Bağımsız servis hedefi, bağımsız CI/CD ve geriye uyumlu sözleşme gerektirir. Yeni servis önce dark launch veya sınırlı trafikle doğrulanabilir. Feature flag, canary veya blue-green yaklaşımı seçilecekse flag sahipliği ve kaldırma tarihi de belirlenmelidir.
Her adımın rollback planı olmalı: trafik eski monolite dönebiliyor mu, yeni veri nasıl uzlaştırılacak, eski şema ne kadar süre korunacak? Otomatik dağıtımın temel adımları için GitHub Actions ile hosting deploy rehberinden yararlanabilirsiniz.
Geçiş kontrol listesi
- Geçişin ölçülebilir iş ve operasyon gerekçesi var mı?
- Servis sınırı bir bounded context ve ekip sahipliğiyle eşleşiyor mu?
- İlk servis geri alınabilir, düşük bağımlılıklı bir pilot mu?
- API/event sözleşmesi ve geriye uyumluluk politikası tanımlı mı?
- Veri sahipliği, idempotency ve telafi işlemleri net mi?
- Timeout, retry, circuit breaker ve kaynak izolasyonu var mı?
- Log, metric, trace, alarm ve rollback canlı trafik öncesi hazır mı?
Sıkça Sorulan Sorular
Mikroservis mimarisine ne zaman geçilmeli?
Bağımsız ölçekleme, dağıtım ve ekip sahipliği ihtiyacı monolitin operasyonel sınırlarını aşıyorsa değerlendirilmelidir. Yalnızca proje büyüdü diye otomatik olarak gerekmez.
Monolit tek seferde mikroservislere bölünür mü?
Yüksek risklidir. Strangler Fig gibi kademeli yaklaşım, her iş yeteneğini ayrı doğrulama ve geri alma fırsatı sağlar.
Her mikroservisin ayrı veritabanı olmalı mı?
Temel ilke veri sahipliğinin serviste olmasıdır. Fiziksel altyapı tercihi değişebilir; başka servislerin aynı şemayı doğrudan yazması bağımsızlığı bozar.
Mikroservisler yalnızca REST ile mi haberleşir?
Hayır. İhtiyaca göre REST, gRPC, mesaj kuyruğu veya event kullanılabilir. Seçim tutarlılık, gecikme, bağımlılık ve hata davranışına göre yapılmalıdır.
Kubernetes mikroservis için zorunlu mu?
Hayır. Kubernetes dağıtım ve orkestrasyon seçeneklerinden biridir; küçük sistemde operasyon maliyeti faydasını aşabilir. Önce servis sınırı ve çalışma gereksinimi belirlenmelidir.
Sonuç
Mikroservis mimarisine geçişin güvenli yolu, monoliti bir gecede parçalamak değil; ölçülebilir bir ihtiyetten başlayıp iş sınırlarını, veri sahipliğini ve operasyon yetkinliğini kademeli olarak kurmaktır. İlk servisi küçük ama anlamlı seçin, eski sistemle kontrollü birlikte çalıştırın ve her adımda gözlem ile rollback kanıtı üretin.
