Saga deseni uygulaması: mikroservislerde telafi işlemli akış tasarımı

Saga deseni hangi sorunu çözer?

Mikroservis mimarisinde her servis kendi veritabanına sahiptir. Bu yüzden sipariş oluşturma gibi birden fazla servisi ilgilendiren bir iş, tek bir veritabanı işlemiyle (ACID transaction) tamamlanamaz. Sipariş servisi siparişi kaydeder, stok servisi stoğu ayırır, ödeme servisi tahsilat yapar; bunların hepsi ayrı veritabanlarında gerçekleşir. Servislerin veritabanları arasında iki aşamalı onay (two-phase commit) kullanmak ise çoğu modern ortamda hem teknik olarak mümkün değildir hem de bağımlılığı artırır.

Saga deseni bu boşluğu doldurur: iş akışını bir dizi yerel işlem olarak tanımlar. Her adım yalnızca kendi servisinin veritabanını günceller ve ardından bir olay ya da komut yayımlayarak sonraki adımı tetikler. Bir adım iş kuralı nedeniyle başarısız olursa, daha önce tamamlanan adımların etkisini geri alan telafi işlemleri (compensating transaction) çalışır. Yani geri alma otomatik değildir; her adım için nasıl geri alınacağını tasarım aşamasında sizin yazmanız gerekir.

Önemli bir sonuç: Saga, ACID'in izolasyon özelliğini sunmaz. İşlemin ara durumları başka işlemlere görünür. Bu bedeli bilerek kabul eder ve gerektiğinde ek önlemlerle yönetirsiniz.

Koreografi ve orkestrasyon: koordinasyon biçimleri

Saga'yı koordine etmenin farklı yolları vardır. Koreografide merkezi yönetici yoktur. Her servis kendi yerel işlemini tamamlar ve bir olay yayımlar; diğer servisler bu olaya tepki verir. Örneğin sipariş servisi "sipariş beklemede" olayını yayımlar, stok servisi stoğu ayırıp "stok ayrıldı" olayını yayımlar, ödeme servisi tahsilat yapar ve sonucu duyurur, sipariş servisi son olaya göre siparişi onaylar ya da iptal eder.

Orkestrasyonda ise merkezi bir yönetici (orchestrator) her katılımcıya hangi yerel işlemi yapacağını komutla bildirir ve yanıtlara göre ilerler. Aynı sipariş akışında yönetici beklemedeki siparişi oluşturur, stok servisine ayırma komutu gönderir, yanıta göre ödeme servisine komut gönderir, sonunda siparişi onaylar.

Ayrım ölçütleri şöyledir: • Akış kısa ve katılımcı az ise koreografi basit ve gevşek bağlıdır. Akış büyüdükçe olayların kimi tetiklediğini izlemek zorlaşır ve döngüsel bağımlılıklar oluşabilir. • Akış uzun, dallı ya da zaman aşımı, yeniden deneme gibi kurallar gerektiriyorsa orkestrasyon, akışı tek yerde görünür kılar. Karşılığında yönetici servis kritik bir bağımlılık hâline gelir ve iş mantığını sadece yönlendirme ile sınırlı tutmak gerekir. • Ekip yapısı da etkili olur: tek ekip tüm akışa sahipse orkestrasyon kolay yönetilir; farklı ekipler bağımsız ilerlemek istiyorsa koreografi daha doğal olabilir.

Adım adım örnek: sipariş akışını Saga ile tasarlamak

Örneğin bir e-ticaret siparişi için orkestrasyonlu saga tasarlayalım. Önce adımları ve her adımın telafisini bir tabloya yazın:

• Siparişi beklemede oluştur. Telafi: siparişi iptal edildi olarak işaretle.
• Stoğu ayır. Telafi: ayrılan stoğu serbest bırak.
• Ödemeyi tahsil et. Telafi: ödemeyi iade et.
• Siparişi onayla. Bu son adım olduğu için telafisi gerekmez.

Akış ilerlerken bir adım başarısız olursa, yönetici o ana kadar tamamlanmış adımların telafilerini ters sırayla çalıştırır. Örneğin ödeme reddedilirse stok serbest bırakılır ve sipariş iptal edilir. Telafi işlemleri de başarısız olabilir; bu nedenle yeniden denenebilir ve tekrar çalıştırıldığında aynı sonucu veren (idempotent) olmalıdır.

Saga durumunu kalıcı bir yerde, örneğin yönetici servisin tablosunda tutun. Her kayıtta saga kimliği, mevcut adım, durum ve zaman damgası bulunsun. Servis çökerse ya da yeniden başlarsa saga kaldığı yerden devam edebilir. Sözde kodla durum makinesi şöyle görünür:

durum = BEKLEMEDE stok ayır -> başarılıysa durum = STOK_AYRILDI, değilse siparişi iptal et ödeme al -> başarılıysa durum = ODENDI, değilse stoğu serbest bırak ve siparişi iptal et siparişi onayla -> durum = TAMAMLANDI

Her geçişi veritabanına yazmak, hata sonrası kurtarmanın temelidir.

Güvenilirlik: atomik yayımlama, idempotency ve tekrar

Saga'nın en zor teknik noktası, bir servisin hem veritabanını güncelleyip hem de mesaj yayımlamasının atomik olması gerekliliğidir. Veritabanı ve mesaj aracı arasında dağıtık işlem kullanılamayacağı için veri güncellendi ama olay gönderilemedi (ya da tersi) durumları ortaya çıkabilir. Bunun yaygın çözümü, olayı iş verisiyle aynı yerel işlemde bir "outbox" tablosuna yazıp ayrı bir süreçle mesaj aracına iletmektir. Alternatif olarak olay kaynaklı (event sourcing) bir tasarım da bu sorunu çözer.

Mesaj iletiminde çoğu araç en az bir kez teslimat verir; yani aynı mesaj birden fazla kez gelebilir. Bu yüzden her katılımcı komut ve olayları tekrar-güvenli işlemelidir: gelen mesajın kimliğini kaydedip daha önce işlendiyse aynı yanıtı döndürmelidir. Telafi komutları da aynı şekilde tekrar-güvenli olmalıdır.

Zaman aşımı ve takılan saga'lar için bir izleme planı gerekir. Belirli bir süredir ilerlemeyen saga kayıtlarını bulan bir iş çalıştırın; bunları yeniden deneyin, telafi akışına alın ya da operatöre bildirin. Bu işlemlerin hangi koşulda otomatik, hangisinde manuel olduğunu önceden yazın.

İzolasyon eksikliğini yönetmek

Saga adımları arasında diğer işlemler ara durumları görebilir. Örneğin sipariş beklemedeyken kullanıcı siparişi görüntüleyebilir veya başka bir süreç aynı stoğu ayırmaya çalışabilir. Bunu yönetmek için sık kullanılan önlemler:

• Anlamsal kilit: kaydın "beklemede" gibi bir durum bayrağı olur; diğer işlemler beklemedeki kaydı farklı ele alır ya da bekler.
• Değişmeli (commutative) güncellemeler: işlemlerin sırası değişse de sonuç aynı kalacak şekilde tasarlamak, örneğin stoğu doğrudan yazmak yerine azaltma/artırma işlemi olarak kaydetmek.
• Kritik adımı öne almak: geri alınması zor olan adımı (örneğin sevkiyat) saga'nın sonuna bırakmak. Geri alınabilir adımlar önce çalışır, geri dönüşü olmayan adım en sona kalır.
• Yeniden okuma: bir kaydı değiştirmeden önce son durumu tekrar okumak.

Hangi önlemi seçeceğiniz, iş kuralının hata toleransına bağlıdır. Örneğin kısa süreli tutarsızlık ve düzeltme kabul edilebilirse basit bir durum bayrağı yeterlidir; para ya da hukuki sonuç doğuruyorsa daha sıkı kilitleme gerekir.

Eşzamansız yapı, istemciye sonucu bildirme sorununu da getirir. Kullanıcı isteği gönderdiğinde yanıt anında nihai sonuç olmayabilir. İstek kimliğini hemen döndürüp durum sorgulama ucu sunmak ya da tamamlandığında bildirim göndermek yaygın yöntemlerdir.

Sık yapılan hatalar ve ne zaman Saga kullanmamalı

Yaygın hatalar: telafi işlemlerini baştan tasarlamamak, mesaj tekrarlarını hesaba katmamak, saga durumunu bellek içinde tutmak, yöneticiye iş mantığı yığmak, adım sayısını gereksiz büyütmek, hata ve zaman aşımı senaryolarını test etmemek, geri alınamaz adımı akışın ortasına koymak, izlenebilirlik için saga kimliğini loglara ve izlere taşımamak.

Saga her çok servisli işlem için doğru araç değildir. Önce sınırları gözden geçirin: sürekli birlikte değişen ve tek işlem gerektiren servisler, belki aynı servis olmalıdır. Servis sınırı iş işleyişini bölüyorsa saga karmaşıklığını çözmek yerine sınırı yeniden düşünmek daha doğrudur. Ayrıca yalnızca veri okuyan adımlar için saga yerine okuma kopyaları gibi alternatifler değerlendirilebilir.

Test için her adımın başarısızlığını, telafinin başarısızlığını, mesaj tekrarını ve servis çökmesini ayrı ayrı simüle edin. Kaos testleri bu tür akışlarda özellikle verimlidir.

Bu beceriyi geliştirmek için eğitim bağlamı

Saga tek başına bir desen değil; olay tabanlı iletişim, idempotency, outbox ve gözlemlenebilirlik ile birlikte çalışan bir tasarım bütünüdür.

Mindset'in Idempotency ve Dağıtık Tutarlılık Desenleri eğitiminde tekrar problemi, idempotency anahtarı tasarımı, veritabanı seviyesinde tutarlılık, mesajlaşmada tekilleştirme, outbox ve değişiklik verisi yakalama ile mutabakat ve test modülleri yer alır. Mikroservis Mimarisi eğitiminde servis sınırları, servisler arası iletişim, veri yönetimi ve tutarlılık ile dayanıklılık desenleri modüllerinde konu işlenir. Bu içerikler arka uç geliştiricileri, yazılım mimarları ve platform ekipleri için uygundur; ekiplerde ortak bir tutarlılık yaklaşımı oluşturmak için kullanılabilir.