Monolit mi, mikroservis mi?
30 saniyede özet
Uygulamayı küçük servislere bölmek bir yükseltme değil, bir takas. Ekipler birbirini beklemeden yayına çıkabilir; karşılığında ağ hataları ve servisler arasında veri tutarlılığı derdi gelir.
Bir uygulamayı tek parça mı tutmalı, küçük servislere mi bölmeli? Bunun doğru bir cevabı yok, bir takası var. “Mikroservis daha modern” demek, dağıtık bir hatayı hiç kovalamamış olmaktan gelir.
Adım adım oku
- Monolitte her şey aynı evdedir: tuzu yan odaya seslenerek istersin, cevap hemen gelir.
- Mikroservislerde herkesin kendi evi var: her ekip kendi mutfağını istediği gibi düzenler ve ayrı yayın yapar.
- Ama tuz istemek artık kapıya çıkmak, yani ağ üzerinden çağrı yapmaktır; bazen kapıyı açan olmaz.
- Doğru cevap yok, bir takas var: bağımsızlık kazanılır, her çağrı pahalanır ve bozulabilir hâle gelir.
-
Bayt: Herkes mikroservise geçiyor. Biz de uygulamamızı on parçaya bölelim mi?
-
Sen: Daha modern gibi duruyor.
-
Bayt: Modern mi, yoksa sadece başka türlü zor mu? Aynı ev ile ayrı evler arasındaki farka bakalım.
-
Bayt: Doğru cevap yok, bir takas var. Önce neyi satın aldığını bil!
Asıl soru ne?
Siparişi ve ödemeyi tek bir COMMIT ile kaydeden bir monolit, ikisini ayrı mikroservislere böldü. O tek COMMIT'e ne olur? Cevabı göster
Artık yok. İki servis iki ayrı veritabanına yazar; birlikte tutarlılık saga ya da eventual consistency ile kurulur.
Üç mimari de aynı işi yapabilir. Fark, işin nerede zorlaştığında.
| Monolit | Modüler monolit | Mikroservis | |
|---|---|---|---|
| Deploy birimi | 1 | 1 | N |
| Modüller arası çağrı | Metot çağrısı | Metot çağrısı (sınırlı arayüz) | Ağ çağrısı |
| Transaction | Tek COMMIT | Tek COMMIT | Saga / eventual consistency |
| Bir modülü ölçekle | Hepsini ölçekle | Hepsini ölçekle | Sadece onu ölçekle |
| Hata yarıçapı | Tüm uygulama | Tüm uygulama | Tek servis (teoride) |
| Bir hatayı izlemek | Stack trace | Stack trace | Dağıtık trace |
| Takım bağımsızlığı | Düşük | Orta | Yüksek |
Dikkat et: mikroservis sütununda kazanç da var, kayıp da. Bu tablo bir kazanan ilan etmiyor.
Kafam karıştı, daha basit anlat
Monolit tek bir büyük ev, mikroservis ise aynı mahallede ayrı evlerdir. Ayrı evde herkes kendi odasını boyar, ama birbirine ulaşmak için dışarı çıkmak gerekir.
Monolitte bir metot çağrısı, mikroserviste ağ çağrısına dönüştüğünde ne değişir?
Yan odaya seslenmek, başka şehri aramak
Bu, tüm konunun özeti. Monolitte şu satır ya çalışır ya exception fırlatır:
var stock = inventoryService.reserve(orderId, items);Mikroservise böldüğünde aynı satır artık bir HTTP çağrısı:
var stock = inventoryClient.reserve(orderId, items);// Artık bu satır şu şekillerde de "başarısız" olabilir:// - istek gitti, cevap dönmedi (timeout) -> rezervasyon yapıldı mı, bilmiyorsun// - 503 döndü -> tekrar dene, ama kaç kez?// - iki kez gitti -> idempotent değilse çift rezervasyon// - cevap 4 saniye sürdü -> çağıran thread'i tuttu// - servis ayakta ama yavaş -> en tehlikelisi, timeout'a takılmazKod bir satır. Düşünmen gereken hata senaryosu beş tane. Mikroservisin gerçek maliyeti burada.
Kafam karıştı, daha basit anlat
Aynı evde yan odaya seslenmek her zaman duyulur. Başka şehri telefonla aradığında ise hat meşgul olabilir, çekmeyebilir ya da cevap geç gelebilir.
Her biri %99.9 kullanılabilirliğe sahip dört servis senkron zincir hâlinde çağrılıyor. Zincirin kullanılabilirliği ne olur?
Senkron zincir gecikmeyi toplar
Dört servisi arka arkaya çağırırsan gecikmeler toplanır, ortalanmaz:
Gateway ──50ms──> Order ──40ms──> Payment ──60ms──> Stock ──30ms──> Shippingtoplam: 180ms (en yavaş halkaya değil, hepsinin toplamına bakılır)Ve kullanılabilirlik çarpılır. Her servis %99.9 ise zincirin tamamı %99.9⁴ ≈ %99.6 olur: ayda yaklaşık üç saat kesinti. Dört tane “çok sağlam” servis, birlikte daha kırılgandır.
Aynı sipariş, üç mimari
Tohum 56252- Gateway
- → →Sipariş
- → →Ödeme
- → →Stok
- → →Kargo
Gecikme
—
Erişilebilirlik
—
Transaction
—
Deploy beklemesi
—
Şu an ne oldu?
Mikroservis · 2 takım · 4 servislik zincir
Bir sipariş isteğinin yolunu ve ekiplerin yayın hızını birlikte izle.
Görevler0/3
Erişilebilirliği %99,3’ün altına düşüraçık
İpucu
Zinciri uzat.
Hazır bir değişikliği 3 gün bekletaçık
İpucu
Çok takım, tek deploy.
Çok takımı beklemeden yayınlat, erişilebilirliği %99,8’in üstünde tutaçık
İpucu
Bölmeyi gerektiren sebep var, zinciri kısa tut.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
- Varsayılanla oynat. Dört servislik zincir: 180 ms ve %99,6.
- Zinciri 8 servise çıkar. Gecikme 340 ms’ye çıktı, erişilebilirlik %99,2’ye düştü.
- “Monolit” ve “6 takım” seç. Çağrılar ucuz ve tek COMMIT var, ama hazır bir değişiklik ortak sırada 3 gün bekliyor.
- “Mikroservis”, “6 takım” ve “2 servis” seç. Takımlar beklemiyor ve erişilebilirlik %99,8’de kaldı.
modüler monolitTek deploy birimi, ama modüller birbirinin iç yapısına dokunamaz. Sınırlar yanlışsa `git mv` ile düzeltilir, servis silip yeniden yazarak değil.Sözlükte gör → — genelde doğru başlangıç. Bölmeden önce sınırları kod içinde çiz. Tek deploy, tek veritabanı, ama modüller birbirinin iç yapısına dokunamıyor:
com.shop├── order // sadece order.api paketi dışarı açık│ ├── api // OrderFacade — diğer modüller yalnızca bunu görür│ └── internal // entity'ler, repository'ler, servisler├── payment│ ├── api│ └── internal└── inventory ├── api └── internalKazanç: sınırlar yanlışsa bunu bir git mv ile düzeltirsin, servis silip yeniden yazarak değil. Sınırlar doğruysa ayırmak zaten kolaydır.
Her gerekçeyi, servisleri bölmek için geçerli bir sebep olup olmadığına göre ayır.
Ne zaman gerçekten bölünür?
Bölmek için bir sebep gerekir, ve bu sebeplerin çoğu teknik değildir:
- Takım sayısı. Altı takım aynı deploy kuyruğunda sıra bekliyorsa, sorun mimaridir.
- Farklı ölçek profili. Görüntü işleme 32 GB RAM isterken ödeme servisi 512 MB istiyorsa, aynı kutuda taşımak pahalıdır.
- Farklı değişim hızı. Günde on kez değişen katalog ile yılda iki kez değişen muhasebe aynı deploy’a bağlı olmamalı.
- Farklı uyumluluk sınırı. Kart verisi PCI kapsamındaysa onu ayırmak kapsamı küçültür.
Bu dördünden hiçbiri yoksa, mikroservis büyük ihtimalle sana sadece operasyon yükü getirir.
Kafam karıştı, daha basit anlat
Bölmenin iyi sebepleri çoğu zaman insanlarla ilgilidir: çok sayıda takımın birbirini beklemesi gibi. “Moda olduğu için” bölmek, mahalleye taşınıp her gün yan eve telefon etmektir.
İki mikroservisin aynı veritabanı tablosuna yazması neden sorundur?
Tuzaklar
En kötü sonuç ikisinin ortası — adı dağıtık monolitServisleri ayırıp bağımsızlığı kazanamamış sistem: ortak veritabanı, koordineli deploy, senkron zincirler.En kötü bileşim — monolitin kolaylığını kaybeder, mikroservisin faydasını almazsın. Teşhis sorusu tek: bir servisi tek başına deploy edebiliyor musun?Sözlükte gör →. Servisleri ayırdın ama:
- hepsi aynı veritabanını paylaşıyor,
- biri değişince diğerlerini de deploy etmen gerekiyor,
- çağrılar senkron zincir halinde.
Bu durumda monolitin kolaylığını kaybettin, mikroservisin faydasını kazanmadın. Bu tabloyu tanımak, aynı yola tekrar girmemenin en pratik yolu.
Aşağıdaki örnek bir dijital bankanın modüler monolitinden: hesap, transfer ve kart modülleri tek deploy’da, ama sınırları bir testle korunuyor.
Derinleş · Dijital bankanın modüler monoliti 5 dosya · ~96 satır · ilk okumada atlayabilirsin
Kendini sına
Mikroservisler her zaman monolitten daha iyidir.
Dört servis senkron zincir halinde çağrılıyor ve her birinin kullanılabilirliği %99.9. Zincirin tamamının kullanılabilirliği yaklaşık kaçtır?
Aklında kalacak üç şey
- 1 Mikroservis teknik değil, organizasyonel bir tercihtir: ekipler birbirini beklemeden yayına çıkabilsin diye bölersin.
- 2 Bedeli somut: ağ çağrısı başarısız olabilir, transaction artık tek bir COMMIT değildir, hata ayıklamak birden çok servisin izini sürmek demektir.
- 3 Arada üçüncü bir yol var: modüler monolit. Sınırları önce kodun içinde çiz, gerçekten gerekince ayrı servislere ayır.
5 kart sonraki derste seni bekliyor
Bu dersin üstüne kurulanlar
Bunlar bu dersi temel alıyor; hazır olduğunda devam edebilirsin.
- Mikroservisler & Design PatternsCircuit BreakerYavaşça ölen bir servis, onu çağıran servisi nasıl yanında götürür?Derse git
- Mikroservisler & Design PatternsSaga PatternÖdeme alındı ama kargo oluşturulamadı. Servisler ayrıyken işi nasıl geri alırsın?Derse git
- Mikroservisler & Design PatternsServisler Arası İletişim DesenleriBir istek dört servise uğruyorsa, hepsinin aynı anda çalışıyor olma ihtimali ne olur?Derse git