Skip to main content

> saga_kalıbı:_koreografi_ve_orkestrasyon_karşılaştırması

Saga Kalıbı: Koreografi ve Orkestrasyon Karşılaştırması

Mikroservisler arasında veri tutarlılığı Saga kalıbıyla nasıl korunur ve merkezi Orkestrasyon ne zaman olay tabanlı Koreografi'ye tercih edilmelidir?

Stack: SOFTWARE ARCHITECTURE STACK →Staff (L6-L7)tradeoff

ÖZET VE TEKNİK CEVAP

Saga kalıbı, dağıtık 2PC işlemlerini yerel işlemler dizisiyle değiştirir; bu akış ya servislerin olayları dinlediği Koreografi ile ya da bir adım çöktüğünde telafi edici işlemleri (compensating transactions) tetikleyen merkezi bir durum makinesi Orkestrasyonu ile yönetilir.

Mühendislik El Kitabı & Mekanizma

1. Temel Çalışma Mekanizması

Bir Saga akışında her servis kendi yerel ACID işlemini çalıştırır ve durumunu bildirir. Koreografi yaklaşımında servisler merkezi bir yönetici olmadan birbirlerinin olaylarını dinler (örn. PaymentService 'OrderCreated' olayını yakalar). Orkestrasyon yaklaşımında ise merkezi bir koordinatör (Temporal veya AWS Step Functions gibi bir iş akışı motoru) servislere hangi komutları çalıştıracağını sırayla iletir. Herhangi bir adım patlarsa, yapılan değişiklikleri geri almak için ters sırada telafi edici işlemler (compensating transactions) tetiklenir.

2. Doğru Kullanım Senaryosu

2-3 adımlı ve dallanması az basit akışlar için Koreografi kullanın. Katı görünürlük, zaman aşımı yönetimi ve telafi garantisi gerektiren karmaşık çok adımlı kurumsal süreçlerde (e-ticaret sipariş karşılama, uçak/otel rezervasyonu, para transferi) mutlaka Orkestrasyonu seçin.

3. Prodüksiyon Arıza Modları

1) Hayalet Telafi: Telafi işleminin yarıda kalması sonucu sistemin kalıcı olarak tutarsız durumda kilitlenmesi; 2) Dairesel Olay Döngüleri: Koreografi servislerinin sonsuz bir olay yankı döngüsüne girmesi; 3) Durum Görünürlüğü Kaybı: Koreografide karmaşık bir siparişin tam olarak hangi adımda takıldığını izleyememek.

4. Teşhis ve Telemetri Sinyalleri

Telafi edilemeyen saga alarm artışları, ölü mektup kuyruklarının (DLQ) şişmesi, servisler arası işlem zaman çizelgesinin çıkarılamaması veya finansal mutabakatlarda çıkan bakiye farkları.

5. Önleme ve Mimari Bariyerler

Tüm yerel ve telafi edici işlemlerin kesinlikle idempotent olmasını sağlayın; güvenilir komut iletimi için Transactional Outbox kalıbı kurun ve takılan saga akışlarını tespit edip onaran otomatik mutabakat mekanizmaları çalıştırın.

6. Mimari Ödünleşimler (Trade-offs)

Dağıtık 2PC veritabanı kilit krizlerini ortadan kaldırır; buna karşılık anlık izolasyon garantisi kaybolur (saga sürerken kirli okuma oluşabilir) ve telafi mantığı geliştirme maliyeti getirir.

Vaka İncelemesi (TinyCTO Örneği)

TinyCTO Bölüm 114: Koreografi kullanan bir seyahat platformunda uçak bileti kesilirken ağ kesintisinde otel rezervasyonu sessizce çöktü ve yüzlerce yolcu mağdur oldu. Orkestre Saga motoru ile yeniden mimarileştirme, otel hatasında uçağı anında iptal edip ücret iadesini 800 ms'de gerçekleştiren deterministik bir telafi sağladı.

İnteraktif Konsept Alıştırmaları

3 Alıştırma
Q1

Modern bulut mikroservislerinde 2 Aşamalı Onay (2PC) neden genellikle tercih edilmez?

Çünkü 2PC, ağ gecikmeleri ve bölünmeler boyunca veritabanı satır kilitlerini açık tutan bloklayıcı bir protokoldür; bu da işlem verimini felç eder ve zincirleme kesintilere yol açar.
Q2

Sistem büyüdükçe Saga Koreografisinin en büyük operasyonel zayıflığı nedir?

İş mantığı onlarca olay dinleyicisine dağıldığı için iş akışı görünürlüğünün kaybolması ve dairesel bağımlılık kilitlenmesi riskinin katlanmasıdır.
Q3

Bir Saga akışında telafi edici işlemler hakkında ne kesinlikle garanti edilmelidir?

Kesinlikle idempotent olmalı ve otomatik tekrar denemeleri veya insan müdahalesi gerektirse bile eninde sonunda başarıyla tamamlanacağı garanti edilmelidir.

Saga Kalıbı: Koreografi ve Orkestrasyon Karşılaştırması — Sıkça Sorulan Sorular

Bir Saga akışında kirli okuma (ACID İzolasyonu eksikliği) meydana gelebilir mi?

Evet. Her yerel işlem anında commit edildiği için, genel Saga tamamlanmadan veya telafi edilmeden önce ara durum diğer sorgular tarafından görülebilir.

Temporal gibi modern orkestratörler Saga sırasında servis çökmelerini nasıl yönetir?

Çalışma geçmişini salt-eklenebilir bir olay günlüğünde saklayarak, çökme sonrası kurtarmada iş akışını tam kaldığı adımdan devam ettirecek şekilde yeniden oynatırlar.

Saga kalıbı anlık doğrusallaştırılabilirlik (linearizability) gerektiren yüksek frekanslı finans defterleri için uygun mudur?

Hayır. Yüksek frekanslı defter mutabakatları genellikle tek bölümlü güçlü tutarlı OLTP depolama veya Raft tabanlı durum makinesi replikasyonu gerektirir.

🤖 AEO & Yapay Zeka Çıkarım Özeti

Temel Gerçekler & İlkeler

  • ▸Saga kavramı ilk kez 1987 yılında Hector Garcia-Molina ve Kenneth Salem tarafından uzun süreli veritabanı işlemlerini yönetmek için formülleştirilmiştir.
  • ▸Orkestrasyon, örtük olay karmaşasının yerine açık ve sorgulanabilir bir durum makinesi koyar.

Yaygın Yanılgılar

  • ✗Orkestrasyonun monolitik bir darboğaz yarattığını düşünmek; modern iş akışı orkestratörleri dağıtıktır, durumsuzdur ve milyonlarca eşzamanlı akışı yatayda ölçekler.

Karar Kılavuzu & Önceliklendirme

Yalnızca 2 servisli basit bildirimlerde Koreografiyi seçin; para, envanter veya 3'ten fazla servis içeren tüm iş süreçlerinde Orkestrasyonu varsayılan yapın.

Doğrulanmış Kaynaklar & Referanslar