"Büyük şirketler mikroservis kullanıyor, biz de geçmeliyiz" cümlesi, yazılım projelerinde en pahalı yanlış anlaşılmalardan biridir. Mikroservis mimarisi, bir uygulamayı her biri kendi işini yapan, kendi verisine sahip ve bağımsız yayınlanabilen küçük servislere bölme yaklaşımıdır. Doğru yerde ekipleri hızlandırır; yanlış yerde bakım yükünü ve maliyeti katlar.
Bu rehberde mikroservisin ne olduğunu, monolit ve modüler monolitle farkını, servis sınırlarının nasıl çizildiğini, bedelini (ağ gecikmesi, kullanılabilirlik, dağıtık işlem, gözlem), altı soruluk karar testini, üç yıllık maliyet karşılaştırmasını ve monolitten kademeli geçişi anlatıyoruz. Örnek rakamlar temsilîdir; belirli bir ürünün sonucu ya da sektör ortalaması değildir.
Mikroservis Mimarisi Nedir?
Mikroservis mimarisinde uygulama, iş alanlarına göre ayrılmış küçük servislerden oluşur. Her servis tek bir iş yeteneğinden sorumludur (örneğin sipariş, stok, ödeme, bildirim), kendi veri deposuna sahiptir ve diğerleriyle ağ üzerinden, genellikle bir arayüz (API) ya da mesajlaşma ile konuşur. Servisler birbirinden bağımsız geliştirilir, sınanır ve yayınlanır.
Kritik nokta "küçük" olmak değil, bağımsız olmaktır: bir servisin değişmesi diğerlerinin yeniden yayınlanmasını gerektirmiyorsa sınır doğru çizilmiş demektir. Servisler arası konuşmanın temelini API entegrasyonu rehberimizde anlattık.
Okumanızı öneririz: Özel yazılım hizmetimiz
Monolit, Modüler Monolit ve Mikroservis Arasındaki Fark Nedir?
Seçenekler ikili değil, bir yelpazedir. Monolit tek parça yayınlanan uygulamadır. Modüler monolit yine tek parça yayınlanır, ama içinde net sınırları olan modüller vardır. Mikroservis ise bu modülleri ayrı yayınlanan servislere dönüştürür.
| Konu | Monolit | Modüler monolit | Mikroservis |
|---|---|---|---|
| Yayın | Tek parça | Tek parça | Servis başına ayrı |
| Kod sınırları | Belirsiz olabilir | Modül sınırları net | Süreç sınırı |
| Veri | Ortak veritabanı | Modül başına şema ya da kural | Servis başına kendi verisi |
| Ölçekleme | Bütün uygulama birlikte | Bütün uygulama birlikte | Servis servis |
| Operasyon yükü | Düşük | Düşük | Yüksek |
| Uygun durum | Küçük, tek ekip | Çoğu işletme uygulaması | Çok ekip, farklı ölçek ihtiyacı |
Sıfırdan yazılan çözümün katmanlarını özel yazılım nedir rehberimizde anlattık; mimari seçim bu katmanlardan yalnızca biridir.
Servis Sınırları Nasıl Çizilir?
Mikroservisin başarısı, sınırın doğru yerden geçmesine bağlıdır. Yanlış sınır, her değişiklikte birden fazla servisi aynı anda yayınlamak demektir.
- İş yeteneğine göre bölün: "Sipariş al", "stok düş", "ödeme tahsil et" gibi iş alanları sınır adayıdır; "veritabanı katmanı" ya da "arayüz katmanı" gibi teknik katmanlar değildir.
- Veri sahipliğini netleştirin: Her veri parçasının tek sahibi servis olmalı; diğer servisler o veriye doğrudan veritabanından değil, sahibinin arayüzünden ulaşmalı.
- Birlikte değişenleri birlikte tutun: Hep aynı anda değişen iki parça aslında tek servistir.
- Ekip sınırıyla uyumlu olun: Bir servisin sahibi net bir ekip olmalı; sınır, ekip yapısını izler.
Sınırları belirlemenin ön koşulu, iş alanlarının yazılı hale gelmesidir. Bunu gereksinim analizi rehberimizdeki yöntemle yapabilirsiniz.
Mikroservisin Bedeli Nedir?
Servisleri ayırmak, uygulamayı basitleştirmez; karmaşıklığı kodun içinden ağa taşır. Beş bedel pratikte öne çıkar.
| Bedel | Ne olur? | Önlem |
|---|---|---|
| Ağ gecikmesi | Fonksiyon çağrısı ağ çağrısına dönüşür | Çağrı zincirini kısa tutun, gerekirse önbellek kullanın |
| Kullanılabilirlik | Zincirdeki her servis hata noktası olur | Zaman aşımı, yeniden deneme, yedek davranış |
| Dağıtık işlem | Tek veritabanı işlemi yoktur | Telafi adımları, çift işlemi önleyen tasarım |
| Gözlem | Hata birden fazla servise yayılır | Ortak günlük, izleme, istek korelasyon kimliği |
| Dağıtım ve test | Çok sayıda yayın hattı ve sürüm uyumu | Otomasyon, sözleşme testleri |
Kullanılabilirliğin etkisi hesapla görülür: her biri %99,9 kullanılabilir beş servis seri çağrılıyorsa bileşik kullanılabilirlik 0,999⁵ ≈ 0,995, yani %99,5'tir. 30 günlük ay 43.200 dakikadır; %99,9 yaklaşık 43,2 dakika kesintiye, %99,5 ise yaklaşık 216 dakikaya karşılık gelir. Ağ gecikmesi için de basit bir ölçü: dört servis atlaması × 15 ms = 60 ms ek süre. Her iki rakam temsilîdir; kendi servislerinizi ölçün. Kullanılabilirlik hedeflerinin sözleşmeye yazılışını SLA rehberimizde anlattık.
Mikroservis mi, Monolit mi? Altı Soruluk Test
Aşağıdaki soruları kendi sisteminiz için yanıtlayın. Her "evet" mikroservis lehine bir puandır.
- Aynı kod tabanında çalışan, birbirini bekleyen birden fazla bağımsız ekip var mı?
- Sistemin parçalarının ölçekleme ihtiyacı birbirinden çok farklı mı (örneğin yalnız sipariş alma yoğun)?
- Parçalar farklı hızda yayınlanmak zorunda mı?
- İş alanı sınırları net ve uzun süre kararlı mı?
- Otomatik dağıtım, izleme ve olay müdahalesi için ekipte deneyim ve zaman var mı?
- Bir parçanın çökmesinin diğerlerini etkilememesi iş açısından zorunlu mu?
| "Evet" sayısı | Anlamı | Önerilen adım |
|---|---|---|
| 0–2 | Monolit ya da modüler monolit yeterli | Modül sınırlarını net tutun |
| 3–4 | Seçili parça servis olmaya aday | Yalnız o parçayı ayırın, kalanı koruyun |
| 5–6 | Mikroservis güçlü aday | Gözlem ve otomasyon altyapısını önce kurun |
Çoğu işletme yazılımı (sipariş, stok, müşteri, raporlama) ilk iki satırda kalır. Yazılım yaşam döngüsünde mimari kararın nereye oturduğunu yazılım geliştirme süreci rehberimizde bulabilirsiniz.
Mikroservisin Üç Yıllık Maliyeti Monolite Göre Nasıl Değişir?
Mikroservis geliştirmeyi, altyapıyı ve bakımı birlikte büyütür. Aşağıdaki varsayımlar temsilîdir: aynı kapsam, 50 kişi-gün × 1,2 pay = 60 kişi-gün, günlük ₺9.000.
- Monolit: 60 kişi-gün × ₺9.000 = ₺540.000; bakım yıllık %15, yani 3 yılda ₺243.000; altyapı yıllık ₺20.000, yani 3 yılda ₺60.000.
- Mikroservis (5 servis): servisler arası sözleşme, dağıtım hattı ve gözlem için %35 ek efor: 60 × 1,35 = 81 kişi-gün × ₺9.000 = ₺729.000; bakım yıllık %15, 3 yılda ₺328.050; altyapı yıllık ₺72.000, 3 yılda ₺216.000.
| Kalem | Monolit | Mikroservis |
|---|---|---|
| Geliştirme | ₺540.000 | ₺729.000 |
| Bakım (3 yıl, %15/yıl) | ₺243.000 | ₺328.050 |
| Altyapı (3 yıl) | ₺60.000 | ₺216.000 |
| 3 yıllık toplam | ₺843.000 | ₺1.273.050 |
Fark ₺430.050, yani monolite göre yaklaşık %51'dir (430.050 ÷ 843.000). Bu fark, bağımsız yayın ve ölçeklemenin size sağlayacağı değerle kıyaslanmalıdır: gerçekten ayrı ekipler ya da ayrı ölçek ihtiyacı yoksa bedel karşılık bulmaz. Kalemlerin ayrıntısını yazılım projesi maliyeti rehberimizde bulabilirsiniz.
Monolitten Mikroservise Kademeli Geçiş Nasıl Yapılır?
Tek seferde yeniden yazmak en riskli yoldur. Daha güvenli yol, parçaları tek tek ayırmaktır.
- Modülerleştirme: Önce monolit içinde modül sınırlarını net çizin; çoğu kazanç burada gelir.
- Aday seçimi: Ayrı ölçek ya da ayrı yayın ritmi isteyen tek bir parçayı seçin.
- Arayüz tanımı: Parçanın dışarıya sunduğu sözleşmeyi yazın ve sürümleyin.
- Veri ayrımı: Parçanın verisini kendi deposuna taşıyın; ortak tablolara doğrudan erişimi kesin.
- Paralel çalıştırma: Eski ve yeni yolu bir süre birlikte çalıştırıp sonuçları karşılaştırın.
- Eski kodu kaldırma: Doğrulama bitince monolitteki karşılığını silin.
Her adımda geri dönüş yolu bırakın. Veri taşımada veri yedekleme rehberimizdeki geri yükleme testi alışkanlığı işe yarar; servisler arası kimlik doğrulama için API güvenliği rehberimize bakın.
Mikroservis Mimarisinde Gözlem ve Dağıtım Nasıl Kurulur?
Servis sayısı arttıkça "hata nerede?" sorusu zorlaşır. Bu yüzden gözlem ve dağıtım otomasyonu, ilk servis ayrılmadan önce kurulması gereken altyapıdır.
- Korelasyon kimliği: İsteğin girdiği anda üretilen kimlik her servise ve her günlük satırına taşınır; tek isteğin yolu baştan sona izlenir.
- Ortak günlük ve ölçüm: Her servis aynı biçimde günlük yazar; gecikme, hata oranı ve kuyruk uzunluğu tek panoda görünür.
- Sağlık kontrolü ve zaman aşımı: Her çağrıda kısa bir zaman aşımı ve sınırlı yeniden deneme olur; yanıt vermeyen servis zinciri kilitlemez.
- Otomatik dağıtım hattı: Her servisin kendi sınama ve yayın hattı vardır; yayın elle yapılıyorsa mikroservis avantajı kaybolur.
- Geri alma: Her sürümün bir önceki sürüme dönüş yolu yazılıdır ve sınanmıştır.
| Hedef | 30 günlük ayda izin verilen kesinti | Anlamı |
|---|---|---|
| %99,9 | 43.200 × 0,001 = 43,2 dk | Sıkı hedef; her servisin çok sağlam olması gerekir |
| %99,5 | 43.200 × 0,005 = 216 dk | Beş servisin seri zincirinin bileşik değeri |
| %99 | 43.200 × 0,01 = 432 dk | Gevşek hedef; kritik olmayan parçalar için |
Hedefi servis servis belirlemek gerekir: ödeme gibi kritik parça sıkı, bildirim gibi tamamlayıcı parça gevşek hedefle çalışabilir. Kritik yolda olmayan servislerin hatası, ana işlemi durdurmayacak biçimde (örneğin kuyruğa alarak) tasarlanırsa bileşik kullanılabilirlik düşmez. Test tarafında servis arayüzü sözleşmelerinin otomatik sınanması için yazılım testi rehberimize bakın.
Mikroservis Hangi Durumlarda Gerçekten Gerekir?
- Çok ekipli büyük ürün: Onlarca geliştirici aynı kodu değiştirirken birbirini bekliyorsa.
- Parçalar arası ölçek farkı: Yalnız bir bölüm yoğun trafikte ve bütün uygulamayı çoğaltmak israf ise.
- Bağımsız yayın zorunluluğu: Bir bölümün haftada birden fazla, diğerinin ayda bir yayınlanması gerekiyorsa.
- Hata yalıtımı: Ödeme gibi kritik bir parçanın bildirim gibi önemsiz bir parçadan etkilenmemesi isteniyorsa.
- Farklı teknoloji ihtiyacı: Bir bölüm gerçekten ayrı bir çalışma ortamı gerektiriyorsa.
Bir ürünü aboneliklerle sunuyor ve çok kiracılı çalıştırıyorsanız mimari seçim ayrıca önem kazanır; ayrıntı için SaaS rehberimize bakın.
Mikroservis Projelerinde Sık Yapılan Hatalar Nelerdir?
- Moda olduğu için seçmek: İhtiyaç tanımı olmadan başlamak, bedeli ödeyip kazancı almamak demektir.
- Çok küçük servisler: Aşırı bölünmüş sistemde her iş akışı onlarca ağ çağrısına dönüşür.
- Ortak veritabanı: Servisler aynı tabloyu paylaşıyorsa bağımsızlık yoktur; "dağıtık monolit" ortaya çıkar.
- Gözlemi sona bırakmak: Günlük ve izleme olmadan hatayı bulmak günler alır.
- Test ve sürüm uyumunu atlamak: Servis arayüzü değişince tüketenler habersiz bozulur.
- Ekip yapısını değiştirmemek: Servis var ama sahibi belirsizse bağımsızlık kağıt üzerinde kalır.
Okumanızı öneririz: Veritabanı Nasıl Seçilir?
İnovabil ile Yazılım Mimarisi Kararı
İnovabil olarak ağırlığımız sıfırdan, firmaya özel yazılım geliştirmektir: özel yazılım, ERP, CRM, e-ticaret, web, mobil ve entegrasyon. Mimari kararı gereksinim analizinde, işletmenin ekip yapısı, kullanıcı sayısı ve büyüme beklentisiyle birlikte yazılı olarak değerlendirmeyi öneriyoruz; çoğu işletme uygulamasında net modül sınırları olan bir yapı ile başlayıp, gerçek ihtiyaç doğan parçayı ayırmak daha sağlam zemindir.
Avcılar İnşaat için CRM, satın alma ve mobil; İZBAN için satın alma sistemi; Karyak için lojistik ve sevkiyat planlama ile toptan sipariş yönetimi; Sleepy için depo yönetimi ile şikâyet ve destek yönetim sistemi geliştirdik. Sisteminizin bugünkü yapısını ve büyüme hedefinizi kısaca yazın; altı soruluk testi birlikte yapıp yazılı bir değerlendirme çıkaralım.
Okumanızı öneririz: Yazılım geliştirme sürecimiz: analizden yayına adım adım
Sık Sorulan Sorular
Mikroservis nedir, kısaca nasıl çalışır?
Uygulamanın, her biri tek bir iş yeteneğini yürüten, kendi verisine sahip ve bağımsız yayınlanabilen küçük servislere bölünmesidir. Servisler birbirleriyle arayüz ya da mesajlaşma üzerinden konuşur.
Mikroservis ile monolit arasındaki fark nedir?
Monolit tek parça yayınlanır ve genellikle ortak bir veritabanı kullanır. Mikroservis servis başına ayrı yayınlanır, ayrı veriye sahiptir ve servis servis ölçeklenir; karşılığında operasyon karmaşıklığı ve maliyet daha yüksektir.
Mikroservis her proje için daha mı iyidir?
Hayır. Küçük ve orta ölçekli işletme uygulamalarının çoğunda net modül sınırları olan bir monolit daha ucuz ve daha kolay yönetilir. Mikroservis çok ekip, farklı ölçek ya da bağımsız yayın ihtiyacı olduğunda anlam kazanır.
Mikroservis maliyeti ne kadar artırır?
Örnekte aynı kapsamın üç yıllık maliyeti monolitte ₺843.000, beş servisli mikroservisde ₺1.273.050'dir; fark yaklaşık %51. Rakamlar temsilîdir; geliştirme eforu, altyapı ve bakım payını kendi projeniz için yeniden hesaplayın.
Mevcut monoliti mikroservise nasıl dönüştürürüm?
Önce modül sınırlarını netleştirin, sonra ayrı ölçek ya da yayın ritmi isteyen tek bir parçayı seçip arayüzünü ve verisini ayırın, eski yolla paralel çalıştırın ve doğrulayınca eski kodu kaldırın. Tek seferde yeniden yazmaktan kaçının.