Saga Deseni Diyagramı: Orkestrasyon ve Koreografi

Sipariş vermek üç servise dokunur: envanter stok ayırır, ödeme servisi kartta provizyon alır, kargo bir gönderi oluşturur. Monolitte bu tek bir veritabanı işlemidir. Kendi veritabanları olan servislere bölündüğünde üçünü birden kapsayan bir işlem yoktur ve servisler arasında iki aşamalı commit pratikte nadiren bir seçenektir.

Bunun standart cevabı saga desenidir. Bu yazı bir saganın nasıl çalıştığını, orkestrasyon ile koreografi arasındaki farkı, telafilerin ve pivot adımların nasıl bir araya geldiğini ve sagaların sizin yerinize çözmediği izolasyon sorunlarını anlatıyor. Diyagram, orkestrasyonla yönetilen bir sipariş sagasını gösteriyor.

Saga nedir

Saga, yerel işlemlerden oluşan bir dizidir. Her adım kendi servisinin veritabanında commit edilir ve bir sonrakini tetikler. Bir adım başarısız olursa saga, zaten commit edilmiş adımların etkilerini geri alan telafi işlemlerini çalıştırır.

Fikir mikroservislerden eskidir: Hector Garcia-Molina ve Kenneth Salem sagaları 1987'de uzun süreli veritabanı işlemleri üzerine yazdıkları bir makalede tanımladı. Desen geri döndü, çünkü servis sınırları aynı sorunu yeniden yarattı.

Geri kalan her şeyi iki sonuç belirler:

• Nihai tutarlılık. İlk ve son adım arasında sistem, diğer isteklerin görebildiği bir ara durumdadır. Sipariş PENDING durumundadır, stok ayrılmıştır, kartta provizyon alınmış ama tahsilat yapılmamıştır.
• Telafi, rollback değildir. Gönderilmiş bir e-postayı geri alamaz, karttan çekilen tutarı sessizce geri koyamazsınız. Telafi, önceki işlemi anlamsal olarak tersine çeviren yeni bir iş aksiyonudur; örneğin provizyonu iptal etmek ya da iade yapmak.

Telafi edilebilir, pivot ve tekrar denenebilir adımlar

Herhangi bir şey çizmeden önce her adımı sınıflandırın. Azure Architecture Center'ın saga deseni rehberi üç tür kullanır:

Sıra önemlidir. Önce telafi edilebilir adımları, ardından pivotu, ondan sonra da yalnızca tekrar denenebilir adımları koyun. Pivot başarısız olursa telafi edin; başarılı olduktan sonra ondan sonraki her şeyi başarılı olana kadar yeniden deneyin. Pivottan sonra telafi edilebilir bir adım bulunan bir saga, o adım başarısız olduğunda tutarlı bir duruma ulaşamaz.

Orkestrasyon ve koreografi

Adımları koordine etmenin iki yolu vardır.

Orkestrasyon: çoğu zaman kalıcı durumu olan bir durum makinesi olan saga orkestratörü, her servise ne yapacağını söyler ve yanıtı bekler. Sıra, yeniden denemeler, zaman aşımları ve telafiler ona aittir.

Koreografi: koordinatör yoktur. Her servis olayları dinler ve tepki verir: envanter OrderCreated olayını duyar ve stok ayırır, ödeme servisi StockReserved olayını duyar ve provizyon alır, bu böyle devam eder. Hatalar da birer olaydır ve her servis hangi telafiyi çalıştıracağını bilir.

Koreografi kısa akışlarda keyiflidir, biri "8812 numaralı sipariş neden takıldı?" diye sorduğunda ise işkenceye döner. Orkestrasyon bu soru için bakılacak tek bir yer sağlar. Temporal, AWS Step Functions veya Camunda gibi iş akışı motorları kalıcı orkestrasyon sunar; böylece durum makinesini kendiniz yazmak zorunda kalmazsınız. Chris Richardson'ın saga deseni sayfası iki stil için de ayrıntılı örnekler içeriyor.

İzolasyon: sagaların size bıraktığı kısım

Bir veritabanı işlemi, ara durumu diğer işlemlerden gizler. Saga gizlemez. Bir sipariş sagası çalışırken başka bir istek ayrılmış stoku okuyabilir ya da ikinci bir saga aynı kaydı değiştirebilir. Olağan karşı önlemler şunlardır:

• Anlamsal kilit. Kayıtları işlemde olarak işaretleyin (PENDING durumundaki bir sipariş, RESERVED durumundaki stok); böylece diğer işlemler beklemeleri ya da reddetmeleri gerektiğini bilir.
• Değişmeli güncellemeler. İşlemleri her sırada aynı sonucu verecek şekilde tasarlayın; örneğin sayıları doğrudan atamak yerine artırıp azaltın.
• Yazmadan önce yeniden okuma. Saga bir değeri okuduğundan beri o değerin değişmediğini kontrol edin; değiştiyse başarısız olun ya da yeniden başlayın.

Her adımı ve her telafiyi, saga kimliği ve adımla anahtarlanmış biçimde idempotent yapın. Mesajlar iki kez teslim edilecektir ve yeniden denenen bir "provizyonu iptal et" işlemi başka bir ödemeyi iptal etmemelidir.

Zaman aşımları ve takılan sagalar

Her adımın bir son tarihi olmalıdır. Hiç yanıt vermeyen bir ödeme servisi sagayı sonsuza kadar bekletir ve stoku ayrılmış halde bırakır. Her adıma bir zaman aşımı verin; zaman aşımını pivottan önce bir hata olarak (telafi edin), pivottan sonra ise yeniden deneme sebebi olarak ele alın ve beklenenden uzun süre aynı durumda kalan sagalar için alarm kurun. Sagaları mevcut adımlarına göre gösteren küçük bir pano, destek sorularının çoğunu tek başına yanıtlar. Her saganın neden sona erdiğini de kaydedin.

Mimari diyagram

Nasıl okunur:

• Sol: sipariş servisi siparişi PENDING durumunda oluşturur ve sagayı başlatır.
• Orta: orkestratör adımları sırayla çalıştırır ve her birini saga loguna kaydeder; böylece yeniden başlatılan bir orkestratör kaldığı yerden devam eder.
• Sağ: her biri adım numarası ve türüyle etiketlenmiş üç servis. Envanter ve ödeme telafi edilebilir; kargo pivottur.
• Alt: tüm adımlar başarılı olursa sipariş APPROVED olur. Pivottan önceki bir adım başarısız olursa orkestratör ters sırayla telafi eder (önce provizyonu iptal eder, sonra stoku serbest bırakır) ve sipariş REJECTED olur.
• Markdown tablosu her aksiyonu telafisiyle eşleştirir; bir gözden geçirenin ilk kontrol etmesi gereken şey budur.

Saga diyagramına ne konmalı

• Adım sırası ve her adımın türü. Telafi edilebilir, pivot ya da tekrar denenebilir bilgisi kutunun üzerinde yer almalı.
• Her telafi. Telafisi olmayan bir adım ya pivottur, ya tekrar denenebilirdir ya da bir hatadır.
• Saga durumunun nerede tutulduğu. Yarı yolda bir çökmeyi atlatamayan bir saga bitmiş sayılmaz.
• Görünür ara durumlar. PENDING ve RESERVED tasarımın parçasıdır; başka özellikler onları görecektir.

Sagalar doğal olarak transactional outbox deseniyle birlikte kullanılır, çünkü her adım hem veritabanını güncellemeli hem de bir mesaj göndermelidir ve ikisinden hiçbiri kaybolmamalıdır. Mikroservis mimari diyagramı bu servislerin nerede durduğunu gösterir; ödeme ağ geçidi entegrasyon diyagramı ise provizyon ve tahsilat adımlarını ayrıntılı olarak ele alır.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. C4 Modeli paketinden sipariş servisi, saga orkestratörü ve sagaya katılan üç servis için Konteyner düğümleri, saga logu için de bir Veritabanı ekleyin.
3. Her servisin teknoloji alanına adım numarasını ve türünü (telafi edilebilir ya da pivot) yazın.
4. Başarı ve telafi yolları için Akış Şeması paketinden bir Karar, bir Süreç ve iki Başla / Bitir düğümü ekleyin.
5. Aksiyonları ve telafilerini listeleyen bir tabloyla Temel paketinden bir Markdown bloğu ekleyin.

Örnek 11 diyagram düğümü kullanıyor ve Free planın sınırları içinde kalıyor.

SSS

Saga ile dağıtık işlem arasındaki fark nedir? Dağıtık bir işlem (iki aşamalı commit), herkes commit edene kadar veritabanları genelinde kaynakları kilitler. Saga ise her adımı yerel olarak commit eder ve sonraki bir adım başarısız olursa önceki adımları telafilerle geri alır; izolasyondan vazgeçip erişilebilirlik kazanır.

Orkestrasyon mu kullanmalıyım, koreografi mi? Çok adımlı, dallanan ya da katı sıralama gerektiren akışlarda orkestrasyon, çünkü her saganın durumu tek bir yerde durur. İki ya da üç servisin birbirinin olaylarına tepki verdiği kısa akışlarda koreografi.

Pivot işlem nedir? Saganın artık telafi edilemediği adımdır. Ondan önceki her şey telafi edilebilir, ondan sonraki her şey başarılı olana kadar tekrar denenebilir olmalıdır.

Bir telafideki hataları nasıl ele alırım? Yeniden deneyin. Telafiler idempotent olmalı ve eninde sonunda başarılı olmalıdır; olamıyorsa saganın elle çözüm yoluna ve bir alarma ihtiyacı vardır.

Sagalar bana izolasyon sağlar mı? Hayır. Diğer istekler ara durumları görebilir. İşiniz için önemli olan anormallikleri önlemek için PENDING gibi durumlarla anlamsal kilitler, değişmeli güncellemeler ve yeniden okumalar kullanın.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.