Bei der Planung der Interaktion zwischen Mikrodiensten steht oft die Frage nach der Implementierung verteilter Transaktionen im Vordergrund. In Monolithen reichen die eingebauten Mechanismen aus, aber bei Mikrodiensten wird die Situation aufgrund unterschiedlicher Datenbanken, Technologien und Datenformaten komplizierter. Die wichtigste Regel lautet: Vermeiden Sie lange verteilte Transaktionen, sie skalieren schlecht und bergen das Risiko einer Verschlechterung der Leistung.
Anstelle klassischer ACID-Protokolle wird empfohlen, das SAGA-Muster zu verwenden. Dies ist eine Kette von lokalen Transaktionen, bei der jeder Mikrodienst seine Änderungen festhält und, falls ein Rollback erforderlich ist, eine Kompensationsoperation im Rahmen seiner Verantwortung sendet.
Ein Beispiel für eine vereinfachte Implementierung der Saga-Verwaltung in Node.js mit REST:
// Saga-Orchestrator auf Express app.post('/saga', async (req, res) => { try { await serviceA.transaction(); await serviceB.transaction(); res.send('ok'); } catch (err) { await serviceA.rollback(); res.status(500).send('rollback durchgeführt'); } });
Wichtige Merkmale:
Kann man klassische Zwei-Phasen-Commits (2PC) zwischen Mikrodiensten zur Unterstützung von Transaktionen verwenden?
Ja, aber das wird für mikrodienstliche Architekturen nicht empfohlen. 2PC bremst die Skalierung und bindet die Dienste technologisch und organisatorisch.
Sind alle SAGA-Szenarien für Finanzoperationen geeignet?
Nein. SAGA ist schwieriger korrekt zu implementieren für Szenarien, in denen die Striktheit von ACID entscheidend ist, zum Beispiel das Neuzählen von Beständen auf einem Konto. Es ist wichtig, Risiken abzuschätzen und einen Kompromiss zu wählen.
Wie erfolgt die Bearbeitung eines Fehlschlags eines Zwischenschrittes, wenn sich ein Mikrodienst nicht zurückziehen kann?
In solchen Fällen muss ein manueller oder automatisierter Kompensationsprotokoll implementiert werden, möglicherweise mithilfe eines separaten Ereignisprotokolls.