Spendiert man jedem Microservice seine eigene Datenbank (Database per Service Pattern), läuft man irgendwann unweigerlich in das Problem verteilter Businesstransaktionen. Die gute alte DB-Transaktion fällt per Definition aus dem Rennen. Lässt sich also aus fachlicher Sicht ganz auf Transaktionen verzichten? In vielen Fällen ist das durchaus möglich. Als Alternative zur Sicherstellung Service-übergreifender Datenkonsistenz bietet sich u. a. eine Realisierung auf Basis mehrerer lokaler, technischer Transaktionen an, auch "Saga-Pattern" genannt. Die Session führt in die Theorie des Saga-Patterns ein und zeigt dessen praktische Verwendung an verschiedenen Beispielen.
3. #WISSENTEILEN
ÜBER MICH
Wer bin ich - und wenn ja, wie viele?
• CIO New Technologies
• Enterprise & Mobile
• Autor, Speaker, Coach & Mentor
• Snowboard & MTB Enthusiast (a.k.a. “stets bemüht“)
Lars Röwekamp (a.k.a. @mobileLarson)
29. #WISSENTEILEN
Plan B - Strategy #1: Lazy Evaluation
a.k.a. die „es kommt, wie es kommt“ Strategie
• TX fachlich aufsplitten, sequentiell
durchführen und schauen, ob es klappt
• im Problemfall alternative Logik ausführen
35. #WISSENTEILEN
Plan B - Strategy #2: Beeing Optimistic
a.k.a. die „es wird schon gutgehen“ Strategie
• wie “Lazy Evaluation“ nur mit erhöhter
Wahrscheinlichkeit, dass die „Transaktion“
erfolgreich abläuft.
36. #WISSENTEILEN
Plan B - Strategy #2: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8
37. #WISSENTEILEN
Plan B - Strategy #2: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8
38. #WISSENTEILEN
Plan B - Strategy #2: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10 decrement
8 – 1 = 7
40. #WISSENTEILEN
Plan B - Strategy #3: Safeguard
a.k.a. die „frag besser nochmal nach“ Strategie
• wie “Beeing Optimistic“ nur auf Basis von
„nearly Real-Time“ Daten
41. #WISSENTEILEN
Plan B - Strategy #3: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8
42. #WISSENTEILEN
Plan B - Strategy #3: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8
43. #WISSENTEILEN
Plan B - Strategy #3: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8
Inventory?
44. #WISSENTEILEN
Plan B - Strategy #3: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8
8 items left
Inventory?
45. #WISSENTEILEN
Plan B - Strategy #3: Beeing Optimistic
Produkt im
Warenkorb,
letzter bekannter
Bestand = 10
8 – 1 = 7
decrement
58. #WISSENTEILEN
Geänderte Servicegrenzen
• technologisch eine super Lösung, aber …
• Problem der Verantwortlichkeiten
• Problem Bounded Context / Domänen Modell
• Vorteile der Microservices gehen verloren
• „Big Ball of Mud“ lässt grüßen
62. #WISSENTEILEN
Verteilte Transaktionen via XA
• aus Developer-Sicht wie lokale TX, aber …
• Verlust der losen Kopplung, da synchrone IPC
• kein Support durch „moderne Plattformen“*
* Cloud-Komponenten, noSQL, MQs
69. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• Konsistenz von Daten zwischen Services
wird durch eine wohldefinierte Abfolge lokaler
Transitionen/Transaktionen erreicht.
• Service kommuniziert „erfolgreiche“ lokale
Transition/Transaktion an den nächsten
beteiligten Service*.
*mehr dazu später
81. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• wohldefinierte Abfolge von Compensation
Algorithms realisieren verteiltes Rollback
• Compensation Algorithms sind fachlicher
Code und somit Applikationslogik
• Abfolge von lokalen TXs & CAs kann
beliebig komplex werden!
93. #WISSENTEILEN
Choreographie von SAGAs
• pro
lose gekoppelt (Teilnehmer kennen sich nicht)
relativ einfach zu implementieren
• contra
i.d.R. zyklische Abhängigkeiten
erhöhte Komplexität im Domänen-Modell
kein zentraler Business-Code (wann valide?)
94. #WISSENTEILEN
Choreographie von SAGAs
• btw lose Kopplung
Teilnehmer kennen sich zwar nicht, wissen aber
genau, was bei einem Event zu tun ist und wie
im Anschluss – durch ein eigenes Event – zu
antworten ist (a.k.a. pseudo lose Kopplung)
96. #WISSENTEILEN
Orchestrierung von SAGAs
• explizite Sequenzsteuerung
• zentraler SAGA-Koordinator im Service
• Command / Handler Pattern
• beteiligte Services haben kein „Wissen“
108. #WISSENTEILEN
Orchestration von SAGAs
• pro
Logik ist einfach(er) zu verstehen
fachliche Kopplung nur unidirektional
keine zyklischen Abhängigkeiten
Separation of Concerns (Domain Logic vs. TX)
109. #WISSENTEILEN
Orchestration von SAGAs
• contra
„Smart Orchestrator & Dump Services“ Pattern,
d.h. Risiko, zu viel Business Logic im
Orchestrator zu zentralisieren
110. #WISSENTEILEN
Orchestration von SAGAs
• btw Orchestrator
Will man den wirklich selber bauen? Nein!
Alternative 1: Saga Framework
Alternative 2: Lightweight Workflow Engine
112. #WISSENTEILEN
Konsistenz von Daten und Nachrichten
• Services veröffentlichen „Erfolgs“-Nachricht
direkt nach lokaler TX
• lokale TX und „Erfolgs“-Nachricht sind
atomare Einheit aus Sicht des Services
• garantierte Beendigung der Business TX*
*Message Broker buffered bei Bedarf die Message
120. #WISSENTEILEN
Verteilte Transaktionen via SAGAs
• „Database per Service“ Pattern erfordert
Alternative zu gewohnten Transaktionen
• Sagas simulieren verteilte Transaktion durch
Abfolge lokaler Transaktionen
• Saga Abfolge wird durch Choreographie oder
Orchestrierung koordiniert
121. #WISSENTEILEN
Herausforderungen von SAGAs
• Atomicity
Database & Event TX je Teilnehmer
• Reliability
Reliable Event-basierte Kommunikation
• Coupling
durch Choreographie oder Orchestration geht
die lose Kopplung teilweise verloren
122. #WISSENTEILEN
Herausforderungen von SAGAs
• Rollback
Compensation Transactions statt Rollback
• Isolation
SAGAs sind evtl. verflochten, d.h.
Intermediate-States sind für alle sichtbar