Hands-On Microservices mit Java
•
1 gefällt mir•317 views
Eine Anwendung basierend auf Microservices mit Java zu entwickeln kann ja so schwer nicht sein. Schließlich gibt es Frameworks wie Spring Boot oder MicroProfile, die dem Entwickler das technologische Rahmengerüst vorgeben. Nur leider ist es damit nicht getan. Wie zum Beispiel sieht der optimale Service-Schnitt aus? Wie kommunizieren die Services untereinander, ohne dabei ihre Unabhängigkeit zu verlieren? Wie soll die Anwendung reagieren, wenn mal ein Service nicht so kann, wie er soll? Und wie bindet man seine Microservices an bestehende Infrastruktur wie Distributed Tracing, Monitoring oder Identity Provider an? Was sich in der Theorie einfach anhört, bringt in der Praixis so manchen Stolperstein mit sich. Im Rahmen des Workshops werden wir daher gemeinsam eine kleine, auf Microservices basierende Anwendung bauen und zum „Fliegen“ bringen. Angefangen bei der Diskussion über den optimalen Service-Schnitt via Domain-driven Design, über die Integration der Services untereinander via unterschiedlicher Kommunikationspatterns inkl. eingebauter Fehlertoleranz bis hin zur Instrumentalisierung der Services zwecks Laufzeitanalyse und -optimierung, lassen wir dabei kaum ein Thema aus. Am Ende steht eine Anwendung, die live gehen könnte – naja, fast.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie Hands-On Microservices mit Java
Ähnlich wie Hands-On Microservices mit Java (20)
Mehr von OPEN KNOWLEDGE GmbH
Mehr von OPEN KNOWLEDGE GmbH (20)
Hands-On Microservices mit Java
- 1. #WISSENTEILEN Hands-On Microservices Arne Limburg & Lars Röwekamp @arneLimburg | @mobileLarson | @_openknowledge
- 2. #WISSENTEILEN Was genau ist eigentlich ein guter Microservice?
- 3. #WISSENTEILEN Functional Decompensation Single Responsibility Principle Share nothing* Consumer Contracts (a.k.a. Interfaces) Lightweight Communication Independently develop, test, deploy, run Heterogeneous (a.k.a. Polyglot) *share as little as possible
- 10. #WISSENTEILEN „If every service has to be updated at the same time it’s not loosely coupled.“ Adiran Cockcroft
- 11. #WISSENTEILEN „If you have to know to much about surrounding services you don‘t have a bounded context.“ Adiran Cockcroft
- 13. #WISSENTEILEN „Loosely coupled service oriented architecture with bounded contexts.“ Adiran Cockcroft
- 14. #WISSENTEILEN Bounded Context? • Klare Grenzen • Business-Prozesse • Inkonsistenzen vermeiden • e.g. „check out“ • e.g. „search products“ • e.g. „my recommendations“
- 16. #WISSENTEILEN Aufteilen nach Bounded Contexts Service Design Was ist mit gemeinsam benutzen Objekten?
- 17. #WISSENTEILEN Aufteilen nach Bounded Contexts Service Design Sind die Objekte wirklich identisch oder heißen sie nur (zufällig) gleich?
- 18. #WISSENTEILEN Aufteilen nach Bounded Contexts Service Design Auch syntaktisch identische Objekte können zu unterschiedlichen Services gehören
- 20. #WISSENTEILEN Service Design Herausforderung: Daten konsistent • einen Data-Owner definieren • schreibend nur via Data-Owner
- 22. #WISSENTEILEN
- 24. #WISSENTEILEN Wie kommunizieren Services untereinander?
- 25. #WISSENTEILEN
- 27. #WISSENTEILEN Search Idee: Ein Search-Service liefert Suchergebnisse RESTfull • Resources via URI • State Transfer via http Methods • Headers, Caches, Status-Codes …
- 29. #WISSENTEILEN Search ok 200 [ … „list of products“ … ] Idee: Ein Search-Service
- 30. #WISSENTEILEN Search no content 204 [ ] Idee: Ein Search-Service
- 31. #WISSENTEILEN Search Super Search ? Herausforderung: Der aktuelle Search-Service soll um einen zweiten SuperSearch-Service ergänzt werden.
- 32. #WISSENTEILEN Search Super Search search?query= … supersearch?query= … Koordination der Aufrufe Aggregation der Ergebnisse Resilience im “Fall des Falles“ btw: starre Kopplung Neue Idee: zwei Search-Services
- 33. #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 Neue Idee: zwei Search-Services
- 34. #WISSENTEILEN Simple Search Super Search search?query= … Search API Aggregation der Ergebnisse Koordination der Aufrufe Resilience im “Fall des Falles“Search MQ Result MQ Neue Idee: zwei Search-Services
- 35. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ User gibt Suchbegriff ein … Neue Idee: zwei Search-Services
- 36. #WISSENTEILEN Simple Search Super Search search?query= … Search API Search MQ Result MQ Neue Idee: zwei Search-Services
- 37. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Search“ Msg Neue Idee: zwei Search-Services
- 38. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Neue Idee: zwei Search-Services
- 39. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Simple Search“ Result Msg Neue Idee: zwei Search-Services
- 40. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ „Super Search“ Result Msg Neue Idee: zwei Search-Services
- 41. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ Neue Idee: zwei Search-Services
- 42. #WISSENTEILEN Simple Search Super Search Search API Search MQ Result MQ ok 200 [ … „merged list of products“ … ] Neue Idee: zwei Search-Services
- 45. #WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 àLiefert Adresse { street: { "name": "Poststraße", "number": "1", }, "city": "26122 Oldenburg" }
- 46. #WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 Attribut hinzufügen { street: { "name": "Poststraße", "number": "1", "additionalAdressLine": "2. Obergeschoss" }, "city": "26122 Oldenburg" }
- 47. #WISSENTEILEN http://www.example.com/addresses/42 Client erwartet { street: { "name": "Poststraße", "number": "1", }... } TOLERANT READER PATTERN Server schickt { street: { "name": "Poststraße", "number": "1", "additionalAdressLine": "2. Obergeschoss" }... }
- 48. #WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 Attribut-Umbenennung { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", }, "city": "26122 Oldenburg" }
- 49. #WISSENTEILEN TOLERANT READER PATTERN http://www.example.com/addresses/42 àAbwärtskompatible Änderungen: Umbenennen durch Kopieren { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", }, "city": "26122 Oldenburg" }
- 50. #WISSENTEILEN Photo by Irene Fertik, USC News Service. Copyright 1994, USC. „Be conservative in what you do, Be liberal in what you accept from others“ RFC 793, Robustness Principal (John Postel)
- 51. #WISSENTEILEN Es darf nichts entfernt werden Keine Veränderung von Verarbeitungsregel Optionales darf nie Required werden http://zalando.github.io/restful-api-guidelines Alles was hinzugefügt wird, muss optional sein
- 52. #WISSENTEILEN http://www.example.com/addresses/42 Client erwartet { street: { "name": "Poststraße", "number": "1", }... } MAGNANIMOUS WRITER PATTERN Server schickt { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html
- 53. #WISSENTEILEN http://www.example.com/addresses/42 Client erwartet { street: { "streetName": "Poststraße", "houseNumber": "1", }... } MAGNANIMOUS WRITER PATTERN Server schickt { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html
- 54. #WISSENTEILEN PUT http://www.example.com/addresses/42 Client schickt { street: { "name": "Poststraße", "number": "1", }... } MAGNANIMOUS WRITER PATTERN Server erwartet http://tenderware.blogspot.de/2011/05/magnanimous-writer.html
- 55. #WISSENTEILEN MAGNANIMOUS WRITER PATTERN PUT http://www.example.com/addresses/42 Client schickt { street: { "name": "Poststraße", "number": "1", }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html Server erwartet { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } oder oder
- 56. #WISSENTEILEN MAGNANIMOUS WRITER PATTERN PUT http://www.example.com/addresses/42 Client schickt { street: { "streetName": "Poststraße", "houseNumber": "1", }... } http://tenderware.blogspot.de/2011/05/magnanimous-writer.html Server erwartet { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1“ }... } oder oder
- 57. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àAbwärtskompatible Änderungen: Umbenennen durch Kopieren { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", }, "city": "26122 Oldenburg" } Geht da noch mehr?
- 58. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àZusammenführen und Teilen von Attributen { street: { ... "streetName": "Poststraße", "houseNumber": "1", "addressLine1": "Poststraße 1", } ... }
- 59. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Zusammenführen von Attributen { street: { ... "streetName": "Poststraße", "houseNumber": "1", "addressLine1": "Poststraße 1", } ... }
- 60. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Teilen von Attributen { street: { ... "addressLine1": "Poststraße 1", } "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg" }
- 61. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Ebene von Attributen ändern { street: { ... "addressLine1": "Poststraße 1" } "addressLine1": "Poststraße 1", ... }
- 62. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Ebene von Attributen ändern { ... "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } }
- 63. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT http://www.example.com/addresses/42 àHerausforderungen: Ebene von Attributen ändern { ... "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } Bei jeder Modelländerung muss eine Migrationsstrategie einbezogen werden!
- 65. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", "addressLine1": "Post... 1", "addressLine2": "" } "addressLine1": "Poststraße 1", "addressLine2": "", "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } http://www.example.com/v1/addresses/42 àBisher nur abwärtskompatible Änderungen
- 66. #WISSENTEILEN ABWÄRTSKOMPATIBILITÄT { street: { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", "addressLine1": "Post... 1", "addressLine2": "" } "addressLine1": "Poststraße 1", "addressLine2": "", "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } http://www.example.com/v1/addresses/42 àViele Attribute deprecated
- 67. #WISSENTEILEN WEITERENTWICKLUNG { "street": { "name": "Poststraße", "streetName": "Poststraße", "number": "1", "houseNumber": "1", "addressLine1": "Post... 1", "addressLine2": "" }, "addressLine1": "Poststraße 1", "addressLine2": "", "city": "26122 Oldenburg", "zipCode": "26122", "cityName": "Oldenburg", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } Schnittstelle Schnittstelle { "addressLine1": "Poststraße 1", "addressLine2": "", "location": { "zipCode": "26122", "cityName": "Oldenburg" } } V1 V2-SNAPSHOT
- 69. #WISSENTEILEN
- 70. #WISSENTEILEN Checkout Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders
- 71. #WISSENTEILEN Checkout Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Orders Herausforderung: Wie kommen die notwendigen Daten zum Checkout-Service?
- 72. #WISSENTEILEN Checkout Idee: 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
- 73. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Herausforderung: Aber was ist, wenn die bevorzugte Lieferadresse bzw. Zahlungsmethode nicht zur Anwendung kommen soll?
- 74. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Alternative Adresse: … im „Ausnahmefall“ wird der Address-Service zur Auswahl einer anderen Adresse heran- gezogen.
- 75. #WISSENTEILEN Checkout Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. POST https://ok-shop.de/orders Orders Preferred Delivery Address Preferred Payment Method
- 76. #WISSENTEILEN Checkout Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. 201 created Location: …/orders/1234 Orders Preferred Delivery Address Preferred Payment Method
- 77. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address
- 78. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address GET …/addresses (list all addresses)
- 79. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 200 ok [ „list of addresses“ ]
- 80. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address PUT …/addresses/123 (change pref. delivery address)
- 81. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 204 no content [ ]
- 82. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 83. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 84. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 85. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 86. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 87. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preffered Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Herausforderung: Was ist, wenn eine neue Adresse verwendet werden soll?
- 88. #WISSENTEILEN Checkout Orders Preferred Delivery Address Preferred Payment Method Idee: Der gesamte Bestellvorgang kann im „Normalfall“ mit Hilfe des Checkout-Service abgehandelt werden. Neue Adresse anlegen: … neue Adressen werden über den Address-Service angelegt und im Anschluss repliziert.
- 89. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address POST …/addresses/ (add new pref. delivery address)
- 90. #WISSENTEILEN Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service. Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 201 created Location ...
- 91. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 92. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 93. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 94. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ pref. delivery address changed Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 95. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Address MQ Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service.
- 96. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Herausforderung: Und was ist, wenn der Address-Service nicht verfügbar ist?
- 97. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Fachlicher Workaround : z.B. durch Setzen der Adresse nur für die aktuelle Bestellung via UI.
- 98. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address POST …/orders/ (with typed in address) Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Fachlicher Workaround : z.B. durch Setzen der Adresse nur für die aktuelle Bestellung via UI.
- 99. #WISSENTEILEN Address Checkout Orders Preferred Delivery Address Preferred Payment Method Addresses Preferred Delivery Address 201 created Location … Idee: Im „Normalfall“ nur der Checkout-Service. Im „Ausnahmefall“ zusätzlich der Address-Service Fachlicher Workaround : z.B. durch Setzen der Adresse nur für die aktuelle Bestellung via UI.
- 102. #WISSENTEILEN
- 103. #WISSENTEILEN
- 104. #WISSENTEILEN
- 105. #WISSENTEILEN Product Idee: Ein Product-Service liefert zu empfehlende Produkte oder alternativ die Liste der Bestseller. Product nicht eingeloggt eingeloggt gutes Service Design: Ein Service hat genau eine fachlich Verantwortlichkeit und ein dazu passendes Domänen Modell
- 106. #WISSENTEILEN Neue Idee: Wenn nicht eingeloggt, liefert ein Bestseller-Service die Liste der Top-10. Wenn eingeloggt, liefert ein Recommendation-Service zu empfehlende Produkte. Bestseller Recomm nicht eingeloggt eingeloggt
- 107. #WISSENTEILEN Herausforderungen: Wer stellt fest, ob eingeloggt oder nicht (UI vs. Services)? Wie kommen die Login- Informationen zum Recommendation-Service? Wie werden „Session“ Info verteilt, wenn mehrere Services in einen Call involviert sind (Context Propagation)? Bestseller Recomm nicht eingeloggt eingeloggt
- 108. #WISSENTEILEN Exkurs: Sicher ist sicher! Sicher? • Server based Security via Session auf dem Server • Token based Security via Austausch von Token
- 111. #WISSENTEILEN Exkurs: Sicher ist sicher! Sicher? JWT (JSON Web Token) • neue, einfache und kompakte Specs • Token plus public & private „Claims“ • digitale Signatur und/oder Encryption • als Bearer Token und für SSO
- 112. #WISSENTEILEN
- 113. #WISSENTEILEN Herausforderungen: Wer stellt fest, ob eingeloggt oder nicht (UI vs. Services)? Wie kommen die Login- Informationen zum Recommendation-Service? Wie werden „Session“ Info verteilt, wenn mehrere Services in einen Call involviert sind (Context Propagation)? Bestseller Recomm nicht eingeloggt eingeloggt
- 114. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API
- 115. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Eingeloggt? Nein. Recommendations?
- 116. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Bestseller
- 117. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider login
- 118. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider ok & Token
- 119. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider Recommendations? Eingeloggt? Ja.
- 120. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider User? Role?
- 121. #WISSENTEILEN Bestseller Recomm Neue Idee: Zwei Services plus API-Service als Weiche. Recomm API Auth Provider Recommendations für User
- 124. #WISSENTEILEN
- 125. #WISSENTEILEN Search Idee: Bei einer Suche durch den Search-Service wird neben den Treffern auch deren Verfügbarkeit angezeigt. gutes Service Design: Ein Service hat genau eine fachlich Verantwortlichkeit und ein dazu passendes Domänen Modell
- 126. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Bei einer Suche wird neben den Treffern auch deren Verfügbarkeit angezeigt. Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit.
- 127. #WISSENTEILEN
- 128. #WISSENTEILEN
- 129. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Herausforderung: Performance ist deutlich schlechter als erwartet! Wo liegt das Problem? Und was ist eigentlich „passiert“?
- 130. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 131. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 132. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 133. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 134. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 135. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 136. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 137. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 138. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Tracing: Unique Trace ID wird als „Klammer“ erzeugt und durch den gesamten Aufruf geschleust. id
- 139. #WISSENTEILEN
- 140. #WISSENTEILEN
- 142. #WISSENTEILEN
- 143. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Herausforderung: Service liefert nicht das erwartete Ergebnis. Wo genau liegt das Problem? Und was ist eigentlich im Detail passiert?
- 144. #WISSENTEILEN Search Inventory Search API Koordination der Aufrufe Aggregation der Ergebnisse Neue Idee: Ein Search-Service liefert die Suchergebnisse. Ein Inventory-Service liefert die Verfügbarkeit. Distributed Logging: Die Logs der einzelnen Services werden in einem „Topf“ aggregiert und ausgewertet.
- 145. #WISSENTEILEN
- 146. #WISSENTEILEN
- 149. #WISSENTEILEN
- 150. #WISSENTEILEN Recomm Idee: Ein Recomm*-Service liefert zu empfehlende Produkte. *PPT-kompatible Version von „Recommendations-Service“
- 151. #WISSENTEILEN Recomm Idee: Ein Recomm*-Service liefert zu empfehlende Produkte. *PPT-kompatible Version von „Recommendations-Service“ Herausforderung: Aber was ist, wenn der Recomm-Service einmal ausfällt?
- 152. #WISSENTEILEN
- 153. #WISSENTEILEN
- 154. #WISSENTEILEN
- 155. #WISSENTEILEN Recomm Idee: Ein Recomm-Service liefert zu empfehlende Produkte. Bestseller Resilience: Im Falles eines Ausfalls wird auf einen Bestseller-Service ausgewichen.
- 156. #WISSENTEILEN Bestseller Recomm Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback. Recomm API
- 157. #WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Ja. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback. Recommendations?
- 158. #WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Ja. Recommendations für User X? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 159. #WISSENTEILEN Bestseller Personal Recomm API Recommendations für User X Eingeloggt? Ja. „Personal“ verfügbar? Ja. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 160. #WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback. Recommendations?
- 161. #WISSENTEILEN Bestseller Personal Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. Bestseller? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 162. #WISSENTEILEN Bestseller Personal Recomm API Bestseller Eingeloggt? Ja. „Personal“ verfügbar? Nein. Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 163. #WISSENTEILEN Bestseller Recomm Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. „Bestseller“verfügbar? Nein. Recommendations? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 164. #WISSENTEILEN
- 165. #WISSENTEILEN
- 166. #WISSENTEILEN Bestseller Recomm Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. „Bestseller“verfügbar? Nein. Recommendations? Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 167. #WISSENTEILEN Bestseller Recomm Recomm API Eingeloggt? Ja. „Personal“ verfügbar? Nein. „Bestseller“verfügbar? Nein. Static Content Idee: Recomm-Service als primäre Option. Bestseller-Service als Fallback.
- 170. #WISSENTEILEN Ein Microservice kommt selten allein!
- 174. #WISSENTEILEN Arne Limburg, @arneLimburg Lars Röwekamp, @mobileLarson Kontakt: lars.roewekamp@openknowledge.de arne.limburg@openknowledge.de kontakt@openknowledge.de Besten Dank! #WISSENTEILEN