Servisler Arası İletişim Desenleri
Önce şunu oku: Monolit mi, mikroservis mi?
30 saniyede özet
Bir istek dört servise uğruyorsa bekleme süreleri toplanır, çalışma ihtimalleri ise çarpılır. Çağrıları aynı anda yapmak beklemeyi kısaltır ama çalışma ihtimalini hiç değiştirmez; onun için başka bir çözüm gerekir.
Birini telefonla aradığında onun o anda müsait olması gerekir. Dört kişiyi arka arkaya aramak zorundaysan, işin biraz daha zorlaşır.
Adım adım oku
- Senkron zincirde A, B'yi; B, C'yi; C de D'yi arar ve her biri cevap gelene kadar bekler.
- Bekleme süreleri toplanır: isteğin süresi zincirdeki bütün servislerin süreleri kadardır.
- Her servis kendi başına zamanın yüzde doksan dokuzunda ayaktaysa, dördünün birden ayakta olma ihtimali çarpılarak düşer.
- Mesaj bırakmak zinciri kırar: gönderen beklemez, alıcı uygun olunca işler; bedeli cevabın hemen gelmemesidir.
-
Bayt: Servislerimizin her biri tek başına çok güvenilir. Zincir de öyle olur, değil mi?
-
Sen: Mantıklı gibi.
-
Bayt: Ama dört servisi arka arkaya çağırınca hem yavaşladık hem daha sık hata aldık!
-
Bayt: Telefonla aramak ile mesaj bırakmak arasındaki farkı düşün.
Bir istek dört servise uğruyor. Bu cümlenin iki ayrı maliyeti var ve bunlar farklı matematikle hesaplanır.
Biri toplanır, biri çarpılır
Dört servis zincir hâlinde senkron çağrılıyor ve her biri yüzde 99.9 ayakta. Zincirin tamamı birlikte daha mı sık ayakta, daha mı az? Cevabı göster
Daha az. Kullanılabilirlikler çarpılır; her yeni halka zinciri biraz daha kırılgan yapar.
Gecikme toplanır:
Gateway ──60ms──> Order ──60ms──> Payment ──60ms──> Stock ──60ms──> Shippingtoplam: 240 msKullanılabilirlik çarpılır:
her servis %99.9 → 0.999⁴ = %99.60 → ayda ~173 dakika kesintiDört tane “üç dokuzlu” servis, birlikte üç dokuzdan daha kötüdür. Zincire eklenen her halka ikisini birden bozar.
Kafam karıştı, daha basit anlat
Servisleri zincir hâlinde arka arkaya çağırırsan bekleme süreleri toplanır. Her birinin çalışma ihtimali ise çarpılır: halka arttıkça zincirin kopma ihtimali büyür.
Senkron ve asenkron iletişim arasındaki temel fark nedir?
Kendin gör
Servisler arası iletişim — gecikme toplanır, kullanılabilirlik çarpılır
Tohum 5- Orderbekliyor
- Paymentbekliyor
- Inventorybekliyor
- Shippingbekliyor
Gecikme — toplanır
0 ms/ beklenen 240 ms
4 × 60 ms
Kullanılabilirlik — çarpılır
%99.60
%99.9 ^ 4 · ayda ~173 dk kesinti
Şu an ne oldu?
İstek başlıyor
Zincirde bir sonraki çağrı, bir öncekinin cevabı gelmeden başlayamaz. Bu yüzden süreler toplanır.
Aklında kalsın: Her servis tek tek %99.9 kullanılabilir; 4 tanesi birlikte %99.60.
Görevler0/3
Zincirdeki tek bir servisin düşmesiyle bütün isteği kaybetaçık
İpucu
Kullanılabilirliği en düşük dokuza, servis sayısını en yükseğe çek. Olmazsa "Yeni senaryo" dene.
Dört veya daha fazla servisi tek bir servisin süresinde çağıraçık
İpucu
Deseni paralel yap. Gecikme en yavaş çağrıya iner — ama kullanılabilirlik hâlâ çarpılır.
Her servis %90 kullanılabilirken isteği yine de kabul ettiraçık
İpucu
Asenkron desende çağıran yalnızca broker’a yazar; aşağıdaki servisler sonra, kendi hızlarında işler.
Olay günlüğü (0)
Henüz olay yok. Oynat veya adımla.
Karşılaştır:
Zincir, 4 servis, 60 ms. Toplam 240 ms. Kullanılabilirlik kartına bak: %99.60.Paralelyap. Gecikme 60 ms’ye düşüyor ama kullanılabilirlik değişmiyor.- Servis sayısını 6 yap. İkisi de kötüleşiyor: gecikme 360 ms, kullanılabilirlik %99.40.
- Dokuz sayısını 2 yap (%99). Dört servis birlikte %96 — ayda 29 saat kesinti.
Asenkronseç. Çağıran 10 ms’de 202 alıyor ve kullanılabilirlik kartı boşalıyor: cevap yolu artık servislere bağlı değil.
Simülatörün altındaki Görevler bu dört gözlemi hedefe çeviriyor: zincirin kırılması, paralelin gecikme kazancı ve asenkronun kullanılabilirlik kazancı.
Kafam karıştı, daha basit anlat
Telefonla aramak, karşı taraf açana kadar beklemektir. Mesaj bırakmak ise hemen işine dönmektir, cevap sonra gelir.
Dört servisi zincir yerine paralel çağırmak neyi değiştirir?
Telefonla aramak
| Desen | Gecikme | Kullanılabilirlik | Ne zaman |
|---|---|---|---|
| Zincir | Toplam | Çarpım | Her adım bir öncekinin sonucuna ihtiyaç duyuyorsa |
| Paralel / Branch | En yavaş çağrı | Çarpım | Çağrılar birbirinden bağımsızsa |
| Aggregator | En yavaş çağrı | Çarpım | Bir ekran için birden fazla servisten veri toplanıyorsa |
Üçünde de kullanılabilirlik aynı: çarpım. Çünkü başarı için hepsinin dönmesi gerekir.
var user = supplyAsync(() -> userClient.fetch(id));var orders = supplyAsync(() -> orderClient.fetch(id));var prefs = supplyAsync(() -> prefsClient.fetch(id));
allOf(user, orders, prefs).join(); // 3 × 60 ms değil, 60 msAma bu kod hâlâ üç servisin de ayakta olmasını gerektirir.
Kullanılabilirliği gerçekten düzelten şeyler. Paralelleştirme değil, bağımlılığı kaldırmak veya zorunluluğunu azaltmak:
- Asenkron mesajlaşma. Çağıran broker’a yazar ve döner. Tüketici düşse bile mesaj kuyrukta bekler — karşılığında eventual consistencySistemin bir süre tutarsız kalıp sonunda tutarlı hâle gelmesi. Saga'nın verdiği garanti budur; arada geçilen ara durumu tasarımın kabul etmesi gerekir.Sözlükte gör → kabul edersin.
- Zorunlu olmayan çağrıyı isteğe bağlı yapmak. Öneri servisi düştüyse ürün sayfası önerisiz açılsın.
allOfyerineanyOf+ fallback. - Önbellek. Servis düştüğünde bayat veri dönmek, hiç dönmemekten iyidir.
- Veriyi kopyalamak. Sipariş servisi müşteri adını kendi kaydında tutarsa, o çağrı tamamen ortadan kalkar.
Son madde en güçlüsüdür: yapılmayan çağrı asla başarısız olmaz.
Her çağrıyı senkron mu kalmalı, asenkrona mı çevrilmeli diye sınıflandır.
Mesaj bırakmanın bedeli
Asenkron mesajlaşma bedava değil. Sattığın şeyler:
- Eventual consistency. İstemci 202 aldı ama iş henüz bitmedi. Arayüzün bunu göstermesi gerekir.
- “Bitti mi?” sorusu. Durum sorgulama endpoint’i, webhook veya bir olay akışı gerekir.
- Hata görünürlüğü. Senkron çağrıda hata çağırana döner; asenkronda kuyrukta kalır ve kimse bakmazsa kaybolur. DLQ ve alarm şart — ayrıca tüketicinin idempotencyAynı işlemin bir kez de on kez de çalışsa aynı sonucu vermesi. Dağıtık sistemde timeout aldığında işlemin yapılıp yapılmadığını bilemediğin için zorunludur.Sözlükte gör → olması gerekir, çünkü teslim en-az-bir-kezdir.
- İşletme yükü. Broker artık bakımını yapman gereken bir bileşen.
Bu yüzden her çağrıyı asenkron yapmak da yanlıştır. Kullanıcının cevabı beklediği işlemler senkron kalmalıdır.
Timeout bütçesi. Zincirde her servisin kendi timeout’u varsa toplam bekleme çarpıcı şekilde büyür:
Gateway timeout: 1000 ms ├─ Order timeout: 800 ms │ └─ Payment timeout: 800 ms ← ikisi birlikte 1600 ms, gateway çoktan pes ettiKural: timeout bütçesiBir zincirdeki timeout değerlerinin içten dışa artacak şekilde bölünmesi. Dıştaki içtekinden küçükse çağıran vazgeçer ama iş devam eder.Sözlükte gör → yukarıdan aşağı dağıtılır. Her servis, çağırandan aldığı kalan süreyi bilmeli ve alt çağrısına ondan azını vermeli. Aksi halde gateway vazgeçtikten sonra alt servisler boşuna çalışmaya devam eder.
Kafam karıştı, daha basit anlat
Mesaj bıraktığında iş hemen bitmez. Kullanıcıya “alındı, işleniyor” demek ve sonucu sonra göstermek gerekir.
Bir servis olay yayınlarken veritabanına yazma ile mesaj gönderme arasındaki tutarlılığı nasıl sağlarsın?
Tuzaklar, servis keşfi ve yük dengeleme
Senkron çağrı yapabilmek için önce adresi bulmak gerekir:
- İstemci tarafı keşif — istemci kayıt defterinden listeyi alır ve kendi seçer (Eureka + Ribbon). Ek ağ sıçraması yok, ama her istemciye mantık gömülür.
- Sunucu tarafı keşif — istemci sabit bir adrese gider, yönlendirmeyi altyapı yapar (Kubernetes Service, yük dengeleyici). Basit, ama bir sıçrama daha ekler.
Kubernetes ortamında ikincisi neredeyse her zaman doğru cevaptır — keşif altyapının işidir, uygulamanın değil.
Aşağıdaki örnek bir bankanın mobil uygulamasından: ana ekran üç servisten veri topluyor, hesap dökümü PDF’i ise mesajla hazırlanıyor.
Derinleş · Mobil bankacılık: senkron toplama, asenkron döküm 5 dosya · ~105 satır · ilk okumada atlayabilirsin
Kendini sına
Senkron bir çağrı zincirinde bekleme süreleri toplanır.
Dört servisi zincir yerine `CompletableFuture` ile paralel çağırdın. Ne değişti?
Aklında kalacak üç şey
- 1 İki ayrı hesap var: bekleme süreleri toplanır, ayakta kalma ihtimalleri çarpılır. Bu ikisini karıştırmamak zincir tasarımının tamamını açıklar.
- 2 Çağrıları paralel yapmak beklemeyi toplamdan en uzuna indirir, ama ayakta kalma ihtimalini değiştirmez: hâlâ her çağrının başarılı olması gerekir.
- 3 Asenkron iletişim anlık bağımlılığı kaldırır; karşılığında 'iş ne zaman bitti?' sorusunu ve verinin bir süre farklı görünmesini getirir.
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 PatternsOutbox ve Idempotent Consumer — Olay Kaybolmasın, İki Kez de İşlenmesinSiparişi veritabanına yazdın, mesajı gönderemeden uygulama çöktü. Sipariş var ama kimsenin haberi yok. Ne yapmalı?Derse git
- Mikroservisler & Design PatternsgRPC ve REST — Aynı Havale, İki DilSunucu bir alanın numarasını değiştirdi. Hiç hata yok, ama alıcı IBAN'ı kayboldu. Nasıl?Derse git
- Mikroservisler & Design PatternsRabbitMQ — Mesaj Hangi Kuyruğa Gider?Ödeme servisi olayı yayınladı, hata da almadı. Peki olay neden hiçbir servise ulaşmadı?Derse git
- Mikroservisler & Design PatternsIBM MQ ve Sıralı Teslim — Gerçekleşme, Emirden Önce Nasıl İşlendi?Kuyrukta önce yeni emir, sonra gerçekleşmesi vardı. Hızlansın diye üç tüketici açtın. Neden gerçekleşme, emir yokken geldi?Derse git