Shared Data in verteilten Architekturen
•
0 recomendaciones•69 vistas
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! Nur wenn die Auftrennung der Fachlichkeit in verschiedenen Microservices auch konsequent bis hin zur Ebene der Datenhaltung vollzogen wird, kann die angestrebte Unabhängigkeit der Services zur Entwicklungs- und Laufzeit erreicht werden. Ohne diesen Schritt dagegen würde sich das Problem der starren Kopplung und der damit einhergehenden Abhängigkeiten einer monolithischen Architektur lediglich um eine Schicht nach unten, in die Datenbank, verlagern. Was aber bedeutet das konsequente Einhalten des Database-per-Service-Patterns und einer damit einhergehenden Verteilung der Datenhaltung in der Praxis? Die Session zeigt die wesentlichen Herausforderungen auf und liefert passende Lösungsansätze.
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Shared Data in verteilten Architekturen
Similar a Shared Data in verteilten Architekturen (20)
Más de OPEN KNOWLEDGE GmbH
Más de OPEN KNOWLEDGE GmbH (20)
Shared Data in verteilten Architekturen
- 1. Shared Data in verteilten Architekturen #WISSENTEILEN Lars Röwekamp (CIO New Technologies) @mobileLarson | @_openknowledge info@openknowledge.de. Shared Data in verteilten Architekturen #WISSENTEILEN Lars Röwekamp | @mobileLarson
- 2. #WISSENTEILEN Lars Röwekamp (CIO New Technologies) @mobileLarson | @_openknowledge @mobileLarson CIO New Technologies OPEN KNOWLEDGE Lars Röwekamp Cloud AI & ML Architecture Microservices < < < <
- 3. #WISSENTEILEN Lars Röwekamp (CIO New Technologies) @mobileLarson | @_openknowledge OPEN KNOWLEDGE @_openknowledge Und da arbeite ich >
- 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!
- 8. #WISSENTEILEN So will ich arbeiten! unabhängig • entwickeln • testen • deployen • skalieren
- 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 Datenbank 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 … Idee: Ein spezieller Service CustOrders liefert die gewünschte Übersicht.
- 23. #WISSENTEILEN Cust Orders GET customerorders/123 … Idee: 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ösung: 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ösung: 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ösung: 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ösung: 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ösung: 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ösung: 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 Idee #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
- 31. #WISSENTEILEN Cust Orders Orders Customer Idee #2: Ein spezieller Service CustOrders hält die gewünschte Übersicht in einer eigenen DB vor.* Herausforderung: Ä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 Lösung #2: Der Service CustOrders wird via Domänen-Events über Änderungen „informiert“. Herausforderung: Änderungen an den Originaldaten müssen propagiert werden. *Integration der Daten lesend via Replikat schreibend via Data Owner Data change benötigte Daten von Customer & Order Domain Event: „Order changed“
- 33. #WISSENTEILEN Cust Orders Orders Customer Lösung #2: Der Service CustOrders wird via Domänen-Events über Änderungen „informiert“ (aka CQRS*). Herausforderung: Änderungen an den Originaldaten müssen propagiert werden. *Integration der Daten lesend via optimiertem Replikat schreibend via Data Owner Data change Domain Event: „Order changed“ Materialized View* CustumerOrders
- 34. #WISSENTEILEN Cust Orders Orders Customer Data change Domain Event: „Order changed“ Lösung #2: Der Service CustOrders wird via Domänen-Events über Änderungen „informiert“. Herausforderung: Ä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ösung #2: Der Service CustOrders wird via Domänen-Events über Änderungen „informiert“. Herausforderung: Ä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* * so kundenfreundlich und effizient wie möglich
- 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: Den Bestell-Service via Domänen-Event über Löschung des Kunden informieren Customer 123 Integrity out of sync
- 71. #WISSENTEILEN Cust Orders Orders Customer Herausforderung: Ein Kunde wird gelöscht. Orders of Customer 123 Idee: Den Bestell-Service via Domänen-Event über Löschung des Kunden informieren 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: Den Bestell-Service via Domänen-Event über Löschung des Kunden informieren 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. Orders of Customer 123 Idee: Den Bestell-Service via Domänen-Event über Löschung des Kunden informieren Customer 123 Integrity in sync* Customer MQ *eventual integrity
- 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: Kunde als gelöscht markieren und APIs bei Bedarf adaptieren
- 75. #WISSENTEILEN Cust Orders Orders Customer Idee #2: Kunde als gelöscht markieren und APIs bei Bedarf adaptieren 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: Kunde als gelöscht markieren und APIs bei Bedarf adaptieren 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: Kunde als gelöscht markieren und APIs bei Bedarf adaptieren 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 A B TX Konsistenz von Daten über Servicegrenzen hinweg
- 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 Verteilte Transaktionen via SAGAs SAGA Idee: Abbilden einer verteilten fachlichen Transaktion durch eine Abfolge lokaler technischer Transitionen / Transaktionen
- 113. #WISSENTEILEN Verteilte Transaktionen via SAGAs order = PENDING item = PENDING TX 1 TX 2 TX 3 TX 4 TX 5 TX 6 APPROVED APPROVED
- 114. #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
- 115. #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
- 116. #WISSENTEILEN Konsistenz von Daten und Nachrichten
- 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 Was ihr mitnehmen solltet. Cool, verstanden. Und wo finde ich mehr dazu?
- 125. #WISSENTEILEN „Es kann nur eine gültige Quelle für eine bestimmte Entität geben.“
- 127. #WISSENTEILEN „Verwende Eventual Consistency wann immer fachlich möglich.“
- 128. #WISSENTEILEN „Denke in fachlichen statt in technischen Transaktionen.“
- 130. #WISSENTEILEN #WISSENTEILEN Vielen Dank! #WISSENTEILEN by open knowledge GmbH @_openKnowledge | @mobileLarson Lars Röwekamp, CIO New Technologies
- 131. #WISSENTEILEN #WISSENTEILEN BILDNACHWEIS Folie 01: © Merena, iStockphoto.com Folie 20: © Photoplotnikov, iStockphoto.com All other pictures, drawings and icons originate from • pexels.com, • pixabay.com, • unsplash.com, • flaticon.com or were made by my own.
- 133. #WISSENTEILEN Anforderung: Ergebnis der Suche eines (ggf anonymen) Nutzers anzeigen
- 135. #WISSENTEILEN Search Ausgangssituation: Ein Search-Service liefert Suchergebnisse RESTfull • Resources via URI • State Transfer via http Methods • Headers, Caches, Status-Codes …
- 136. #WISSENTEILEN Search https://ok-shop.de/search?query= … Ausgangssituation: Ein Search-Service liefert Suchergebnisse
- 137. #WISSENTEILEN Search ok 200 [ … „list of products“ … ] Ausgangssituation: Ein Search-Service liefert Suchergebnisse
- 138. #WISSENTEILEN Search no content 204 [ ] Ausgangssituation: Ein Search-Service liefert Suchergebnisse
- 139. #WISSENTEILEN Search Super Search ? Herausforderung: Der aktuelle Search-Service soll um einen zweiten SuperSearch-Service ergänzt werden.
- 140. #WISSENTEILEN Search Super Search search?query= … supersearch?query= … Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ btw: starre Kopplung Idee: zwei Search-Services
- 141. #WISSENTEILEN Simple Search Super Search simplesearch?query= … supersearch?query= … Search API search?query= … Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ btw: starre Kopplung Idee #2: zwei Search-Services plus API Composition
- 142. #WISSENTEILEN Simple Search Super Search search?query= … Search API Aggregation der Ergebnisse Koordination der Aufrufe Resilience im “Fall des Falles“ Search MQ Result MQ Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 143. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ User gibt einen Suchbegriff ein … Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 144. #WISSENTEILEN Simple Search Super Search search?query= … Search API Search MQ Result MQ Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 145. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Search“ Msg Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 146. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 147. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Simple Search“ Result Msg Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 148. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Super Search“ Result Msg Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 149. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 150. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ ok 200 [ … „merged list of products“ … ] Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 151. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Idee #3: zwei Search-Services plus API Composition plus Entkoppelung
- 152. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Idee #3: zwei Search-Services plus API Composition plus Entkoppelung TIMEOUT
- 153. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ ok 200 [ … „list of products“ of SIMPLE SEARCH only ] Idee #3: zwei Search-Services plus API Composition plus Entkoppelung