Microservice’ler arasında distributed transaction nasıl yönetebiliriz?

2, Mar 2025

Microservice’ler arasında distributed transaction nasıl yönetebiliriz?

Two-Phase Commit (2PC)

Two-Phase Commit (2PC), dağıtık sistemlerde veri tutarlılığı (Data Consistency) sağlamak için kullanılan bir transaction coordination (işlem koordinasyonu) protokolüdür.

Bu protokol, birden fazla mikroservisin veya veritabanının aynı işlemi atomik (Atomic) bir şekilde tamamlamasını sağlar.

Problem Ne?

Dağıtık sistemlerde veri tutarlılığı (Data Consistency) sağlamak oldukça zordur.

Örneğin:

OrderService → Siparişi oluşturur
PaymentService → Ödeme alır
StockService → Stoktan ürün düşer

Bu üç işlem aynı anda başarılı olmalı ya da hiçbiri yapılmamalı. Aksi halde Veri Tutarsızlığı (Data Inconsistency) oluşur.

Çözüm: Two-Phase Commit

2PC, dağıtık işlemleri ya hep ya hiç prensibine göre çalıştırır.

🎯 Nasıl Çalışır?

Two-Phase Commit protokolü iki aşamada çalışır:

1. Prepare (Hazırlık) Aşaması

Koordinatör (Coordinator) servisi, tüm katılımcılara (Participants) “İşlemi yapmaya hazır mısın?” diye sorar.
Katılımcılar ya:
- YES (Hazırım) → Hazır olduğunu bildirir.
- NO (Hazır değilim) → İşlemi yapamayacağını bildirir.

2. Commit (Onaylama) Aşaması

Eğer tüm katılımcılar YES dediyse, koordinatör Commit komutu gönderir ve işlemler tamamlanır.
Eğer herhangi biri NO derse, koordinatör Rollback komutu gönderir ve tüm işlemler geri alınır.

🔑 Koordinatör Kimdir?

Koordinatör, işlemin yöneticisidir. Dağıtık sistemlerde genellikle:

Message Broker (Kafka, RabbitMQ)
Database Transaction Manager
Custom API Service

📌 Akış Şeması

luaCopyEdit          +-------------------+
          |  Koordinatör      |
          +-------------------+
                 |
                 |
         +-------+-------+
         |               |
    OrderService     PaymentService
         |               |
         |               |
         +-------+-------+
                 |
           StockService

⚙️ Örnek Senaryo

OrderService → Sipariş oluşturuldu (Hazır)
PaymentService → Ödeme alındı (Hazır)
StockService → Stok güncellendi (Hazır)

Hepsi hazırsa: ✅ Commit
Eğer biri başarısızsa:
❌ Rollback

C# .NET Core ile 2PC Örneği

1. OrderService

csharpCopyEditpublic async Task<bool> PrepareOrder(Guid orderId)
{
    Console.WriteLine($"Order {orderId} Hazır");
    return true;
}

2. PaymentService

csharpCopyEditpublic async Task<bool> PreparePayment(Guid orderId)
{
    Console.WriteLine($"Payment {orderId} Alındı");
    return true;
}

3. StockService

csharpCopyEditpublic async Task<bool> PrepareStock(Guid orderId)
{
    Console.WriteLine($"Stock {orderId} Güncellendi");
    return true;
}

4. Koordinatör

csharpCopyEditpublic async Task<bool> TwoPhaseCommit(Guid orderId)
{
    var orderPrepared = await OrderService.PrepareOrder(orderId);
    var paymentPrepared = await PaymentService.PreparePayment(orderId);
    var stockPrepared = await StockService.PrepareStock(orderId);

    if (orderPrepared && paymentPrepared && stockPrepared)
    {
        Console.WriteLine("✅ Commit Edildi");
        return true;
    }
    else
    {
        Console.WriteLine("❌ Rollback Yapıldı");
        return false;
    }
}

💪 Avantajları

Özellik	Açıklama
Veri Tutarlılığı	Tüm servisler aynı anda tamamlanır
ACID Uygunluğu	Dağıtık sistemlerde ACID prensibi sağlanır
Otomatik Rollback	Başarısız olan işlemler geri alınır

❌ Dezavantajları

Problem	Açıklama
Performans	Ağ gecikmeleri nedeniyle yavaş çalışır
Tıkanıklık	Bir servis kilitlenirse tüm işlem durur
Single Point of Failure	Koordinatör çökerse tüm sistem çökebilir

🔥 Alternatif Çözüm: Saga Pattern

Saga Pattern, Two-Phase Commit’e göre daha Asenkron çalışır.

Özellik	2PC	Saga
Asenkron	❌	✅
Performans	Yavaş	Hızlı
Hata Toleransı	Düşük	Yüksek
Veri Tutarlılığı	Yüksek	Orta

Hangi Durumda Hangisi Kullanılır?

Durum	Önerilen Yöntem
Yüksek Veri Tutarlılığı	Two-Phase Commit
Performans Odaklı	Saga Pattern
Cloud Native	Saga Pattern
Legacy Sistemler	Two-Phase Commit

🔍 Azure Service Bus ile 2PC

Azure Transaction Manager kullanarak Distributed Transactions otomatik olarak yönetilebilir.

🌐 Mimaride Kullanabileceğin Teknolojiler

Teknoloji	Kullanım
RabbitMQ	Event Coordination
Kafka	Event Streaming
Azure Service Bus	Cloud Native Event Coordination
Outbox Pattern	Veri Tutarlılığı

Sonuç

✅ Veri Tutarlılığı
✅ ACID Uygunluğu
❌ Yavaşlık
❌ Yüksek Karmaşıklık

🎯 Benim Tavsiyem

filesharingsecure projesi için Event-Driven + Saga Pattern + Azure Service Bus kullanman daha performanslı olur.

🚀 Sana Özel Mimari Önerisi

Katman	Teknoloji	Pattern
Kullanıcı Yönetimi	Azure Service Bus	Saga
Dosya Paylaşımı	Azure Blob	Event-Driven
Bildirimler	Azure Queue	Outbox

Eventual Consistency (Zamanla Tutarlılık), dağıtık sistemlerde veri tutarlılığı sağlamak için kullanılan bir veri senkronizasyon stratejisidir.

Bu yaklaşımda anlık (strong consistency) yerine, belirli bir zaman aralığında tüm sistemlerin tutarlı hale gelmesi garanti edilir.

🧠 Neden Eventual Consistency?

Mikroservis mimarilerinde yüksek performans ve ölçeklenebilirlik sağlamak için Asenkron iletişim kullanılır.

Örneğin:

Bir sipariş sistemi,
Ödeme sistemi,
Stok sistemi

Bu sistemler aynı anda çalışmaz. Bunun yerine mesaj kuyruğu (Message Broker) kullanılarak birbirinden bağımsız şekilde veri işler.

💡 Nasıl Çalışır?

Eventual Consistency’de veri şu şekilde senkronize edilir:

İşlem Başlatılır: Bir servis veri günceller.
Event Gönderilir: Güncelleme olayı (Event) mesaj kuyruğuna gönderilir.
Asenkron İşleme: Diğer servisler bu olayı okur ve kendi veri tabanlarını günceller.
Senkronizasyon: Tüm servisler bir süre sonra aynı veriyle tutarlı hale gelir.

🎯 Örnek Senaryo

Bir Dosya Paylaşım Sistemi düşünelim:

Adımlar:

Kullanıcı dosya yükler.
FileService → Dosyayı Azure Blob’a yükler.
Event Gönderir → FileUploadedEvent
NotificationService → Kullanıcıya e-posta bildirimi gönderir.
AuditService → Log kaydı oluşturur.

Akış Şeması:

rustCopyEdit   Kullanıcı
      |
 FileService ---> FileUploadedEvent ---> NotificationService
      |
      +---------------------> AuditService

Eventual Consistency’nin Avantajları

Özellik	Açıklama
Performans	Servisler Asenkron çalışır
Ölçeklenebilirlik	Servisler bağımsız çalışır
Yüksek Uygunluk	Bir servis çökerse diğerleri çalışmaya devam eder

Dezavantajları ❌

Problem	Açıklama
Veri Tutarsızlığı	Kısa süreliğine veri uyumsuz olabilir
Karmaşıklık	Event-driven mimariler daha karmaşıktır
Hata Yönetimi	Retry ve Dead Letter Queue mekanizmaları gerekir

Strong Consistency vs Eventual Consistency

Özellik	Strong Consistency	Eventual Consistency
Tutarlılık	Anlık	Zamanla
Performans	Yavaş	Hızlı
Karmaşıklık	Basit	Karmaşık
Kullanım Alanı	Finansal İşlemler	Mikroservisler

🔑 Kullanılan Teknolojiler

Teknoloji	Açıklama
Azure Service Bus	Event Distribution
RabbitMQ	Message Broker
Kafka	Event Streaming
Outbox Pattern	Veri tutarlılığı için

🔥 Örnek Uygulama (.NET Core + Azure)

Event Tanımı

csharpCopyEditpublic class FileUploadedEvent
{
    public Guid FileId { get; set; }
    public string UserEmail { get; set; }
}

FileService (Publisher)

csharpCopyEditpublic async Task UploadFile(File file)
{
    await _blobService.UploadAsync(file);
    
    var @event = new FileUploadedEvent
    {
        FileId = file.Id,
        UserEmail = file.UserEmail
    };

    await _messageBus.PublishAsync(@event);
}

NotificationService (Subscriber)

csharpCopyEditpublic async Task Handle(FileUploadedEvent @event)
{
    Console.WriteLine($"Mail gönderildi: {@event.UserEmail}");
}

🔥 Outbox Pattern ile Eventual Consistency

Outbox Pattern, Eventual Consistency’yi daha güvenilir hale getirir.

👉 Temel mantık şu:

İşlem yapıldığında veritabanına önce Event kaydedilir.
Daha sonra ayrı bir işlem (Background Job) bu Event’i kuyruğa yollar.

🌐 Azure Mimarisinde Eventual Consistency

Azure Blob Storage → Dosya Yükleme
Azure Service Bus → Event Mesajları
Azure Function → Event İşleyici
Azure CosmosDB → Log Depolama
Azure Application Insights → Telemetri ve İzleme

Sonuç

Strateji	Açıklama
Saga Pattern	İşlem bazında tutarlılık sağlar
2PC	ACID uyumlu, senkron çalışır
Eventual Consistency	Yüksek Performans, Asenkron

Tavsiye Mimari

Katman	Pattern	Teknoloji
Transaction	Saga Pattern	Azure Service Bus
Veri Tutarlılığı	Eventual Consistency	Outbox + Kafka
İşlem Koordinasyonu	Event-Driven	Azure Functions

🎯 filesharingsecure Projesi İçin Mimari Önerisi:

İşlem	Yöntem	Teknoloji
Dosya Yükleme	Eventual Consistency	Azure Blob
Kullanıcı Bildirimi	Event-Driven	Azure Service Bus
Loglama	Outbox Pattern	Azure CosmosDB
Retry	Dead Letter Queue	Azure Queue

📌 Senin Projen için YOL HARİTASI

Aşama	Teknoloji	Açıklama
1. Adım	Azure Blob	Dosya Yükleme
2. Adım	Azure Service Bus	Event Gönderme
3. Adım	Azure CosmosDB	Loglama
4. Adım	Azure Functions	Retry & DLQ

1. Two-Phase Commit (2PC)

✅ Tavsiye Durumları:

ACID uyumluluğunun kesinlikle zorunlu olduğu yerlerde
Bankacılık, finansal işlemler gibi kritik veri tutarlılığı gereken sistemlerde
Senkron çalışan servisler arasında

❌ Tavsiye Edilmez:

Yüksek trafik ve performans gerektiren sistemlerde
Çok sayıda servis arasında (Yavaşlar ve Deadlock riski oluşur)
Cloud-Native sistemlerde

🔥 2. Saga Pattern (Asenkron İşlem Koordinasyonu)

✅ Tavsiye Durumları:

Mikroservis mimarileri
Event-Driven sistemler
Azure, AWS gibi Cloud-Native uygulamalar
Yüksek ölçeklenebilirlik ihtiyacı olan sistemler
Kullanıcı işlemlerinde birden fazla servis zinciri varsa (Dosya Yükleme, Bildirim, Loglama vs.)

Nasıl Çalışır?

Saga Pattern, işlemleri küçük adımlara böler ve her adım tamamlandığında bir Event yayınlar.

👉 Örneğin:

Servis	İşlem	Event
FileService	Dosya Yükleme	FileUploadedEvent
NotificationService	Mail Gönderimi	MailSentEvent
AuditService	Log Kaydı	LogRecordedEvent

Avantajlar:

Özellik	Açıklama
Performans	Asenkron, çok hızlı
Fault Tolerance	Bir servis çökerse diğerleri çalışmaya devam eder
Transaction Isolation	Servisler birbirinden bağımsız çalışır
Scalability	Cloud Native sistemler için mükemmel

Dezavantajlar:

Problem	Çözüm
Veri Tutarsızlığı	Compensation Transactions ile Geri Alma
Karmaşıklık	Outbox Pattern + Retry ile kontrol

🔥 3. Eventual Consistency + Outbox Pattern

Bu yaklaşım hem performans hem de veri tutarlılığı açısından en optimum çözüm.

Nasıl Çalışır?

İşlem yapılırken önce veritabanına yazılır.
Event Outbox tablosuna kaydedilir.
Background Job veya Azure Function gibi bir servis Outbox tablosundaki mesajları Message Queue‘ya yollar.

Önerdiğim Mimari

Katman	Pattern	Teknoloji
Transaction	Saga + Eventual Consistency	Azure Service Bus
Veri Tutarlılığı	Outbox Pattern	MSSQL + Azure
Retry	Dead Letter Queue	Azure Queue
Bildirim	Event-Driven	Azure Functions

⚙️ Teknoloji Stack:

Katman	Teknoloji	Açıklama
Event Broker	Azure Service Bus	Event Driven Asenkron
Outbox	MSSQL + EF Core	Transaction + Event Tutarlılığı
Storage	Azure Blob	Dosya Yükleme
Loglama	CosmosDB	Event-Driven Loglama
Telemetry	Azure Application Insights	İzleme ve Hata Yönetimi

🔥 Peki filesharingsecure için Önerdiğim Mimari:

İşlem	Yöntem	Teknoloji	Pattern
Dosya Yükleme	Asenkron + Outbox	Azure Blob	Eventual Consistency
Bildirim	Event-Driven	Azure Service Bus	Saga Pattern
Loglama	Outbox Pattern	CosmosDB	Eventual Consistency
Retry	Dead Letter Queue	Azure Queue	Event-Driven

Neden Bu Mimaride Israrcıyım?

✅ Azure Native
✅ Performans
✅ Asenkron
✅ Otomatik Retry
✅ Eventual Consistency
✅ Dağıtık Transaction

🏆 Tavsiye Sıralaması

Yöntem	Performans	Tutarlılık	Karmaşıklık	Önerilen Alan
Two-Phase Commit	❌ Düşük	🔥 %100	🔥 Basit	Finans, Bankacılık
Saga Pattern	🔥 Yüksek	%90	⚠️ Orta	Mikroservisler
Eventual Consistency + Outbox	🔥 Çok Yüksek	%95	⚠️ Orta	Cloud Native, Dosya Paylaşımı

Sana Özel Önerim 💪

Senin filesharingsecure projenin iş modelini düşündüğümde sana şu yapıyı öneriyorum:

Katman	Yöntem	Teknoloji
Transaction	Eventual Consistency + Outbox	MSSQL + EF Core
Bildirim	Event-Driven Saga	Azure Service Bus
Loglama	Outbox Pattern	CosmosDB
Dosya Depolama	Azure Blob	Eventual Consistency
Hata Yönetimi	Retry + DLQ	Azure Queue

🚀 YOL HARİTASI:

Azure Blob Storage Dosya Yükleme
MSSQL + Outbox Veri Tutarlılığı
Azure Service Bus Event Gönderimi
Azure CosmosDB Loglama
Azure Functions Retry ve DLQ

0
By admin
19:48 HOURS

Microservice’ler arasında distributed transaction nasıl yönetebiliriz?

2, Mar 2025

Microservice’ler arasında distributed transaction nasıl yönetebiliriz?

Problem Ne?

Çözüm: Two-Phase Commit

🎯 Nasıl Çalışır?

1. Prepare (Hazırlık) Aşaması

2. Commit (Onaylama) Aşaması

🔑 Koordinatör Kimdir?

📌 Akış Şeması

⚙️ Örnek Senaryo

C# .NET Core ile 2PC Örneği

1. OrderService

2. PaymentService

3. StockService

4. Koordinatör

💪 Avantajları

❌ Dezavantajları

🔥 Alternatif Çözüm: Saga Pattern

Hangi Durumda Hangisi Kullanılır?

🔍 Azure Service Bus ile 2PC

🌐 Mimaride Kullanabileceğin Teknolojiler

Sonuç

🎯 Benim Tavsiyem

🚀 Sana Özel Mimari Önerisi

🧠 Neden Eventual Consistency?

💡 Nasıl Çalışır?

🎯 Örnek Senaryo

Adımlar:

Akış Şeması:

Eventual Consistency’nin Avantajları

Dezavantajları ❌

Strong Consistency vs Eventual Consistency

🔑 Kullanılan Teknolojiler

🔥 Örnek Uygulama (.NET Core + Azure)

Event Tanımı

FileService (Publisher)

NotificationService (Subscriber)

🔥 Outbox Pattern ile Eventual Consistency

🌐 Azure Mimarisinde Eventual Consistency

Sonuç

Tavsiye Mimari

🎯 filesharingsecure Projesi İçin Mimari Önerisi:

📌 Senin Projen için YOL HARİTASI

1. Two-Phase Commit (2PC)

🔥 2. Saga Pattern (Asenkron İşlem Koordinasyonu)

Nasıl Çalışır?

Avantajlar:

Dezavantajlar:

🔥 3. Eventual Consistency + Outbox Pattern

Önerdiğim Mimari

⚙️ Teknoloji Stack:

🔥 Peki filesharingsecure için Önerdiğim Mimari:

Neden Bu Mimaride Israrcıyım?

🏆 Tavsiye Sıralaması

Sana Özel Önerim 💪

🚀 YOL HARİTASI:

Bir yanıt yazın Yanıtı iptal et