Spaß mit Microservices: Transaktionen
1 gefällt mir969 aufrufe
Das Dokument behandelt Herausforderungen und Lösungen bei der Transaktionsverwaltung in Microservices, insbesondere die Notwendigkeit, Transaktionen zu adaptieren, wenn traditionelle Ansätze scheitern. Es werden alternative Strategien vorgestellt, wie das Saga-Muster zur Umsetzung verteilter Transaktionen durch lokale Transaktionen zu nutzen und die Wichtigkeit der Konsistenz von Daten und Nachrichten hervorzuheben. Der Fokus liegt auf der Überlegung von Prozess- und Servicegrenzen sowie der Implementierung von Kompensationsmechanismen für fehlgeschlagene Aktionen.
Spaß mit Microservices: Transaktionen
- 1. #WISSENTEILEN Aus der Rubrik „Spaß mit Microservices“ Transaktionen #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 Upps, 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
- 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.
- 35. #WISSENTEILEN Beeing Optimistic Order Service Inventory Service #2 #4 least known value of items available:
- 36. #WISSENTEILEN Beeing Optimistic Order Service Inventory Service checkOut #2 #4 least known value of items available:
- 37. #WISSENTEILEN Beeing Optimistic Order Service Inventory Service checkOut #1 decrement #1 least known value of items available:
- 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
- 40. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service #2 #4 least known value of items available:
- 41. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service checkOut #2 #4 least known value of items available:
- 42. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service checkOut #2 inventory? #4 least known value of items available:
- 43. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service checkOut #2 2 items left! #2 least known value of items available:
- 44. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service checkOut #1 decrement #1 least known value of items available:
- 46. #WISSENTEILEN Order Service Inventory Service #0 Good to have a Plan „B“ #1 least known value of items available:
- 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)?“
- 50. #WISSENTEILEN#WISSENTEILEN Plan B? Schön & gut, aber ich brauche meine Transaktionen!
- 53. #WISSENTEILEN Fachliche TX über Servicegrenzen hinweg
- 54. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson)
- 55. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson)
- 56. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson) „Sichtbarkeit" Order Service „Sichtbarkeit“ Customer Service
- 57. #WISSENTEILEN it‘s all about consistency - eventual -
- 58. #WISSENTEILEN Wie garantiere ich die Konsistent der Daten über Servicegrenzen hinweg?
- 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
- 65. #WISSENTEILEN Die „XA“ Strategie Btw: DB locks Btw: Chatty O(4n) mit Retries = (n^2) Btw: CAP Theorem
- 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
- 68. #WISSENTEILEN Die „DIY 2PC“ Strategie* *Nein, das willst du nicht. Glaube mir!
- 69. #WISSENTEILEN Strategie #4 Business TX via SAGA Pattern
- 70. #WISSENTEILEN Quelle: SAGAS, Hector Garcia-Molina & Kenneth Salem, January 1987 Die „Saga“ Strategie
- 71. #WISSENTEILEN Verteilte Transaktionen via SAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler technischer Transitionen / Transaktionen
- 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
- 74. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 75. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 76. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 77. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 78. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 79. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 80. #WISSENTEILEN Wow, that is simple! What can go wrong?
- 83. #WISSENTEILEN Die „Saga“ Strategie CA = Compensation Algorith a.k.a. Compensation Transaction
- 84. #WISSENTEILEN Die „Saga“ Strategie CA = Compensation Algorith a.k.a. Compensation Transaction „Every Ti has its Ci“
- 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!
- 86. #WISSENTEILEN Frage: Wie koordiniert man das Ganze?
- 87. #WISSENTEILEN Steuerung von SAGAs TX 1 TX 2 TX 3 TX 4 TX 5 TX 6 order = PENDING item = PENDINGAPPORVED APPORVED
- 88. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 89. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 90. #WISSENTEILEN Choreographie von SAGAs • implizite Sequenzsteuerung • verteilte Koordination durch Eventfluss • „Wissen“ liegt bei den beteiligten Services
- 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)
- 99. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 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
- 117. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 118. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 119. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 120. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 121. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 122. #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!
- 123. #WISSENTEILEN
- 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
- 133. #WISSENTEILEN Ressourcen • SAGA Frameworks Eventuate Tram Sagas • Lightweight Workflow Engines Zeebe.io • See also https://github.com/meirwah/awesome-workflow-engines
- 134. #WISSENTEILEN Kontakt LARS RÖWEKAMP CIO NEW TECHNOLOGIES lars.roewekamp@openknowledge.de +49 (0)441 4082 – 0 @mobileLarson @_openknowledge OFFENKUNDIGGUT
- 135. #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.