Spendiert man jedem Microservice seine eigene Datenbank (Database-per-Service-Pattern), hat man irgendwann unweigerlich 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 seine 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
34. #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.
39. #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
47. #WISSENTEILEN
Good to have
a Plan „B“
Order
Service
Inventory
Service
#0
checkOut
#1
least known value
of items available:
48. #WISSENTEILEN
Good to have
a Plan „B“
Order
Service
Inventory
Service
#0
checkOut
#1
least known value
of items available:
„Ist der
Datenstand
konsistent?“
49. #WISSENTEILEN
Good to have
a Plan „B“
Order
Service
Inventory
Service
#0
checkOut
#1
least known value
of items available:
„Kann ich
pünktlich
liefern?“*
*„Und ist der Datenstand
letztendlich konsistent
(aka eventual consistency)?“
62. #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
66. #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
73. #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
85. #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!
97. #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?)
98. #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)
100. #WISSENTEILEN
Orchestrierung von SAGAs
• explizite Sequenzsteuerung
• zentraler SAGA-Koordinator im Service
• Command / Handler Pattern
• beteiligte Services haben kein „Wissen“
112. #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)
113. #WISSENTEILEN
Orchestration von SAGAs
• contra
„Smart Orchestrator & Dump Services“ Pattern,
d.h. Risiko, zu viel Business Logic im
Orchestrator zu zentralisieren
114. #WISSENTEILEN
Orchestration von SAGAs
• btw Orchestrator
Will man den wirklich selber bauen? Nein!
Alternative 1: Saga Framework
Alternative 2: Lightweight Workflow Engine
116. #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
128. #WISSENTEILEN
Die Weisheit des Tages:
„Wenn deine Service-Landkarte am Ende
genauso aussieht, wie dein Monolith,
dann hattest du entweder vorher
kein Problem oder wirst zukünftig
eine Menge Probleme haben!“
129. #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
130. #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
131. #WISSENTEILEN
Herausforderungen von SAGAs
• Rollback
Compensation Transactions statt Rollback
• Isolation
SAGAs sind evtl. verflochten, d.h.
Intermediate-States sind für alle sichtbar