Als PDF, PPTX herunterladen
![#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.](https://image.slidesharecdn.com/wsmicroservicesdata-220202101745/85/Shared-Data-in-verteilten-Systemen-50-320.jpg)
![#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.](https://image.slidesharecdn.com/wsmicroservicesdata-220202101745/85/Shared-Data-in-verteilten-Systemen-52-320.jpg)
Hochgeladen vonOPEN KNOWLEDGE GmbH
Shared Data in verteilten Systemen
Das Dokument behandelt die Herausforderungen und Lösungen beim Umgang mit Daten in verteilten Architekturen, insbesondere bei der Mikroservices-Architektur. Es werden Konzepte wie API-Komposition und domänenbasierte Event-Integration vorgestellt, um Datenintegrität und Konsistenz zu gewährleisten, wenn Daten über Servicegrenzen hinweg benötigt werden. Zentrale Themen sind der Umgang mit redundanten Daten, die Gewährleistung von Konsistenz und Resilienz sowie die Herausforderungen bei der Löschung von Benutzerdaten und deren Auswirkungen auf verbundene Dienstlein.
Shared Data in verteilten Systemen
- 1. Shared Data in verteiltenArchitekturen #WISSENTEILEN Lars Röwekamp (CIO New Technologies) @mobileLarson | @_openknowledge
- 2. @mobileLarson CIO New Technologies OPENKNOWLEDGE Lars Röwekamp Architecture Microservices Cloud AI & ML < < < < #WISSENTEILEN
- 3. ÜBER OPEN KNOWLEDGE BranchenneutraleSoftwareentwicklung & IT-Beratung
- 4. #WISSENTEILEN Wo bitte liegtdas Problem
- 5.
- 6. #WISSENTEILEN MONOLITH ACHTUNG: von Naturaus böse! So kann ich nicht arbeiten!
- 7. #WISSENTEILEN MI CR O SERVI CES ARCHI TEC TURE So will ich arbeiten!
- 8. #WISSENTEILEN MI CR O SERVI CES ARCHI TEC TURE unabhängig • entwickeln • testen • deployen • skalieren So will ich arbeiten!
- 9.
- 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 willmeine monolithische Database zurück!
- 17. #WISSENTEILEN Halt, nicht soschnell! Lösungen müssen her.
- 18.
- 19.
- 20.
- 21. #WISSENTEILEN Anforderung: Übersicht der letztenBestellungen eines Kunden anzeigen
- 22. #WISSENTEILEN Cust Orders GET customerorders/123 … Konzept: Einspezieller Service CustOrders liefert die gewünschte Übersicht.
- 23. #WISSENTEILEN Cust Orders GET customerorders/123 … Konzept: Einspezieller 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 CustOrdersliefert 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 CustOrdersliefert 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: Einspezieller 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 Aggregationder 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 Aggregationder 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 Aggregationder 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 speziellerService 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 speziellerService 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 Datenvon 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 lesendvia 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: „Orderchanged“ 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: „Orderchanged“ 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
- 36.
- 37.
- 38.
- 39. #WISSENTEILEN Eine einzelne Information genau aneinem Ort* *How to survive working with Data?
- 40.
- 41. #WISSENTEILEN Checkout Konzept: Der gesamte Bestellvorgang kannim „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders
- 42. #WISSENTEILEN Checkout Konzept: Der gesamte Bestellvorgang kannim „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 kannim „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 DeliveryAddress 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 PreferredDelivery 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 PreferredPayment 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 PreferredPayment 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 DeliveryAddress 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 PreferredPayment 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 PreferredPayment 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 neueAdressen 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 DeliveryAddress 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.
- 62.
- 63. #WISSENTEILEN A B Integrität von Daten überServicegrenzen hinweg
- 64. #WISSENTEILEN A B Integrität von Daten überServicegrenzen hinweg
- 65. #WISSENTEILEN A B Integrität von Daten überServicegrenzen hinweg
- 66. #WISSENTEILEN Anforderung: Übersicht der letztenBestellungen eines Kunden anzeigen
- 67. #WISSENTEILEN Cust Orders Orders Customer GET customerorders/123 … Ausgangssituation: Kundendatenund 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 sindin 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 sindin 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 wirdgelö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 wirdgelö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 wirdgelö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 wirdgelö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 wirdgelö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 Kundewird 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 Kundewird 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 Kundewird 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 wirdgelö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 wirdgelö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? Kundenund zugehörige Bestellungen in einer TX löschen?
- 81.
- 82.
- 83.
- 84. #WISSENTEILEN Transaktionen* sichern Konsistenz * Transactionsvs. Database-per-Service Pattern
- 85. #WISSENTEILEN Die Alternative aka „PlanB“* * Transactions vs. Eventual Consistency
- 86. #WISSENTEILEN The Real Worldis not transactional!
- 87. #WISSENTEILEN The Online Worldis not transactional!
- 88.
- 89.
- 90. #WISSENTEILEN The Optimist „Es wirdschon irgendwie gutgehen.“ Strategie #1
- 91.
- 92.
- 93.
- 94. #WISSENTEILEN The Fortune-Teller „Es wirdalles gut, vertraue mir!“ Strategie #2
- 95.
- 96.
- 97.
- 98. #WISSENTEILEN The Safeguard „Ich fragebesser noch mal nach!“ Strategie #3
- 99. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #4 last known value ofitems available: checkOut
- 100. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #4 last known value ofitems available: checkOut inventory?
- 101. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #2 last known value ofitems available: checkOut inventory? 2 items left!
- 102. #WISSENTEILEN The Safeguard Order Service Inventory Service #2 #2 last known value ofitems available: checkOut order-id xyz inventory? 2 items left!
- 103. #WISSENTEILEN The Safeguard Order Service Inventory Service #1 #1 last known value ofitems available: decrement checkOut order-id xyz
- 104. #WISSENTEILEN The Plan “B“ „Esgibt immer eine Alternative!“ Strategie #4
- 105. #WISSENTEILEN Order Service Inventory Service #0 checkOut #1 Plan „B“ last knownvalue of items available:
- 106. #WISSENTEILEN Order Service Inventory Service #0 checkOut #1 „Ist der Datenstand konsistent?“ Plan „B“ lastknown value of items available:
- 107. #WISSENTEILEN Order Service Inventory Service #0 checkOut „Kann ich pünktlich liefern?“* Plan „B“ lastknown 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.
- 111. #WISSENTEILEN DISCLAIMER Im folgenden Beispielwird 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 dieKonsistenz der Daten über Servicegrenzen hinweg?
- 115.
- 116. #WISSENTEILEN Quelle: SAGAS, Hector Garcia-Molina &Kenneth Salem, January 1987 Die „Saga“ Strategie
- 117. #WISSENTEILEN Verteilte Transaktionen viaSAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler technischer Transitionen / Transaktionen
- 118.
- 119. #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
- 120. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 121. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 122. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 123. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 124. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 125. #WISSENTEILEN Die „Saga“ Strategie Invariante: sum(open order) is smalleror equals customer.creditLimit
- 126. #WISSENTEILEN Was ihr mitnehmen solltet. Wow, dasist ja wirklich einfach. Was kann da bitte schon schiefgehen?
- 127.
- 128.
- 129. #WISSENTEILEN Die „Saga“ Strategie CA = CompensationAction a.k.a. Compensation Transaction
- 130. #WISSENTEILEN Die „Saga“ Strategie CA = CompensationAction a.k.a. Compensation Transaction „Every Ti has its Ci“
- 131. #WISSENTEILEN Verteilte Transaktionen viaSAGAs • 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.
- 133. #WISSENTEILEN Steuerung von SAGAs TX1 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
- 137.
- 138.
- 139.
- 140.
- 141.
- 142.
- 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“
- 147.
- 148.
- 149.
- 150.
- 151.
- 152.
- 153.
- 154.
- 155.
- 156.
- 157.
- 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
- 161.
- 162. #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 *Message Broker buffered bei Bedarf die Message
- 163. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 164. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 165. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 166. #WISSENTEILEN Konsistenz von Datenund Nachrichten
- 167. #WISSENTEILEN Konsistenz von Datenund 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: „lostupdates“ create order SAGA ORDER create
- 170. #WISSENTEILEN Fehlende Isolation: „lostupdates“ create order SAGA ORDER create cancel order SAGA cancel
- 171. #WISSENTEILEN Fehlende Isolation: „lostupdates“ create order SAGA ORDER create approve cancel order SAGA cancel
- 172. #WISSENTEILEN Fehlende Isolation: „dirtyreads“ cancel order SAGA CUSTOMER increase credit (from 0 to 100) order value = 100
- 173. #WISSENTEILEN Fehlende Isolation: „dirtyreads“ cancel order SAGA CUSTOMER increase credit (from 0 to 100) delivery can‘t be stopped - CA needed!
- 174. #WISSENTEILEN Fehlende Isolation: „dirtyreads“ 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: „dirtyreads“ 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: „dirtyreads“ 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)
- 177.
- 178.
- 179.
- 180. #WISSENTEILEN „Es kann nur einegültige Quelle je Entität geben.“
- 181. #WISSENTEILEN „Denke in fachlichen statt intechnischen Transaktionen.“
- 182. #WISSENTEILEN „Denke in Domänen stattin Entitäten.“
- 183.
- 184.
- 185. #WISSENTEILEN Shared Data in verteiltenArchitekturen Lars Röwekamp | @mobileLarson BESTEN DANK! #WISSENTEILEN Microservices Pattern
- 186. #WISSENTEILEN Shared Data in verteiltenArchitekturen 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