Cevap.

Mikroservisler arasında etkileşimi projelendirirken sıklıkla dağıtık işlemlerin uygulanması meselesi ortaya çıkar. Monolitik yapılar için yeterli olan yerleşik mekanizmalar varken, mikroservislerde farklı veritabanları, teknolojiler ve veri alışveriş formatlarından dolayı durum karmaşıklaşır. Ana kural, uzun dağıtık işlemlerden kaçınmaktır; bu tür işlemler kötü ölçeklenir ve performans düşüşü riski taşır.

Klasik ACID protokolleri yerine SAGA deseninin kullanılması önerilir. Bu, her mikro hizmetin değişikliklerini kaydettiği ve geri alma gereksinimi olduğunda sorumluluk çerçevesinde tazminat işlemi gönderdiği bir yerel işlem zinciridir.

Node.js ile REST üzerinde sade bir SAGA yönetimi örneği:

// Express üzerindeki Saga orkestratörü
app.post('/saga', async (req, res) => {
  try {
    await serviceA.transaction();
    await serviceB.transaction();
    res.send('tamam');
  } catch (err) {
    await serviceA.rollback();
    res.status(500).send('geri alma gerçekleştirildi');
  }
});

Anahtar özellikler:

• SAGA, hizmetler arasındaki uzun beklemeleri en aza indirir.
• Genişletilebilirlik — yeni adımlar ve tazminat eylemleri eklenebilir.
• "Her hizmetin kendi depolaması var" mimarisi için uygundur.

Zorlayıcı sorular.

Mikroservisler arasında işlemleri desteklemek için klasik iki aşamalı taahhütler (2PC) kullanılabilir mi?

Kullanılabilir, ancak mikroservis mimarileri için tavsiye edilmez. 2PC, ölçeklenmeyi yavaşlatır ve hizmetleri teknolojik ve organizasyonel olarak birbirine bağlar.

SAGA'nın tüm senaryoları mali işlemler için uygun mu?

Hayır. SAGA'nın ACID'in katılığına kritik olan senaryolarda doğru uygulanması daha zordur, örneğin bir hesap üzerindeki bakiyelerin yeniden hesaplanması. Burada riskleri değerlendirmek ve bir uzlaşma seçmek önemlidir.

Eğer mikroservis geri dönemiyorsa, ara adımın başarısızlığı nasıl işlenir?

Bu tür durumlarda ayrı bir olay günlüğü kullanarak manuel veya otomatik bir tazminat protokolü uygulanmalıdır.