Stellen Sie sich vor, Sie bauen eine E-Commerce-Plattform mit Microservices für Inventar, Zahlung und Versand. Ein Kunde gibt eine Bestellung auf, und plötzlich stehen Sie vor der altbekannten Frage: Wie stellen Sie sicher, dass all diese Dienste gut zusammenarbeiten, ohne dass Sie graue Haare bekommen?

Traditionelle ACID-Transaktionen sind großartig für Monolithen, aber sie versagen in der Welt der Microservices. Sie sind wie ein Vorschlaghammer, um eine Nuss zu knacken - übertrieben und wahrscheinlich mehr Probleme verursachend, als sie lösen. Hier kommt LRA ins Spiel, um den Tag zu retten.

Warum ACID nicht ausreicht:

  • Enge Kopplung zwischen Diensten (ein großes No-Go in Microservices)
  • Leistungsengpässe durch Sperren
  • Skalierungsprobleme, wenn Ihr System wächst

LRA verfolgt einen anderen Ansatz. Anstatt atomare Transaktionen über Dienste zu erzwingen, setzt es auf das Modell der eventual consistency. Es ist wie das Koordinieren einer Tanzroutine, bei der jeder Tänzer (Dienst) seinen Teil kennt und weiß, wie er sich erholen kann, wenn jemand auf seine Zehen tritt.

MicroProfile LRA

Was genau ist MicroProfile LRA? Stellen Sie es sich als Choreografen für Ihr Microservices-Ballett vor. Es bietet eine standardisierte Möglichkeit, langlaufende, verteilte Operationen zu verwalten, die mehrere Dienste umfassen.

Schlüsselkonzepte:

  • Langlaufende Aktionen: Operationen, die Sekunden, Minuten oder sogar Stunden dauern können
  • Kompensation: Die Fähigkeit, Aktionen rückgängig zu machen, wenn etwas schiefgeht
  • Eventual Consistency: Die Akzeptanz, dass Konsistenz über Dienste hinweg Zeit braucht

LRA versucht nicht, sofortige Konsistenz zu erzwingen. Stattdessen bietet es Ihnen Werkzeuge, um den Lebenszyklus dieser langlaufenden Operationen zu verwalten und sicherzustellen, dass Ihr System schließlich einen konsistenten Zustand erreicht.

Einrichtung von LRA: Eine Schritt-für-Schritt-Anleitung

Bereit, etwas LRA-Magie zu Ihrem Projekt hinzuzufügen? Lassen Sie uns durch die Einrichtung gehen:

1. Fügen Sie die MicroProfile LRA-Abhängigkeit hinzu

Zuerst müssen Sie die MicroProfile LRA-Abhängigkeit zu Ihrem Projekt hinzufügen. Wenn Sie Maven verwenden, fügen Sie dies zu Ihrer pom.xml hinzu:


<dependency>
    <groupId>org.eclipse.microprofile.lra</groupId>
    <artifactId>microprofile-lra-api</artifactId>
    <version>1.0</version>
</dependency>

2. Konfigurieren Sie Ihren LRA-Koordinator

Sie benötigen einen LRA-Koordinator, um Ihre LRAs zu verwalten. Dies könnte ein separater Dienst oder Teil Ihrer bestehenden Infrastruktur sein. Hier ist eine einfache Konfiguration mit Quarkus:


quarkus.lra.coordinator.url=http://localhost:8080/lra-coordinator

3. Annotieren Sie Ihre Methoden

Jetzt kommt der spaßige Teil - das Annotieren Ihrer Methoden, um an LRAs teilzunehmen. Hier ist ein einfaches Beispiel:


@Path("/order")
public class OrderService {

    @POST
    @Path("/create")
    @LRA(LRA.Type.REQUIRED)
    public Response createOrder(@HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) String lraId) {
        // Ihre Logik zur Auftragserstellung hier
        return Response.ok().build();
    }

    @PUT
    @Path("/complete")
    @Complete
    public Response completeOrder(@HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) String lraId) {
        // Logik zum Abschließen der Bestellung
        return Response.ok().build();
    }

    @PUT
    @Path("/compensate")
    @Compensate
    public Response compensateOrder(@HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) String lraId) {
        // Logik zur Kompensation (Stornierung) der Bestellung
        return Response.ok().build();
    }
}

In diesem Beispiel startet oder tritt createOrder einer LRA bei, completeOrder wird aufgerufen, wenn die LRA erfolgreich abgeschlossen wird, und compensateOrder wird aufgerufen, wenn die LRA zurückgesetzt werden muss.

LRA-Anmerkungen: Ihre neuen besten Freunde

LRA kommt mit einer Reihe von Anmerkungen, die das Verwalten von langlaufenden Aktionen zum Kinderspiel machen. Lassen Sie uns die wichtigsten aufschlüsseln:

@LRA

Dies ist der Star der Show. Verwenden Sie es, um den Umfang Ihrer LRA zu definieren:


@LRA(LRA.Type.REQUIRED)
public Response doSomething() {
    // Diese Methode wird immer innerhalb einer LRA ausgeführt
}

Der Type-Parameter kann sein:

  • REQUIRED: Einer bestehenden LRA beitreten oder eine neue erstellen
  • REQUIRES_NEW: Immer eine neue LRA erstellen
  • MANDATORY: Muss innerhalb einer bestehenden LRA aufgerufen werden
  • SUPPORTS: Eine LRA verwenden, wenn vorhanden, andernfalls ohne eine ausführen
  • NOT_SUPPORTED: Ohne LRA ausführen, selbst wenn eine existiert

@Compensate

Dies ist Ihr Sicherheitsnetz. Verwenden Sie es, um zu definieren, was passieren soll, wenn etwas schiefgeht:


@Compensate
public Response undoStuff(URI lraId) {
    // Aufräumlogik hier
    return Response.ok().build();
}

@Complete

Der glückliche Weg. Diese Methode wird aufgerufen, wenn Ihre LRA erfolgreich abgeschlossen wird:


@Complete
public Response finalizeStuff(URI lraId) {
    // Finalisierungslogik hier
    return Response.ok().build();
}

Koordinieren von Aktionen: Der LRA-Tanz

Jetzt, da wir unsere Anmerkungen haben, sehen wir, wie LRA Aktionen über Dienste hinweg koordiniert. Stellen Sie sich vor, wir bauen einen Online-Buchladen mit separaten Diensten für Inventar, Zahlung und Versand.

Der Bestellablauf:


@Path("/order")
public class OrderService {

    @Inject
    InventoryService inventoryService;
    
    @Inject
    PaymentService paymentService;
    
    @Inject
    ShippingService shippingService;

    @POST
    @Path("/place")
    @LRA(LRA.Type.REQUIRED)
    public Response placeOrder(Order order) {
        // Schritt 1: Inventar reservieren
        inventoryService.reserveBooks(order.getBooks());
        
        // Schritt 2: Zahlung verarbeiten
        paymentService.processPayment(order.getTotal());
        
        // Schritt 3: Versand arrangieren
        shippingService.arrangeShipment(order.getShippingDetails());
        
        return Response.ok().build();
    }

    @Compensate
    public Response compensateOrder(URI lraId) {
        // Wenn etwas schiefgeht, wird dies aufgerufen, um alles rückgängig zu machen
        inventoryService.releaseReservation(lraId);
        paymentService.refundPayment(lraId);
        shippingService.cancelShipment(lraId);
        return Response.ok().build();
    }

    @Complete
    public Response completeOrder(URI lraId) {
        // Dies wird aufgerufen, wenn alles erfolgreich ist
        inventoryService.confirmReservation(lraId);
        paymentService.confirmPayment(lraId);
        shippingService.confirmShipment(lraId);
        return Response.ok().build();
    }
}

In diesem Beispiel, wenn ein Schritt fehlschlägt (z.B. die Zahlung nicht durchgeht), wird die @Compensate-Methode aufgerufen, um alle vorherigen Schritte rückgängig zu machen. Wenn alles erfolgreich ist, finalisiert die @Complete-Methode die Bestellung.

Timeouts und Stornierungsrichtlinien: Ihre LRAs im Griff behalten

LRAs sind von Natur aus langlaufend, aber manchmal wird "langlaufend" zu "endlos". Um zu verhindern, dass Ihre LRAs außer Kontrolle geraten, bietet MicroProfile LRA Mechanismen für Timeouts und Stornierungen.

Timeouts festlegen

Sie können ein Timeout für Ihre LRA mit dem timeLimit-Parameter der @LRA-Anmerkung festlegen:


@LRA(value = LRA.Type.REQUIRED, timeLimit = 10, timeUnit = ChronoUnit.MINUTES)
public Response longRunningOperation() {
    // Diese LRA wird automatisch nach 10 Minuten ablaufen
    // ...
}

Wenn die LRA nicht innerhalb der angegebenen Zeit abgeschlossen wird, wird sie automatisch abgebrochen und die @Compensate-Methode wird aufgerufen.

Manuelle Stornierung

Manchmal müssen Sie eine LRA manuell stornieren. Sie können dies tun, indem Sie den LRAClient injizieren und dessen cancel-Methode aufrufen:


@Inject
LRAClient lraClient;

public void cancelOperation(URI lraId) {
    lraClient.cancel(lraId);
}

LRA vs. Sagas: Wählen Sie Ihre Waffe

An diesem Punkt denken Sie vielleicht: "Moment mal, das klingt sehr nach dem Saga-Muster!" Sie liegen nicht falsch. LRAs und Sagas sind wie Cousins in der Familie der verteilten Transaktionen. Lassen Sie uns die Ähnlichkeiten und Unterschiede aufschlüsseln:

Ähnlichkeiten:

  • Beide behandeln langlaufende, verteilte Transaktionen
  • Beide verwenden Kompensation, um Teilarbeiten rückgängig zu machen
  • Beide streben nach eventual consistency

Unterschiede:

  • LRA ist eine standardisierte Spezifikation, während Saga ein Muster ist
  • LRA bietet integrierte Unterstützung durch Anmerkungen, was die Implementierung erleichtert
  • Sagas verwenden typischerweise Ereignisse zur Koordination, während LRA HTTP-Header verwendet

Wann sollten Sie also LRA über Sagas verwenden?

  • Wenn Sie ein MicroProfile-kompatibles Framework verwenden (wie Quarkus oder Open Liberty)
  • Wenn Sie einen standardisierten Ansatz mit weniger Boilerplate-Code wünschen
  • Wenn Sie einen eher deklarativen Stil mit Anmerkungen bevorzugen

Auf der anderen Seite könnten Sagas die bessere Wahl sein, wenn:

  • Sie mehr Kontrolle über den Kompensationsprozess benötigen
  • Ihr System stark ereignisgesteuert ist
  • Sie kein MicroProfile-kompatibles Framework verwenden

Überwachung und Verwaltung von LRA-Lebenszyklen

Jetzt, da wir unsere LRAs am Laufen haben, wie behalten wir sie im Auge? Die Überwachung von LRAs ist entscheidend, um die Gesundheit und Leistung Ihrer verteilten Transaktionen zu verstehen.

Zu beobachtende Metriken

MicroProfile LRA bietet mehrere Metriken von Haus aus:

  • lra_started: Anzahl der gestarteten LRAs
  • lra_completed: Anzahl der erfolgreich abgeschlossenen LRAs
  • lra_cancelled: Anzahl der abgebrochenen LRAs
  • lra_duration: Dauer der LRAs

Sie können diese Metriken mit MicroProfile Metrics exponieren. Hier ist, wie Sie es in Quarkus einrichten könnten:


quarkus.smallrye-metrics.extensions.lra.enabled=true

Integration mit Überwachungstools

Sobald Sie Ihre Metriken exponiert haben, können Sie sie mit beliebten Überwachungstools integrieren. Hier ist ein kurzes Beispiel, wie Sie eine Prometheus-Scrape-Konfiguration einrichten könnten:


scrape_configs:
  - job_name: 'lra-metrics'
    metrics_path: '/metrics'
    static_configs:
      - targets: ['localhost:8080']

Und eine einfache Grafana-Dashboard-Abfrage, um LRA-Dauern zu visualisieren:


rate(lra_duration_seconds_sum[5m]) / rate(lra_duration_seconds_count[5m])

Protokollierung und Alarmierung

Vergessen Sie nicht, eine ordnungsgemäße Protokollierung für Ihre LRAs einzurichten. Hier ist ein einfaches Beispiel mit SLF4J:


@Inject
Logger logger;

@LRA
public void someOperation() {
    logger.info("Starting LRA: {}", Context.getObjectId());
    // ...
}

@Complete
public void completeOperation() {
    logger.info("Completing LRA: {}", Context.getObjectId());
    // ...
}

@Compensate
public void compensateOperation() {
    logger.warn("Compensating LRA: {}", Context.getObjectId());
    // ...
}

Richten Sie Alarme für abgebrochene LRAs oder LRAs ein, die bestimmte Dauern überschreiten, um potenzielle Probleme frühzeitig zu erkennen.

Reale Beispiele: LRA in Aktion

Schauen wir uns ein paar reale Szenarien an, in denen MicroProfile LRA glänzt:

Beispiel 1: Reisebuchungssystem

Stellen Sie sich ein Reisebuchungssystem vor, in dem Benutzer Flüge, Hotels und Mietwagen in einer einzigen Transaktion buchen können. So könnten Sie es mit LRA strukturieren:


@Path("/booking")
public class BookingService {

    @Inject
    FlightService flightService;
    
    @Inject
    HotelService hotelService;
    
    @Inject
    CarRentalService carRentalService;

    @POST
    @Path("/create")
    @LRA(LRA.Type.REQUIRES_NEW)
    public Response createBooking(BookingRequest request) {
        flightService.bookFlight(request.getFlightDetails());
        hotelService.reserveRoom(request.getHotelDetails());
        carRentalService.rentCar(request.getCarDetails());
        return Response.ok().build();
    }

    @Compensate
    public Response compensateBooking(URI lraId) {
        flightService.cancelFlight(lraId);
        hotelService.cancelReservation(lraId);
        carRentalService.cancelRental(lraId);
        return Response.ok().build();
    }

    @Complete
    public Response completeBooking(URI lraId) {
        flightService.confirmFlight(lraId);
        hotelService.confirmReservation(lraId);
        carRentalService.confirmRental(lraId);
        return Response.ok().build();
    }
}

In diesem Beispiel, wenn ein Teil der Buchung fehlschlägt (z.B. das Hotel ist ausgebucht), wird die gesamte Transaktion zurückgesetzt, um sicherzustellen, dass der Benutzer nicht mit Teilbuchungen endet.

Beispiel 2: E-Commerce-Bestellabwicklung

So könnte ein E-Commerce-Bestellabwicklungssystem LRA verwenden, um die Komplexität der Auftragsabwicklung zu bewältigen:


@Path("/order")
public class OrderProcessingService {

    @Inject
    InventoryService inventoryService;
    
    @Inject
    PaymentService paymentService;
    
    @Inject
    ShippingService shippingService;
    
    @Inject
    NotificationService notificationService;

    @POST
    @Path("/process")
    @LRA(LRA.Type.REQUIRES_NEW, timeLimit = 30, timeUnit = ChronoUnit.MINUTES)
    public Response processOrder(Order order) {
        String orderId = order.getId();
        inventoryService.reserveItems(orderId, order.getItems());
        paymentService.processPayment(orderId, order.getTotalAmount());
        String trackingNumber = shippingService.createShipment(orderId, order.getShippingAddress());
        notificationService.sendOrderConfirmation(orderId, trackingNumber);
        return Response.ok().build();
    }

    @Compensate
    public Response compensateOrder(URI lraId) {
        String orderId = extractOrderId(lraId);
        inventoryService.releaseReservedItems(orderId);
        paymentService.refundPayment(orderId);
        shippingService.cancelShipment(orderId);
        notificationService.sendOrderCancellationNotice(orderId);
        return Response.ok().build();
    }

    @Complete
    public Response completeOrder(URI lraId) {
        String orderId = extractOrderId(lraId);
        inventoryService.confirmItemsShipped(orderId);
        paymentService.finalizePayment(orderId);
        shippingService.dispatchShipment(orderId);
        notificationService.sendShipmentDispatchedNotification(orderId);
        return Response.ok().build();
    }

    private String extractOrderId(URI lraId) {
        // Bestell-ID aus LRA-ID extrahieren
        // ...
    }
}

Dieses Beispiel zeigt, wie LRA einen komplexen Bestellabwicklungsprozess verwalten kann, indem alle Schritte (Inventarverwaltung, Zahlungsabwicklung, Versand und Kundenbenachrichtigung) koordiniert und bei Bedarf zurückgesetzt werden können.

Fazit: Verteilte Harmonie mit LRA umarmen

MicroProfile LRA bringt frischen Wind in die Welt der verteilten Transaktionen. Es bietet einen standardisierten, anmerkungsgetriebenen Ansatz zur Verwaltung langlaufender Aktionen über Microservices hinweg und findet ein Gleichgewicht zwischen Konsistenz und den Realitäten verteilter Systeme.

Wichtige Erkenntnisse:

  • LRA setzt auf eventual consistency und ist damit eine gute Wahl für Microservices-Architekturen
  • Der anmerkungsbasierte Ansatz reduziert Boilerplate und erleichtert das Verständnis von Transaktionsgrenzen
  • Die eingebaute Unterstützung für Kompensation ermöglicht eine elegante Handhabung von Fehlern
  • Die Integration mit MicroProfile macht Überwachung und Metriken zum Kinderspiel

Wenn Sie sich in die Welt der verteilten Transaktionen wagen, sollten Sie MicroProfile LRA in Betracht ziehen. Es könnte genau die geheime Zutat sein, nach der Ihre Microservices gesucht haben!

"In verteilten Systemen ist Perfektion der Feind des Guten. LRA hilft uns, eine 'gut genug' Konsistenz zu erreichen, ohne Skalierbarkeit oder Leistung zu opfern."

Denken Sie daran, dass LRA zwar mächtig ist, aber kein Allheilmittel. Berücksichtigen Sie immer Ihren spezifischen Anwendungsfall und Ihre Anforderungen, wenn Sie zwischen LRA, Sagas oder anderen Mustern für verteilte Transaktionen wählen.

Viel Spaß beim Programmieren, und mögen Ihre verteilten Transaktionen immer zu Ihren Gunsten sein!