Shared Data in verteilten Systemen
•
0 gefällt mir•176 views
Eine auf Microservices basierende Architektur umzusetzen, bedeutet, dass auch die Datenhaltung auf die verschiedenen Services verteilt werden muss. Was aber bedeutet das in der Praxis? Was ist, wenn Daten einer Entität - vollständig oder in Teilen - in mehreren Services benötigt werden? Wie wird referenzielle Integrität über mehrere Services hinweg realisiert? Wie lassen sich serviceübergreifende Transaktionen realisieren? Dies sind nur einige von vielen Fragen, die im Rahmen der Session beantwortet werden. So viel vorab: Umdenken ist gefragt!
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Shared Data in verteilten Systemen
Ähnlich wie Shared Data in verteilten Systemen (20)
Mehr von OPEN KNOWLEDGE GmbH
Mehr von OPEN KNOWLEDGE GmbH (16)
Shared Data in verteilten Systemen
- 1. Shared Data in verteilten Architekturen #WISSENTEILEN Lars Röwekamp (CIO New Technologies) @mobileLarson | @_openknowledge
- 2. @mobileLarson CIO New Technologies OPEN KNOWLEDGE Lars Röwekamp Architecture Microservices Cloud AI & ML < < < < #WISSENTEILEN
- 3. ÜBER OPEN KNOWLEDGE Branchenneutrale Softwareentwicklung & IT-Beratung
- 4. #WISSENTEILEN Wo bitte liegt das Problem
- 5. #WISSENTEILEN MONOLITH ACHTUNG: von Natur aus böse!
- 6. #WISSENTEILEN MONOLITH ACHTUNG: von Natur aus böse! So kann ich nicht arbeiten!
- 7. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE So will ich arbeiten!
- 8. #WISSENTEILEN MI CR O SER VI CES ARCHI TEC TURE unabhängig • entwickeln • testen • deployen • skalieren So will ich arbeiten!
- 10. #WISSENTEILEN Ok, es gibt Challenges … • DS per Service
- 11. #WISSENTEILEN Ok, es gibt Challenges … • DS per Service • Poly Persistence
- 12. #WISSENTEILEN Ok, es gibt Challenges … • DS per Service • Poly Persistence • Joins AB B A
- 13. #WISSENTEILEN Ok, es gibt Challenges … • DS per Service • Poly Persistence • Joins • Redundanz A‘‘ A‘ A
- 14. #WISSENTEILEN Ok, es gibt Challenges … • DS per Service • Poly Persistence • Joins • Redundanz • Integrität A B
- 15. #WISSENTEILEN Ok, es gibt Challenges … • DS per Service • Poly Persistence • Joins • Redundanz • Integrität • Konsistenz A B TX
- 16. Hilfe, ich will meine monolithische Database zurück!
- 17. #WISSENTEILEN Halt, nicht so schnell! Lösungen müssen her.
- 21. #WISSENTEILEN Anforderung: Übersicht der letzten Bestellungen eines Kunden anzeigen
- 22. #WISSENTEILEN Cust Orders GET customerorders/123 … Konzept: Ein spezieller Service CustOrders liefert die gewünschte Übersicht.
- 23. #WISSENTEILEN Cust Orders GET customerorders/123 … Konzept: Ein spezieller Service CustOrders liefert die gewünschte Übersicht. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. ? Orders Customer
- 24. #WISSENTEILEN Lösungsidee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht via API Composition. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. Cust Orders Orders Customer GET customerorders/123 …
- 25. #WISSENTEILEN Lösungsidee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht via API Composition. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. Cust Orders Orders Customer GET customerorders/123 … Aufruf der Data Owner APIs* Data Owner *Integration der Daten lesend via Data Owner schreibend via Data Owner
- 26. #WISSENTEILEN Koordination der Aufrufe Lösungsidee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht via API Composition. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. Cust Orders Orders Customer
- 27. #WISSENTEILEN Koordination der Aufrufe Aggregation der Ergebnisse Lösungsidee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht via API Composition. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. Cust Orders Orders Customer
- 28. #WISSENTEILEN Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ Lösungsidee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht via API Composition. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. Cust Orders Orders Customer
- 29. #WISSENTEILEN Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ btw: starre Kopplung Lösungsidee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht via API Composition. Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services. Cust Orders Orders Customer !
- 30. #WISSENTEILEN Cust Orders Lösungsidee #2: Ein spezieller Service CustOrders hält die gewünschte Übersicht in einer eigenen DB vor.* GET customerorders/123 … * Database-per-Service Pattern benötigte Daten von Customer & Order Herausforderung: Die dafür benötigten Infos der Kunden und Bestellungen liegen in unterschiedlichen Services.
- 31. #WISSENTEILEN Cust Orders Orders Customer Lösungsidee #2: Ein spezieller Service CustOrders hält die gewünschte Übersicht in einer eigenen DB vor.* Herausforderung #2: Änderungen an den Originaldaten müssen propagiert werden. ? * Database-per-Service Pattern Data change benötigte Daten von Customer & Order
- 32. #WISSENTEILEN Cust Orders Orders Customer Data change benötigte Daten von Customer & Order Domain Event: „Order changed“ Lösungsidee #2+: Der CustOrders Service wird via Domänen-Event über die Änderung “informiert“. Herausforderung #2: Änderungen an den Originaldaten müssen propagiert werden. *Integration der Daten lesend via Replikat schreibend via Data Owner
- 33. #WISSENTEILEN Cust Orders Orders Customer *Integration der Daten lesend via optimiertem Replikat schreibend via Data Owner Data change Domain Event: „Order changed“ „Materialized View“* CustumerOrders Lösungsidee #2+: Der CustOrders Service wird via Domänen-Event über die Änderung “informiert“. Herausforderung #2: Änderungen an den Originaldaten müssen propagiert werden.
- 34. #WISSENTEILEN Cust Orders Orders Customer Data change Domain Event: „Order changed“ Lösungsidee #2+: Der CustOrders Service wird via Domänen-Event über die Änderung “informiert“. Herausforderung #2: Änderungen an den Originaldaten müssen propagiert werden. Order NEW Order OLD WARNING: Eventual Consistency, d.h. Original und Replikat sind für einen kurzen Augenblick out-of-sync!
- 35. #WISSENTEILEN Cust Orders Orders Customer Data change Domain Event: „Order changed“ Lösungsidee #2+: Der CustOrders Service wird via Domänen-Event über die Änderung “informiert“. Herausforderung #2: Änderungen an den Originaldaten müssen propagiert werden. Dies führt zu Eventual Consistency. Ist das fachlich ein Problem? Wenn nicht, alles OK! Order NEW Order OLD
- 39. #WISSENTEILEN Eine einzelne Information genau an einem Ort* *How to survive working with Data?
- 40. #WISSENTEILEN Anforderung: Aufgeben einer Bestellung eines Kunden
- 41. #WISSENTEILEN Checkout Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders
- 42. #WISSENTEILEN Checkout Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders Herausforderung: Wie kommen die notwendigen Daten zum Checkout-Service?
- 43. #WISSENTEILEN Checkout Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Datenversorgung: Zu dem Zweck hält der Checkout-Service ein Replikat der notwendigen Daten*. Orders Preferred Delivery Address Preferred Payment Method *ggf. als eigene Domänen-Repräsentation
- 44. #WISSENTEILEN Checkout POST https://ok-shop.de/orders Orders Preferred Delivery Address Preferred Payment Method Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden.
- 45. #WISSENTEILEN Checkout 201 created Location: …/orders/1234 Orders Preferred Delivery Address Preferred Payment Method Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden.
- 46. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Herausforderung: Die bevorzugte Lieferadresse bzw. Zahlungsmethode soll nicht zur Anwendung kommen.
- 47. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Alternative Adresse: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer alternativen Adresse herangezogen.
- 48. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 49. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address GET …/addresses (list all addresses) Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 50. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 200 ok [ „list of addresses“ ] Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 51. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address PUT …/addresses/123 (change pref. delivery address) Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 52. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 204 no content [ ] Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 53. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 54. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 55. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 56. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 57. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Lösungsidee: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse herangezogen.
- 58. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Herausforderung: Eine neue Adresse, die bisher dem System noch nicht bekannt ist, soll zur Anwendung kommen.
- 59. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Konzept: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Neue Adresse anlegen: … auch neue Adressen werden ausschließlich über den Data-Owner Address-Service angelegt und im Anschluss repliziert.
- 60. #WISSENTEILEN Address Lösungsidee: … auch neue Adressen werden ausschließlich über den Data-Owner Address-Service angelegt und im Anschluss repliziert. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address NEW Preferred Delivery Address new Address
- 61. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Lösungsidee: … auch neue Adressen werden ausschließlich über den Data-Owner Address-Service angelegt und im Anschluss repliziert.
- 63. #WISSENTEILEN A B Integrität von Daten über Servicegrenzen hinweg
- 64. #WISSENTEILEN A B Integrität von Daten über Servicegrenzen hinweg
- 65. #WISSENTEILEN A B Integrität von Daten über Servicegrenzen hinweg
- 66. #WISSENTEILEN Anforderung: Übersicht der letzten Bestellungen eines Kunden anzeigen
- 67. #WISSENTEILEN Cust Orders Orders Customer GET customerorders/123 … Ausgangssituation: Kundendaten und zugehörige Bestellungen sind in unterschiedlichen Services abgelegt. *API Composition Pattern * Customer 123 Orders of Customer 123
- 68. #WISSENTEILEN Cust Orders Orders Customer Ausgangssituation: Kundendaten und zugehörige Bestellungen sind in unterschiedlichen Services abgelegt. Herausforderung: Ein Kunde wird gelöscht. Customer 123 Orders of Customer 123
- 69. #WISSENTEILEN Cust Orders Orders Customer Ausgangssituation: Kundendaten und zugehörige Bestellungen sind in unterschiedlichen Services abgelegt. Herausforderung: Ein Kunde wird gelöscht. DELETE customer/123 Was passiert mit den Bestellungen von Kunde 123? Customer 123 Orders of Customer 123
- 70. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. Orders of Customer 123 Idee: Der Bestell-Service wird via Domänen-Event über Löschung des Kunden Informiert. Customer 123 Integrity out of sync
- 71. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. Orders of Customer 123 Idee: Der Bestell-Service wird via Domänen-Event über Löschung des Kunden Informiert. Customer 123 Integrity out of sync* Customer MQ customer 123 deleted *eventual integrity
- 72. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. Orders of Customer 123 Idee: Der Bestell-Service wird via Domänen-Event über Löschung des Kunden Informiert. Customer 123 Customer MQ customer 123 deleted Integrity out of sync* *eventual integrity
- 73. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. Ist die so entstehende Eventual Integrity fachlich akzeptabel? Wenn ja, alles OK. Wenn nein, … Orders of Customer 123 Idee: Der Bestell-Service wird via Domänen-Event über Löschung des Kunden Informiert. Customer 123 Integrity in sync Customer MQ
- 74. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. DELETE customer/123 Customer 123 Orders of Customer 123 * *als gelöscht markiert Idee #2: Der Kunde wird lediglich als gelöscht markiert und die APIs Bedarf angepasst.
- 75. #WISSENTEILEN Cust Orders Orders Customer Idee #2: Der Kunde wird lediglich als gelöscht markiert und die APIs Bedarf angepasst. Herausforderung: Ein Kunde wird gelöscht. Customer 123 Orders of Customer 123 GET customerorders/123 … * *als gelöscht markiert
- 76. #WISSENTEILEN Cust Orders Orders Customer Idee #2: Der Kunde wird lediglich als gelöscht markiert und die APIs Bedarf angepasst. Herausforderung: Ein Kunde wird gelöscht. Customer 123 Orders of Customer 123 GET customerorders/123 … * *als gelöscht markiert Kunde 123 im Status „aktiv“? GET customer/123 200 OK
- 77. #WISSENTEILEN Cust Orders Orders Customer Idee #2: Der Kunde wird lediglich als gelöscht markiert und die APIs Bedarf angepasst. Herausforderung: Ein Kunde wird gelöscht. Customer 123 Orders of Customer 123 GET customerorders/123 … * *als gelöscht markiert Kunde 123 im Status „aktiv“? GET customer/123 404 Not Found
- 78. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. DELETE customer/123 Customer 123 Orders of Customer 123 * *in einer Transaktion löschen Idee #3: Kunde und zugehörige Bestellungen in einer TX löschen. *
- 79. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. DELETE customer/123 Customer 123 Orders of Customer 123 Idee #3: Kunde und zugehörige Bestellungen in einer TX löschen. TX
- 80. #WISSENTEILEN Dein Ernst? Kunden und zugehörige Bestellungen in einer TX löschen?
- 82. #WISSENTEILEN Konsistenz von Daten über Servicegrenzen hinweg A B
- 83. #WISSENTEILEN Konsistenz von Daten über Servicegrenzen hinweg A B TX
- 84. #WISSENTEILEN Transaktionen* sichern Konsistenz * Transactions vs. Database-per-Service Pattern
- 85. #WISSENTEILEN Die Alternative aka „Plan B“* * Transactions vs. Eventual Consistency
- 86. #WISSENTEILEN The Real World is not transactional!
- 87. #WISSENTEILEN The Online World is not transactional!
- 88. #WISSENTEILEN
- 90. #WISSENTEILEN The Optimist „Es wird schon irgendwie gutgehen.“ Strategie #1
- 94. #WISSENTEILEN The Fortune-Teller „Es wird alles gut, vertraue mir!“ Strategie #2
- 95. #WISSENTEILEN The Fortune-Teller Order Service Inventory Service #2 #4 checkOut last known value of items available:
- 96. #WISSENTEILEN The Fortune-Teller Order Service Inventory Service #2 #4 checkOut order-id xyz last known value of items available:
- 97. #WISSENTEILEN The Fortune-Teller Order Service Inventory Service #1 decrement #1 checkOut order-id xyz last known value of items available:
- 98. #WISSENTEILEN The Safeguard „Ich frage besser noch mal nach!“ Strategie #3
- 99. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #4 last known value of items available: checkOut
- 100. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #4 last known value of items available: checkOut inventory?
- 101. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #2 last known value of items available: checkOut inventory? 2 items left!
- 102. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #2 last known value of items available: checkOut order-id xyz inventory? 2 items left!
- 103. #WISSENTEILEN The Safeguard Order Service Inventory Service #1 #1 last known value of items available: decrement checkOut order-id xyz
- 104. #WISSENTEILEN The Plan “B“ „Es gibt immer eine Alternative!“ Strategie #4
- 105. #WISSENTEILEN Order Service Inventory Service #0 checkOut #1 Plan „B“ last known value of items available:
- 106. #WISSENTEILEN Order Service Inventory Service #0 checkOut #1 „Ist der Datenstand konsistent?“ Plan „B“ last known value of items available:
- 107. #WISSENTEILEN Order Service Inventory Service #0 checkOut „Kann ich pünktlich liefern?“* Plan „B“ last known value of items available: #1
- 108. #WISSENTEILEN Order Service Inventory Service #0 checkOut „Kann ich pünktlich liefern?“* * … und ist der Datenstand letztendlich konsistent (aka eventual consistency)? Plan „B“ last known value of items available: #0
- 109. #WISSENTEILEN #WISSENTEILEN Plan B? Schön & gut, aber ich brauche meine Transaktionen!
- 110. #WISSENTEILEN Konsistenz von Daten über Servicegrenzen hinweg A B TX
- 111. #WISSENTEILEN DISCLAIMER Im folgenden Beispiel wird davon ausgegangen, dass die gezeigten Services bereits „optimal“ geschnitten sind und somit aus Sicht der fachlichen Modellierung keine weitere Optimierung möglich ist. “
- 112. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson)
- 113. #WISSENTEILEN (Quelle: Microservices Pattern, Chris Richardson)
- 114. #WISSENTEILEN Wie garantiere ich die Konsistenz der Daten über Servicegrenzen hinweg?
- 116. #WISSENTEILEN Quelle: SAGAS, Hector Garcia-Molina & Kenneth Salem, January 1987 Die „Saga“ Strategie
- 117. #WISSENTEILEN Verteilte Transaktionen via SAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler technischer Transitionen / Transaktionen
- 118. #WISSENTEILEN Verteilte Transaktionen via SAGAs
- 119. #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
- 120. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 121. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 122. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 123. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 124. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 125. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smaller or equals customer.creditLimit
- 126. #WISSENTEILEN Was ihr mitnehmen solltet. Wow, das ist ja wirklich einfach. Was kann da bitte schon schiefgehen?
- 129. #WISSENTEILEN Die „Saga“ Strategie CA = Compensation Action a.k.a. Compensation Transaction
- 130. #WISSENTEILEN Die „Saga“ Strategie CA = Compensation Action a.k.a. Compensation Transaction „Every Ti has its Ci“
- 131. #WISSENTEILEN Verteilte Transaktionen via SAGAs • wohldefinierte Abfolge von Compensation Actions realisieren verteiltes Rollback • Compensation Actions sind fachlicher Code und somit Applikationslogik • Abfolge von lokalen TXs & CAs kann beliebig komplex werden!
- 132. #WISSENTEILEN Frage: Wie koordiniert man das Ganze?
- 133. #WISSENTEILEN Steuerung von SAGAs TX 1 TX 2 TX 3 TX 4 TX 5 TX 6 order = PENDING item = PENDING APPORVED APPORVED
- 134. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 135. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 136. #WISSENTEILEN Choreographie von SAGAs • implizite Sequenzsteuerung • verteilte Koordination durch Eventfluss • „Wissen“ liegt bei den beteiligten Services
- 143. #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?)
- 144. #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)
- 145. #WISSENTEILEN Steuerung von SAGAs • Choreographie • Orchestrierung
- 146. #WISSENTEILEN Orchestrierung von SAGAs • explizite Sequenzsteuerung • zentraler SAGA-Koordinator im Service • Command / Handler Pattern • beteiligte Services haben kein „Wissen“
- 158. #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)
- 159. #WISSENTEILEN Orchestration von SAGAs • contra „Smart Orchestrator & Dump Services“ Pattern, d.h. Risiko, zu viel Business Logic im Orchestrator zu zentralisieren
- 160. #WISSENTEILEN Orchestration von SAGAs • btw Orchestrator Will man den wirklich selber bauen? Nein! Alternative 1: Saga Framework Alternative 2: Lightweight Workflow Engine
- 162. #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 *Message Broker buffered bei Bedarf die Message
- 163. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 164. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 165. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 166. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 167. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 168. #WISSENTEILEN Fehlende 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! * SAGA = ACD (ACID ohne Isolation)
- 169. #WISSENTEILEN Fehlende Isolation: „lost updates“ create order SAGA ORDER create
- 170. #WISSENTEILEN Fehlende Isolation: „lost updates“ create order SAGA ORDER create cancel order SAGA cancel
- 171. #WISSENTEILEN Fehlende Isolation: „lost updates“ create order SAGA ORDER create approve cancel order SAGA cancel
- 172. #WISSENTEILEN Fehlende Isolation: „dirty reads“ cancel order SAGA CUSTOMER increase credit (from 0 to 100) order value = 100
- 173. #WISSENTEILEN Fehlende Isolation: „dirty reads“ cancel order SAGA CUSTOMER increase credit (from 0 to 100) delivery can‘t be stopped - CA needed!
- 174. #WISSENTEILEN Fehlende Isolation: „dirty reads“ cancel order SAGA CUSTOMER increase credit (from 0 to 100) delivery can‘t be stopped - CA needed! decrease credit (CA) (from 100 to 0)
- 175. #WISSENTEILEN Fehlende Isolation: „dirty reads“ cancel order SAGA CUSTOMER create order SAGA decrease credit (to 10) read credit (100) increase credit (from 0 to 100) decrease credit (CA) (from 100 to 0)
- 176. #WISSENTEILEN Fehlende Isolation: „dirty reads“ cancel order SAGA CUSTOMER create order SAGA decrease credit (to 10) read credit (100) increase credit (from 0 to 100) decrease credit (CA) (from 100 to 0)
- 180. #WISSENTEILEN „Es kann nur eine gültige Quelle je Entität geben.“
- 181. #WISSENTEILEN „Denke in fachlichen statt in technischen Transaktionen.“
- 182. #WISSENTEILEN „Denke in Domänen statt in Entitäten.“
- 185. #WISSENTEILEN Shared Data in verteilten Architekturen Lars Röwekamp | @mobileLarson BESTEN DANK! #WISSENTEILEN Microservices Pattern
- 186. #WISSENTEILEN Shared Data in verteilten Architekturen Lars Röwekamp | @mobileLarson Feedback erwünscht! #WISSENTEILEN Microservices Pattern
- 187. #WISSENTEILEN © Sharon McCutcheon – pexels.com (Folie 01) © Monstera – pexels.com (Folie 04) © Andrea Piascquadio – pexels.com (Folie 21, 22, 248) © Gert Altmann – pexels.com (Folie 177) Alle weiteren Bilder und Icons der Präsentation sind entweder von pexels.com, pixabay.com, unsplash.com, flaticon.com oder von mir selbst erstellt. Bildernachweis