Saga Pattern

Saga Pattern çok önemli bir konudur ve mikroservisler arasında dağıtık işlemleri yönetmek için kullanılır. Bu desen, genellikle birden fazla mikroservisin bir arada çalıştığı, uzun süren ve farklı aşamalardan oluşan işlemlerle başa çıkmak için tercih edilir. Şimdi, daha ayrıntılı bir şekilde Choreography-based Saga ve Orchestration-based Saga desenlerini ele alalım. Ayrıca, Ocelot API Gateway’in bu desenlerde nasıl kullanılabileceğine dair detaylı açıklamalar yapacağız.

Saga Pattern (Deseni) Nedir?

Saga, mikroservis mimarisinde birden fazla servisi birbirine bağlayarak dağıtık bir işlem yapmanızı sağlar. Genellikle, uzun süren işlemler ve çoklu adımlardan oluşan süreçlerde kullanılır. Saga, her mikroservisin kendi yerel işlemini yönetmesini sağlar ve mikroservisler arası koordinasyonu düzenler.

Her mikroservis kendi işleminde başarılı ya da başarısız durumu işleyebilir. Eğer bir servis başarısız olursa, ilgili iptal işlemi (compensating transaction) yapılabilir.

Saga Pattern’ı genellikle iki şekilde uygularız:

• 1. Choreography-based Saga: Mikroservislerin kendi başlarına karar verdiği, asenkron iletişimle çalışan dağıtık bir sistem.
• 2. Orchestration-based Saga: Merkezi bir kontrol noktası (Saga State Machine) tarafından yönlendirilen ve her mikroservisin sırasıyla çalıştığı bir sistem.

1. Choreography-based Saga (Choreography Temelli Saga)

Choreography-based Saga, merkezi bir yöneticinin olmadığı, her mikroservisin birbirini doğrudan etkilemeden ve asenkron bir şekilde birbirleriyle iletişim kurarak işlediği bir desendir. Mikroservisler, bir olay meydana geldiğinde (örneğin bir sipariş oluşturulduğunda), bu olayı message broker üzerinden diğer mikroservislere bildirir. Her mikroservis, aldığı bu olaya göre kendi işlemini başlatır ve sonrasında yine bir olay yayınlar.

Nasıl Çalışır?

• Olay Yayınlama: Bir mikroservis, kendi işini tamamladıktan sonra bir olay (event) yayınlar. Örneğin, sipariş servisi bir sipariş oluşturduğunda OrderCreated adında bir olay yayınlar.
• Diğer Servislerin Olayı Dinlemesi: Diğer mikroservisler bu olayı dinler ve gerekli işlemi başlatır. Örneğin, stok yönetim servisi, sipariş olayını dinleyip, stok durumunu günceller.
• Sonuç Bildirimi: Her mikroservis, işlemin başarılı ya da başarısız olduğunu belirten bir geri bildirim (event) yayınlar. Eğer stok işlemi başarılıysa, StockReserved olayı yayınlanır. Eğer başarısız olursa, bir iptal olayı (CancelStockReserved) yayınlanır.
• Asenkron İletişim: Bu yapı tamamen asenkron çalışır, yani bir servis diğer servisi doğrudan çağırmaz. Bunun yerine, servisler birbirine mesaj gönderir ve olayları dinler.

Avantajları:

• Dağıtık Yapı: Mikroservisler birbirinden bağımsız çalışır. Yani, bir servis çökseler bile diğerleri işine devam edebilir.
• Esneklik: Her servis kendi işleminden sorumludur ve bağımsız çalışabilir.
• Asenkron:Hizmetler arasında asenkron iletişim, hizmetlerin birbirine bağlı olmadan çalışmasına imkan tanır.

Dezavantajları:

• Hata Yönetimi Zorluğu: Her mikroservis yalnızca kendi işlemini yönetir, bu da hata durumlarında geri alma işlemlerinin karmaşık olmasına ve zor izlenmesine yol açar.
• Bağımlılık Yönetimi: Mikroservisler birbirine bağımlı hale gelir, bir servisin aksaması tüm süreci etkileyebilir.
• İzlenebilirlik Sorunları: Her mikroservis yalnızca kendi durumunu günceller. Sürecin genel durumu ve hangi adımda kalındığı zor takip edilir.
• Performans Dar Boğazları: Yüksek trafikte, mikroservislerin sürekli mesaj dinlemesi performans sorunlarına ve yük dengeleme problemlerine yol açabilir.

Bu dezavantajlar, modelin yönetim zorlukları ve performans sınırlamaları yaratmasına neden olabilir.

Choreography-based Saga Örneği:

Bir e-ticaret platformu üzerinden sipariş oluşturma sürecini ele alalım:

• 1. Sipariş Servisi: Bir müşteri siparişi oluşturduğunda, sipariş oluşturuldu (OrderCreated) olayı gönderilir.
• 2. Stok Servisi: Stok servisi bu olayı dinler ve ilgili ürünlerin stok durumunu günceller. Stok başarılı bir şekilde ayrılırsa, stok ayrıldı (StockReserved) olayı gönderilir.
• 3. Ödeme Servisi: Ödeme servisi, stok ayrıldı olayı aldığında, ödeme işlemini başlatır. Ödeme başarılı olursa, ödeme başarılı (PaymentSuccessful) olayı gönderilir.

Bu yapıda, message broker (örneğin Kafka veya RabbitMQ) tüm servisler arasındaki mesajlaşmayı yönetir.

Burada her mikroservis, bir olayı aldığında kendi işlemini yapar ve bir sonraki servise mesaj gönderir.

2. Orchestration-based Saga (Orkestrasyon Temelli Saga)

Orchestration-based Saga, merkezi bir kontrol noktası (genellikle Saga State Machine) aracılığıyla tüm işlem adımlarının yönetildiği bir yaklaşımdır. Bu modelde, bir merkezi orchestrator (yönetici) tüm işlemleri koordine eder ve her mikroservisi sırasıyla çağırır.

Nasıl Çalışır?

• 1. Orchestrator Başlatır: Bir kullanıcı bir işlem başlatır (örneğin, bir sipariş verir). Saga State Machine bu işlemi başlatır ve ilk adımda ilgili mikroservisi (sipariş servisi) çağırır.
• 2. Mikroservislerin Yönlendirilmesi: Orchestrator, her bir mikroservisi sırayla çağırır. Örneğin, Stok Servisi’ni çağırır, stok işlemini gerçekleştirmesini bekler, sonra Ödeme Servisi’ni çağırır.
• 3. Durum Güncellemeleri: Her mikroservis işlemi tamamladığında, Saga State Machine yeni bir duruma geçer. Örneğin:
  • Initial: İşlem başladı.
  • OrderCreated: Sipariş oluşturuldu.
  • StockReserved: Stok ayrıldı.
  • PaymentProcessed: Ödeme başarıyla işlendi.
• 4. Başarı ya da Hata Durumu: Eğer bir işlem başarısız olursa, compensating transaction işlemi yapılır. Örneğin, ödeme başarısız olursa, stock rollback (stok geri alımı) işlemi yapılır.

Avantajları:

• Merkezi Yönetim: Tüm işlem adımları merkezi bir Saga State Machine tarafından kontrol edilir, bu da işlem akışını yönetmeyi kolaylaştırır.
• Hata Durumları: Hata durumları daha kolay yönetilir çünkü merkezi bir kontrol vardır.
• Durum Takibi: Her bir kullanıcı için, işlemin hangi aşamasında kaldığı takip edilebilir.

Dezavantajları:

• 1. Merkezi Bağımlılık: Tüm işlemler merkezi bir yönetici tarafından kontrol edilir. Bu, merkezi sistemin arızalanması durumunda tüm işlemlerin aksamasına yol açabilir.
• 2. Performans Sorunları: Merkezi yönetici aşırı yük altında kalabilir. Çok fazla işlem talebi geldiğinde, bu durum performans dar boğazlarına yol açabilir.
• 3. Karmaşıklık ve Yönetim Zorluğu:Merkezi bir yönetici olması, işlemlerin takibini zorlaştırabilir. Ayrıca, her bir mikroservisin doğru sırada çalışması karmaşık hale gelebilir.
• 4. Ölçeklenebilirlik:Merkezi bir yapı kullanmak, yatay ölçeklenebilirlik konusunda zorluklar yaratabilir. Merkezi bileşenler daha fazla yük taşıyacak şekilde ölçeklenemeyebilir.
• 5. Arıza Durumu: Eğer Saga State Machine arızalanırsa, tüm işlem sırası kesilebilir ve geri alımlar zorlaşır.
• 6. Hata Yönetimi: Hata durumlarında işlemlerin doğru bir şekilde telafi edilmesi karmaşık olabilir. Ayrıca, işlemlerin durumu sürekli izlenmelidir.

Bu dezavantajlara rağmen, merkezi bir yönetici kullanmak bazı durumlarda iş akışlarını daha düzenli hale getirebilir. Ancak, yüksek trafikli ve kritik sistemlerde dikkatli bir şekilde tasarlanması gerekir.

Orchestration-based Saga Örneği:

Bir siparişin işlendiğini düşünelim:

• 1. Saga State Machinebir sipariş oluşturma isteğini alır ve sipariş servisi’ni çağırır.
• 2. Saga State Machine sırayla stok servisi ve ödeme servisini çağırır.
• 3. Eğer stokta ürün yoksa, Saga State Machine iptal işlemi başlatır ve stok iptal olayını gönderir.

Burada, tüm süreç merkezi bir kontrol noktası olan Saga State Machine tarafından yönetiliyor.

Ocelot API Gateway ve Saga Pattern

Ocelot API Gateway, mikroservislerin birleşimi için bir giriş noktasıdır ve genellikle HTTP isteklerini yönlendirmek için kullanılır. Ocelot, mikroservislerin birbirine bağlanmasını sağlar ve dış dünyaya tek bir API giriş noktası sunar.

Ocelot’un Saga Pattern’deki Rolü:

• 1. Choreography-based Saga: Ocelot, mikroservisler arasında doğrudan bir iletişim sağlamaz. Ancak, dış dünyadan gelen talepleri doğru servislere yönlendirebilir. Ocelot, istemcilerden gelen talepleri alır ve doğru mikroservise ileterek, servislerin birbirine bağımsız bir şekilde çalışmasına yardımcı olabilir.
• 2. Orchestration-based Saga: Ocelot, merkezi bir state machine’i yönetmez. Ancak, Orkestrasyon modelinde, her mikroservisin çağırılması ve yönlendirilmesi konusunda Ocelot yine yardımcı olabilir. Ocelot, isteklerin doğru mikroservislere gitmesini sağlar ancak işlem akışını Saga State Machine yönlendirir.

Sonuç:

• Choreography-based Saga: Dağıtık ve bağımsız mikroservislerin bulunduğu sistemlerde, her servis kendi başına olaylar üzerinden çalışır ve mikroservisler arasında doğrudan bağımlılık yoktur.
• Orchestration-based Saga:Merkezi bir kontrol noktası kullanılarak, tüm süreç bir yönetici tarafından yönlendirilir ve her mikroservis sırasıyla çağrılır.

Ocelot API Gateway, her iki modelde de servisler arası iletişimi yönlendiren, dış dünyaya tek bir API sunan bir aracıdır. Ancak, Saga işlemlerinin yönetilmesi için asıl iş Saga State Machine veya Event-driven mimariler tarafından yapılır.

Umarım açıklamalar ve örnekler, Saga Pattern’ı daha iyi anlamanıza yardımcı olur!