Als PDF, PPTX herunterladen
Hochgeladen vonOPEN KNOWLEDGE GmbH
Spaß mit Microservices: Transaktionen
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 BranchenneutraleSoftwareentwicklung & IT-Beratung
- 3. #WISSENTEILEN ÜBER MICH Wer binich - 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 dasProblem? Die Alternative a.k.a. „Plan B“ TX via SAGA Pattern
- 5.
- 6.
- 7.
- 8.
- 9.
- 10.
- 11. #WISSENTEILEN Hey, lasst unsMicroservices machen …
- 12. #WISSENTEILEN Lasst und zusammengehörigeLogik finden.
- 13. #WISSENTEILEN Und in „kleine“Services zerlegen.
- 14. #WISSENTEILEN Upps, das giltnatürlich auch für die DB!
- 15.
- 16.
- 17.
- 18.
- 19. #WISSENTEILEN Das klappt nieim Leben! (Anonymous, DB Admin)
- 20.
- 21.
- 22. #WISSENTEILEN#WISSENTEILEN „Benötigen wir wirklicheine Transaktion oder gibt es einen fachlich sinnvollen Plan B?“
- 23. #WISSENTEILEN „Starbucks does notknow Two-Phase-Commit“ http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html
- 24. #WISSENTEILEN The Real Worldis not transactional!
- 25. #WISSENTEILEN The Online Worldis not transactional!
- 26.
- 27.
- 28.
- 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.
- 31.
- 32.
- 33.
- 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.
- 36.
- 37.
- 38.
- 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 knownvalue of items available:
- 41. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service checkOut #2 #4 least knownvalue of items available:
- 42.
- 43. #WISSENTEILEN Optimistic w/ Safeguard Order Service Inventory Service checkOut #2 2 itemsleft! #2 least known value of items available:
- 44.
- 45.
- 46. #WISSENTEILEN Order Service Inventory Service #0 Good to have aPlan „B“ #1 least known value of items available:
- 47. #WISSENTEILEN Good to have aPlan „B“ Order Service Inventory Service #0 checkOut #1 least known value of items available:
- 48. #WISSENTEILEN Good to have aPlan „B“ Order Service Inventory Service #0 checkOut #1 least known value of items available: „Ist der Datenstand konsistent?“
- 49. #WISSENTEILEN Good to have aPlan „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!
- 51.
- 52.
- 53. #WISSENTEILEN Fachliche TX überServicegrenzen 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.
- 58. #WISSENTEILEN Wie garantiere ichdie Konsistent der Daten über Servicegrenzen hinweg?
- 59.
- 60.
- 61.
- 62. #WISSENTEILEN Geänderte Servicegrenzen • technologischeine 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
- 63.
- 64.
- 65. #WISSENTEILEN Die „XA“ Strategie Btw: DB locks Btw:Chatty O(4n) mit Retries = (n^2) Btw: CAP Theorem
- 66. #WISSENTEILEN Verteilte Transaktionen viaXA • aus Developer-Sicht wie lokale TX, aber … • Verlust der losen Kopplung, da synchrone IPC • kein Support durch „moderne Plattformen“* * Cloud-Komponenten, noSQL, MQs
- 67.
- 68. #WISSENTEILEN Die „DIY 2PC“ Strategie* *Nein, daswillst du nicht. Glaube mir!
- 69. #WISSENTEILEN Strategie #4 Business TXvia SAGA Pattern
- 70. #WISSENTEILEN Quelle: SAGAS, Hector Garcia-Molina &Kenneth Salem, January 1987 Die „Saga“ Strategie
- 71. #WISSENTEILEN Verteilte Transaktionen viaSAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler technischer Transitionen / Transaktionen
- 72.
- 73. #WISSENTEILEN Verteilte Transaktionen viaSAGAs • 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 smalleror equals customer.creditLimit
- 75. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 76. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 77. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 78. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 79. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 80. #WISSENTEILEN Wow, that is simple! Whatcan go wrong?
- 81.
- 82.
- 83. #WISSENTEILEN Die „Saga“ Strategie CA = CompensationAlgorith a.k.a. Compensation Transaction
- 84. #WISSENTEILEN Die „Saga“ Strategie CA = CompensationAlgorith a.k.a. Compensation Transaction „Every Ti has its Ci“
- 85. #WISSENTEILEN Verteilte Transaktionen viaSAGAs • 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.
- 87. #WISSENTEILEN Steuerung von SAGAs TX1 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
- 91.
- 92.
- 93.
- 94.
- 95.
- 96.
- 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“
- 101.
- 102.
- 103.
- 104.
- 105.
- 106.
- 107.
- 108.
- 109.
- 110.
- 111.
- 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
- 115.
- 116. #WISSENTEILEN Konsistenz von Datenund 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 Datenund Nachrichten
- 118. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 119. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 120. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 121. #WISSENTEILEN Konsistenz von Datenund 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.
- 124.
- 125.
- 126.
- 127.
- 128. #WISSENTEILEN Die Weisheit desTages: „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 viaSAGAs • „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
- 132.
- 133. #WISSENTEILEN Ressourcen • SAGA Frameworks EventuateTram Sagas • Lightweight Workflow Engines Zeebe.io • See also https://github.com/meirwah/awesome-workflow-engines
- 134. #WISSENTEILEN Kontakt LARS RÖWEKAMP CIO NEWTECHNOLOGIES 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.