Mittendrin statt nur dabei: Microservices und Transaktionen
•
2 gefällt mir•851 views
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.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Mittendrin statt nur dabei: Microservices und Transaktionen
Ähnlich wie Mittendrin statt nur dabei: Microservices und Transaktionen (20)
Mehr von OPEN KNOWLEDGE GmbH
Mehr von OPEN KNOWLEDGE GmbH (20)
Mittendrin statt nur dabei: Microservices und Transaktionen
- 1. #WISSENTEILEN Mittendrin statt nur dabei: Microservices & Transactions #WISSENTEILEN Lars Röwekamp | @_openKnowledge | @mobileLarson
- 2. #WISSENTEILEN ÜBER OPEN KNOWLEDGE Branchenneutrale Softwareentwicklung & IT-Beratung
- 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)
- 4. #WISSENTEILEN#WISSENTEILEN Agenda: Wo liegt das Problem? Die Alternative a.k.a. „Plan B“ TX via SAGA Pattern
- 11. #WISSENTEILEN Hey, lasst uns Microservices machen …
- 12. #WISSENTEILEN Lasst und zusammengehörige Logik finden.
- 13. #WISSENTEILEN Und in „kleine“ Services zerlegen.
- 14. #WISSENTEILEN Ups, das gilt natürlich auch für die DB!
- 15. #WISSENTEILEN Database per Service Pattern
- 19. #WISSENTEILEN Das klappt nie im Leben! (Anonymous, DB Admin)
- 20. #WISSENTEILEN Wir brauchen Transaktionen! (Anonymous, DB Admin)
- 22. #WISSENTEILEN#WISSENTEILEN „Benötigen wir wirklich eine Transaktion oder gibt es einen fachlich sinnvollen Plan B?“
- 23. #WISSENTEILEN „Starbucks does not know Two-Phase-Commit“ http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
- 24. #WISSENTEILEN The Real World is not transactional!
- 25. #WISSENTEILEN The Online World is not transactional!
- 26. #WISSENTEILEN
- 27. #WISSENTEILEN Der “Plan B“ Produkt im Warenkorb 8
- 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
- 30. #WISSENTEILEN Plan B - Strategy #1: Lazy Evaluation Produkt im Warenkorb 8
- 31. #WISSENTEILEN Plan B - Strategy #1: Lazy Evaluation Produkt im Warenkorb 8
- 32. #WISSENTEILEN Plan B - Strategy #1: Lazy Evaluation Produkt im Warenkorb decrement 8
- 33. #WISSENTEILEN Plan B - Strategy #1: Lazy Evaluation Produkt im Warenkorb decrement 8 – 1 = 7
- 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
- 46. #WISSENTEILEN#WISSENTEILEN Plan B? Schön & gut, aber ich brauche meine Transaktionen!
- 49. #WISSENTEILEN Fachliche TX über Servicegrenzen hinweg
- 50. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson)
- 51. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson)
- 52. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson) „Sichtbarkeit" Order Service „Sichtbarkeit“ Customer Service
- 53. #WISSENTEILEN it‘s all about consistency - eventual -
- 54. #WISSENTEILEN Wie garantiere ich die Konsistent der Daten über Servicegrenzen hinweg?
- 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
- 61. #WISSENTEILEN Die „XA“ Strategie Btw: DB locks Btw: Chatty O(4n) mit Retries = (n^2) Btw: CAP Theorem
- 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
- 64. #WISSENTEILEN Die „DIY 2PC“ Strategie* *Nein, das willst du nicht. Glaube mir!
- 65. #WISSENTEILEN Strategie #4 Business TX via SAGA Pattern
- 66. #WISSENTEILEN Quelle: SAGAS, Hector Garcia-Molina & Kenneth Salem, January 1987 Die „Saga“ Strategie
- 67. #WISSENTEILEN Verteilte Transaktionen via SAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler technischer Transitionen / Transaktionen
- 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
- 76. #WISSENTEILEN Wow, that is simple! What can go wrong?
- 79. #WISSENTEILEN Die „Saga“ Strategie CA = Compensation Algorith a.k.a. Compensation Transaction
- 80. #WISSENTEILEN Die „Saga“ Strategie CA = Compensation Algorith a.k.a. Compensation Transaction „Every Ti has its Ci“
- 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!
- 82. #WISSENTEILEN Frage: Wie koordiniert man das Ganze?
- 83. #WISSENTEILEN Steuerung von SAGAs TX 1 TX 2 TX 3 TX 4 TX 5 TX 6 order = PENDING item = PENDINGAPPORVED APPORVED
- 84. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 85. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 86. #WISSENTEILEN Choreographie von SAGAs • implizite Sequenzsteuerung • verteilte Koordination durch Eventfluss • „Wissen“ liegt bei den beteiligten Services
- 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)
- 95. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 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
- 113. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 114. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 115. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 116. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 117. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 118. #WISSENTEILEN Fehlende Isolation • SAGA = ACD (ACID ohne Isolation) • fehlende Isolation kann zu Anomalien führen (lost updates, dirty reads, event race condition) • Anomalien müssen soweit minimiert bzw. verhindert werden, dass sie fachlich vertretbar sind!
- 119. #WISSENTEILEN
- 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
- 123. #WISSENTEILEN Ressourcen • SAGA Frameworks Eventuate Tram Sagas • Lightweight Workflow Engines Zeebe (Preview) • See also https://github.com/meirwah/awesome-workflow-engines
- 125. #WISSENTEILEN Kontakt LARS RÖWEKAMP CIO NEW TECHNOLOGIES lars.roewekamp@openknowledge.de +49 (0)441 4082 – 0 @mobileLarson @_openknowledge OFFENKUNDIGGUT
- 126. #WISSENTEILEN Bildnachweise #19 © vasakna – fotolia.com #25 © rawpixel.com – shutterstock.com #43 © vadymvdrobot – fotolia.com #82 © pathdoc – shutterstock.com #119 © garagestock – shutterstock.com All other pictures inside this presentation orginate from pixabay.com or were created by my own.