E-ticaret Mikroservislerinde Saga Pattern

Giriş

Mikroservis mimarisinde, birden fazla servis arasında dağıtılmış işlemleri yönetmek zorlu olabilir. Saga pattern, distributed transaction kullanmadan bu işlemleri yönetmenin bir yoludur. Bunun yerine, her biri tek bir servis içindeki verileri güncelleyen bir dizi local transaction kullanır. Bir işlem başarısız olursa, Saga önceki işlemlerin etkisini geri almak için compensating transaction yürütür.

Saga Pattern Nedir?

Saga pattern, distributed transaction senaryolarında mikroservisler arasında veri tutarlılığını sağlamak için kullanılan bir tasarım kalıbıdır. Bir Saga, her bir işlemin tek bir servis içindeki verileri güncellediği bir dizi local transaction’dan oluşur. İlk işlem, sistem operasyonuna karşılık gelen external request tarafından başlatılır ve ardından her bir sonraki adım, bir öncekinin tamamlanmasıyla tetiklenir.

Local transaction başarısız olursa, Saga, önceki local transaction’lar tarafından yapılan değişiklikleri geri almak için bir dizi compensating transaction yürütür. Compensating transaction, daha önce tamamlanmış başka bir transaction’ın etkilerini geri alan bir işlemdir.

Neden Saga Pattern Kullanılır?

Mikroservis mimarisinde, bir işlemin birden çok servisi etkilemesi yaygındır. Örneğin, bir e-ticaret uygulamasında bir sipariş oluşturulduğunda, bu işlem genellikle Sipariş Servisi, Stok Servisi, Ödeme Servisi gibi birden fazla servisi içerir. Bu servisler arasında veri tutarlılığını sağlamak kritik öneme sahiptir.

Geleneksel olarak, bu tür senaryolarda distributed transaction (genellikle two-phase commit protokolü ile) kullanılır. Ancak, mikroservisler bağımsız olarak dağıtıldığından ve ölçeklendirildiğinden, distributed transaction kullanmak zorlu hale gelebilir ve sistemin esnekliğini ve performansını etkileyebilir.

Saga pattern, distributed transaction kullanmadan veri tutarlılığını sağlamak için alternatif bir yaklaşım sunar. Her servis kendi local transaction’ını yürütür ve diğer servisleri event’ler aracılığıyla bilgilendirir. Eğer bir adımda hata olursa, compensating transaction’lar yürütülerek önceki adımlar geri alınır. Bu, sistemin tutarlı bir durumda kalmasını sağlar.

Saga Pattern Türleri

Yaygın olarak kullanılan iki tür Saga pattern vardır:

1. Choreography-Based Saga: Bu yaklaşımda, her local transaction, diğer servislerdeki local transaction’ları tetikleyen domain event’leri yayınlar. Merkezi bir koordinasyon yoktur, her servis bir olay alındığında hangi eylemin yapılacağını bilmekten sorumludur.

2. Orchestration-Based Saga: Bu yaklaşım, Saga’yı yöneten merkezi bir orchestrator’a (Saga manager) dayanır. Orchestrator, katılımcılara hangi local transaction’ların yürütüleceğini söylemekten sorumludur. Katılımcılara command mesajları göndererek Saga’yı koordine eder.

E-ticaret Uygulamamızda Saga Pattern

E-ticaret uygulamamızda Choreography-Based Saga pattern’ini kullanıyoruz. Nasıl çalıştığını daha detaylı olarak inceleyelim:

1. Sipariş Oluşturma Saga’sı:

   • Sipariş Servisi, ‘Pending’ durumunda bir sipariş oluşturur ve ‘Order Created’ event’ini yayınlar.
   • Kullanıcı Servisi, ‘Order Created’ event’ini tüketir, kullanıcının kredisini kontrol eder ve yeterliyse krediyi rezerve eder ve ‘Credit Reserved’ event’ini yayınlar. Yetersizse, ‘Insufficient Credit’ event’ini yayınlar.
   • Sipariş Servisi, ‘Credit Reserved’ event’ini tüketir ve ‘Check Stock’ event’ini yayınlar.
   • Ürün Servisi, ‘Check Stock’ event’ini tüketir, ürün stokunu kontrol eder ve yeterliyse stoku rezerve eder ve ‘Stock Reserved’ event’ini yayınlar. Yetersizse, ‘Insufficient Stock’ event’ini yayınlar.
   • Sipariş Servisi, ‘Stock Reserved’ event’ini tüketir, sipariş durumunu ‘Processing Payment’ olarak günceller ve ‘Process Payment’ event’ini yayınlar.
   • Eğer Sipariş Servisi bir ‘Insufficient Credit’ veya ‘Insufficient Stock’ event’i tüketirse, sipariş durumunu ‘Cancelled’ olarak günceller ve ‘Order Cancelled’ event’ini yayınlar.
   • Kullanıcı Servisi ve Ürün Servisi, ‘Order Cancelled’ event’ini tüketir ve rezervasyonlarını geri alır.

   Burada, her servis kendi sorumluluğundaki işlemleri gerçekleştirir ve ilgili event’leri yayınlar. Örneğin, Kullanıcı Servisi kredi kontrolünden, Ürün Servisi stok kontrolünden sorumludur. Eğer herhangi bir adımda bir hata olursa (yetersiz kredi, yetersiz stok gibi), sipariş iptal edilir ve önceki adımlar compensating transaction’lar aracılığıyla geri alınır.

2. Ödeme Saga’sı:

   • Sipariş Servisi, ‘Process Payment’ event’ini tüketir, ödemeyi işler, sipariş durumunu ‘Payment Processed’ olarak günceller ve ‘Payment Processed’ event’ini yayınlar.
   • Sevkiyat Servisi, ‘Payment Processed’ event’ini tüketir, bir sevkiyat kaydı oluşturur ve ‘Order Dispatched’ event’ini yayınlar.
   • Sipariş Servisi, ‘Order Dispatched’ event’ini tüketir ve sipariş durumunu ‘Completed’ olarak günceller.

   Burada, ödeme işlemi tamamlandıktan sonra Sevkiyat Servisi devreye girer ve sipariş sevkiyatı başlatılır. Her adım başarıyla tamamlandıktan sonra ilgili event’ler yayınlanarak diğer servisler bilgilendirilir.

Bu choreography-based yaklaşımda, her servis kendi local transaction’larını yürütmekten ve event’leri yayınlamaktan sorumludur. Diğer servisler bu event’lere tepki verir, kendi local transaction’larını yürütür. Bir transaction başarısız olursa, compensating transaction’lar yürütülerek değişiklikler geri alınır.

Saga Pattern’in Faydaları

• Veri tutarlılığını sağlar: Saga pattern, distributed transaction kullanmadan distributed bir ortamda veri tutarlılığını sağlar.
• Loose coupling sağlar: Servisler, event’ler aracılığıyla iletişim kurarak loosely coupled olur. Her servis bağımsız olarak geliştirilebilir, dağıtılabilir ve ölçeklendirilebilir.
• Performansı artırır: Distributed transaction ve two-phase commit kullanmaktan kaçınarak, Saga pattern sistemin performansını ve ölçeklenebilirliğini artırır.
• Hata toleransını artırır: Local transaction başarısız olursa, compensating transaction’lar yürütülerek değişiklikler geri alınır ve sistemin tutarsız bir durumda kalması önlenir.

Saga Pattern’in Zorlukları

• Karmaşıklık: Saga pattern, özellikle choreography-based yaklaşımda event’lerin akışının takip edilmesi zor hale gelebileceğinden, sisteme karmaşıklık ekleyebilir.
• Eventual consistency: Saga pattern, hemen değil eventual consistency sağlar. Tüm servislerin verilerini güncellemesi biraz zaman alabilir.
• Compensating transaction’lar: Compensating transaction’ları yazmak, özellikle orijinal transaction’ın harici yan etkileri varsa (e-posta göndermek gibi) zorlayıcı olabilir.