Transaktionale Vorgänge über mehrere Dienste hinweg. Eine Methode zum Wahnsinn.

Eine der vielen Komplexitäten, mit denen sich ein Team in einer Microservices-Umgebung auseinandersetzen muss, sind Transaktionen. Transaktionen, die mehrere Microservices umfassen. Im Gegensatz zu monolithischen Anwendungen, bei denen Transaktionen typischerweise mit einer einzigen Datenbank und dem @Transactional
verwaltet werden Anmerkung: In Microservices verfügt jeder Dienst oft über eine eigene Datenbank, was verteilte Transaktionen komplexer macht. Hier finden Sie eine Anleitung zur effektiven Handhabung dieser verteilten Transaktionen in Spring Boot.

Beginnen wir zunächst mit der Einigung darüber, was eine Transaktion ist.

Eine Transaktion ist eine Arbeitseinheit in einer Computer- oder Datenbankumgebung, die als eine einzige, unteilbare Operation behandelt wird. Es stellt eine Reihe von Aktionen oder Schritten dar, die alle gemeinsam erfolgreich sein oder scheitern müssen, um die Datenkonsistenz und -integrität auch bei unerwarteten Ereignissen (wie einem Stromausfall oder einem Netzwerkausfall) sicherzustellen.

In einem Datenbankkontext kann eine Transaktion mehrere Abfragen umfassen, z. B. das Erstellen, Aktualisieren oder Löschen von Datensätzen. Eine Transaktion folgt im Allgemeinen vier wesentlichen Eigenschaften, die als ACID-Eigenschaften bezeichnet werden:

a. Atomizität- Alle Vorgänge innerhalb einer Transaktion werden als eine einzige Einheit behandelt. Entweder sind alle Vorgänge erfolgreich oder keiner.

b. Konsistenz – Eine Transaktion bringt das System von einem gültigen Zustand in einen anderen und behält dabei die Datengültigkeit bei.

c. Isolation – Transaktionen werden isoliert ausgeführt, was bedeutet, dass Zwischenzustände für andere Transaktionen nicht sichtbar sind.

d. Dauerhaftigkeit – Sobald eine Transaktion festgeschrieben wurde, sind ihre Änderungen dauerhaft und überstehen Systemabstürze.

---

Eine Kurzgeschichte

Stellen Sie sich in einer geschäftigen E-Commerce-App eine Kundin, Alice, vor, die eine Bestellung für einen neuen Laptop, ein Zubehör und den Expressversand aufgibt. Hier ist die Geschichte hinter den Kulissen, wie ihre Bestellung durch das System fließt, verwaltet vom OrderSagaOrchestrator.

Stellen Sie sich in einer geschäftigen E-Commerce-App eine Kundin, Alice, vor, die eine Bestellung für einen neuen Laptop, ein Zubehör und den Expressversand aufgibt. Hier ist die Geschichte hinter den Kulissen, wie ihre Bestellung durch das System fließt, verwaltet vom OrderSagaOrchestrator.

Alice klickt auf „Jetzt bestellen“, nachdem sie ihre Zahlungs- und Versandinformationen eingegeben hat. Diese Aktion löst einen Prozess namens Saga aus, eine sorgfältig orchestrierte Reihe von Transaktionen, um sicherzustellen, dass ihre Bestellung von Anfang bis Ende korrekt bearbeitet wird.

Schritt 1: Zahlungsabwicklung
Der Saga-Orchestrator erkundigt sich zunächst beim PaymentService und initiiert einen Anruf, um den erforderlichen Betrag von Alices Konto abzubuchen. Die Methode paymentService.processPayment() wird aufgerufen und Alices Zahlung wird autorisiert.

Schritt 2: Bestandsreservierung
Sobald die Zahlung erfolgreich ist, wechselt der Orchestrator zum InventoryService, wo er das spezifische Laptopmodell und Zubehör für Alice reserviert. Dieser Reservierungsschritt ist von entscheidender Bedeutung, damit der Lagerbestand nicht ausverkauft ist oder an eine andere Kundin weitergegeben wird, während ihre Bestellung noch bearbeitet wird.

Schritt 3: Versandinitiierung
Nachdem der Lagerbestand erfolgreich reserviert wurde, wendet sich der Saga-Orchestrator an den ShippingService. Hier startet shippingService.initiateShipping() die Logistik und stellt sicher, dass die Artikel verpackt und für den Versand an Alices Adresse bereit sind.

Umgang mit Fehlern: Kompensationslogik

Aber in einer verteilten Umgebung kann bei jedem Schritt etwas schief gehen. Was passiert, wenn die Einleitung des Versands aufgrund eines logistischen Fehlers fehlschlägt oder wenn der Lagerbestand aufgrund einer Bestandsdiskrepanz nicht tatsächlich erfüllt werden kann? Der Orchestrator wird mit einer Vergütungsstrategie vorbereitet.

Wenn eine Ausnahme ausgelöst wird, initiiert der Orchestrator kompensierende Transaktionen, um den gesamten Prozess rückgängig zu machen, sodass Alice keine Gebühren für Artikel berechnet werden, die sie nicht erhält:

3.1. Versand abbrechen – Der Orchestrator ruft shippingService.cancelShipping() auf und stoppt den Versand.

3.2. Inventar freigeben – Anschließend wird inventoryService.releaseInventory() ausgelöst, wodurch die reservierten Artikel von Alice freigegeben werden, damit andere Kunden sie kaufen können.

3.3. Zahlung zurückerstatten – Schließlich wird paymentService.refund() aufgerufen, um Alices Zahlung zurückzuerstatten und sicherzustellen, dass ihr die Bestellung nicht in Rechnung gestellt wird.

Letztendlich stellt diese orchestrierte Saga sicher, dass Alices Erfahrung reibungslos und konsistent ist und dass, wenn Probleme auftreten, diese auf eine Weise gelöst werden, die die Integrität des Systems aufrechterhält. Das ist die Magie verteilter Transaktionen und Kompensationslogik in Microservices.

---

Da wir nun wissen, was eine Transaktion ist und ein reales Szenario verstehen, in dem dies nützlich sein könnte, wollen wir uns damit befassen, wie dies in einer verteilten Umgebung funktioniert.

Es gibt Schlüsselansätze, die Teams nutzen, um dieses Problem zu lösen

1. SAGA-Muster: Eines der am häufigsten verwendeten Muster zur Abwicklung verteilter Transaktionen in einer Microservices-Architektur ist das Saga-Muster. Eine Saga ist eine Folge lokaler Transaktionen, die jeder Dienst unabhängig ausführt. Jeder Schritt in einer Saga wird durch eine Aktion kompensiert, die ihn rückgängig macht, wenn die Saga fehlschlägt.

Das Saga-Muster kann im Wesentlichen auf zwei Arten implementiert werden:

1. a. Choreographiebasiertes SAGA: Jeder an der Transaktion beteiligte Dienst wartet auf Ereignisse und führt seine Transaktion durch. Nach Abschluss gibt es ein Ereignis aus, das den nächsten Schritt in der Saga auslöst. Wenn ein Schritt fehlschlägt, wird ein kompensierendes Ereignis ausgelöst, um vorherige Schritte rückgängig zu machen.

2. b. Orchestrierungsbasierte SAGA: Ein zentraler Dienst (der Saga-Orchestrator) koordiniert die Schritte der Saga. Es bestimmt die Reihenfolge der Vorgänge und verwaltet die Entschädigungen, wenn ein Fehler auftritt.

2. Zwei-Phasen-Commit (2PC): Obwohl das Zwei-Phasen-Commit-Protokoll häufig in monolithischen Systemen verwendet wird, kann es über verteilte Systeme hinweg mit einem verteilten Transaktionsmanager wie Atomikos oder Bitronix verwendet werden. Ich würde diesen Ansatz jedoch nicht empfehlen, da er im Microservices-Kontext einige Einschränkungen aufweist, da er zu einer hohen Latenz führt und weniger fehlertolerant ist. An Ihrer Stelle würde ich diesen Ansatz generell zugunsten des Saga-Musters vermeiden.

3. Ereignisgesteuerte Architektur: Die Verwendung eines ereignisgesteuerten Ansatzes, bei dem Dienste über Ereignisse kommunizieren, eignet sich besonders für die Abwicklung verteilter Transaktionen. Dieser Ansatz passt gut zum Saga-Muster. Jeder Dienst führt seine Transaktion unabhängig aus und gibt dann ein Ereignis aus, um andere Dienste über das Ergebnis zu informieren. Diese Ereignisse können mit Apache Kafka, RabbitMQ oder anderen Nachrichtenbrokern verarbeitet werden.

Jetzt wollen wir sehen, wie das im Code funktioniert.

Es gibt verschiedene Varianten des Saga-Musters, aber in diesem Artikel werde ich versuchen, ein orchestrierungsbasiertes Saga-Muster in Spring Boot zu implementieren:

SCHRITT 1: Definieren eines Saga-Orchestrators:
Hier erstelle ich einen einfachen Dienst, der als Orchestrator fungiert und für die Koordinierung der Transaktionen verantwortlich ist.

Dieser Dienst definiert den Ablauf der Saga, ruft jeden Dienst in der richtigen Reihenfolge auf und wickelt bei Bedarf Ausgleichstransaktionen ab.

@Service
public class OrderSagaOrchestrator {

    @Autowired
    private PaymentService paymentService;

    @Autowired
    private InventoryService inventoryService;

    @Autowired
    private ShippingService shippingService;

    public void createOrderSaga(Order order) {
        try {
            paymentService.processPayment(order.getPaymentDetails());
            inventoryService.reserveInventory(order.getItems());
            shippingService.initiateShipping(order.getShippingDetails());
        } catch (Exception e) {
            // Compensation logic
            shippingService.cancelShipping(order.getShippingId());
            inventoryService.releaseInventory(order.getItems());
            paymentService.refund(order.getPaymentId());
        }
    }
}

SCHRITT 2: Erstellen lokaler Transaktionen und Vergütungsmethoden in jedem Service:

Jeder Dienst sollte eine eigene Transaktion haben, um seinen Schritt in der Saga abzuschließen, und eine weitere, um ihn bei Bedarf zu kompensieren. Hier ist die allgemeine Struktur, wie das aussehen könnte.

@Service
public class PaymentService {

    @Transactional
    public void processPayment(PaymentDetails details) {
        // Perform payment logic
    }

    @Transactional
    public void refund(String paymentId) {
        // Perform refund logic
    }
}

SCHRITT 3: Ereignisbasierte Kommunikation (Optional, für Choreografie): Jeder Dienst kann Ereignisse ausgeben, um andere über das Ergebnis der Transaktion zu informieren.

public class PaymentService {

    private final ApplicationEventPublisher eventPublisher;

    public PaymentService(ApplicationEventPublisher eventPublisher) {
        this.eventPublisher = eventPublisher;
    }

    public void processPayment(PaymentDetails details) {
        // Process payment
        eventPublisher.publishEvent(new PaymentProcessedEvent(this, details));
    }
}

SCHRITT 4: Ergreifen Sie Maßnahmen, um die Datenkonsistenz zu gewährleisten: Verwenden Sie Idempotenzprüfungen, um sicherzustellen, dass jeder Schritt in der Saga nur einmal ausgeführt wird. Dies ist in verteilten Systemen wichtig, wo Netzwerkausfälle oder Wiederholungsversuche zu doppelten Anfragen führen können.

SCHRITT 5: Verwenden Sie einen Nachrichtenbroker für Zuverlässigkeit: Wenn Sie Ereignisse zum Verwalten der Saga verwenden, bietet sich ein Nachrichtenbroker wie Kafka von RabbitMq an Haltbarkeit und kann Ereignisse puffern, wenn ein Dienst vorübergehend nicht verfügbar ist.

SCHRITT 6: Fehlerbehandlung und Wiederholungsversuche: Integrieren Sie Fehlerbehandlungs- und Wiederholungslogik in Ihren Orchestrator und einzelne Dienste, um vorübergehende Fehler zu behandeln. Spring Retry ist hier nützlich, da es fehlgeschlagene Vorgänge innerhalb einer konfigurierbaren Richtlinie automatisch wiederholen kann.

@Service
public class OrderSagaOrchestrator {

    @Autowired
    private PaymentService paymentService;

    @Autowired
    private InventoryService inventoryService;

    @Autowired
    private ShippingService shippingService;

    public void createOrderSaga(Order order) {
        try {
            paymentService.processPayment(order.getPaymentDetails());
            inventoryService.reserveInventory(order.getItems());
            shippingService.initiateShipping(order.getShippingDetails());
        } catch (Exception e) {
            // Compensation logic
            shippingService.cancelShipping(order.getShippingId());
            inventoryService.releaseInventory(order.getItems());
            paymentService.refund(order.getPaymentId());
        }
    }
}

Fazit

Verteilte Transaktionen in Microservices stellen eine Herausforderung dar, aber durch die Verwendung von Mustern wie Saga (insbesondere mit Orchestrierung) und ereignisgesteuerter Kommunikation können Sie zuverlässige und skalierbare Lösungen erzielen.

Spring Boot erleichtert dies, indem es Unterstützung für Transaktionsmanagement, Ereignisveröffentlichung und Integration mit Nachrichtenbrokern bietet.

Letztendlich stellt diese orchestrierte Saga sicher, dass Alices Erfahrung reibungslos und konsistent ist und dass, wenn Probleme auftreten, diese auf eine Weise gelöst werden, die die Integrität des Systems aufrechterhält. Das ist die Magie verteilter Transaktionen und Kompensationslogik in Microservices.

Das obige ist der detaillierte Inhalt vonTransaktionale Vorgänge über mehrere Dienste hinweg. Eine Methode zum Wahnsinn.. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!