Schöne neue reaktive Welt

Bei idealo haben wir in einem Zeitraum von über 15 Jahren eine Preisvergleichsplattform geschaffen. Aus dem Startup wurde ein schnell wachsendes Unternehmen, mehr Teams, mehr Entwickler, mehr Fachlichkeit. Die monolitischen Systeme, die im Hintergrund ihre Arbeit verrichteten, waren nicht mehr in der Lage, den äusseren Faktoren gerecht zu werden: Es musste etwas passieren.

Nach einer Reorganisation der Entwicklungs- und Produktabteilung standen wir als neues Entwicklerteam Anfang 2017 vor der Herausforderung, unsere Fachlichkeit aus den Monolithen herauszulösen.

Der Vortrag beleuchtet unseren bisherigen Weg und wie wir mit den Technologien Spring Framework, RxJava, MongoDB, Vert.x und Hazelcast eine stabiles und skalierbares System entwickelt haben.

Und wir wagen einen Blick in die Zukunft einer schönen neuen reaktiven Welt.

Transcript

1. »Mit allen einschlägigen Daten«, fügte der Direktor hinzu. »Jeden Morgen aktualisiert.« »Und nachmittags korreliert.« »Die Basis der Kalkulationen.« »Soundso viele Einzelwesen der verlangten Qualität«, sagte Mr Foster. »In der und der Stückmenge geliefert.« »Fortlaufend optimierte Dekantier-Rate.« »Unverzüglicher Ausgleich aller Ausfälle.« »Unverzüglich«, wiederholte Mr Foster. Aldous Huxley - Schöne neue Welt
2. Schöne neue reaktive Welt Wie wir zu einem eventbasierten Ansatz kamen und was wir lernen mussten Jan Guntowski & Daniel Hübner
3. Agenda I. Begriffsdefinitionen zum Warmwerden II. Hintergrund: Monolith & Organisationsstrukturen III. System Design & API Integration IV. Schöne neue reaktive Welt
4. Begriffsdefinitionen zum Warmwerden
5. idealo
6. Reactive Programming “Reactive Programming ist ein Programmierparadigma, bei dem auf Ereignisse oder die Änderungen von Daten reagiert wird. Dazu werden Ereignisse oder Daten dem Empfänger übermittelt, anstatt von ihm abgefragt zu werden.” Nurkiewicz / Christensen, Reactive Programming in RxJava
7. Conway’s Law “Organisationen, die Systeme entwerfen, […] sind auf Entwürfe festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden.” M. Conway
8. Weitere Begriffe Request / Response Kommunikation • Blockierend • Synchron • Beispiele: REST, JDBC Eventbasierte Kommunikation • Nicht blockierend • Asynchron • Beispiele: vert.x, Apache Kafka Command Query Responsibility Segregation (CQRS) Pattern • Command = Fachereignis ◦ “neues Produkt angelegt” + Payload (Produktdaten) ◦ “neues Angebot für Produkt” + Payload (Angebotsdaten) • Query = Benutzeranfrage ◦ “Zeige die Produktseite vom iPhone X an” • Verbindung über eine Datenhaltung (materialized view)
9. Hintergrund: Monolith & Organisationsstrukturen Woher kommen wir?
10. 2017 2018 2019..? 2016 Alte, gegenwärtige und schöne neue Welt
11. Ausgangssituation zum Projektstart Monolith blabla X blabla X Backlog: Backlog: Backlog:
12. System Design & API Integration Verantwortung für Fachlichkeit übernehmen
13. Unsere Herausforderung: Fachlogik extrahieren: • Konsumieren verschiedener Datenquellen • Berechnen abgeleiteter Informationen • Aktualität gewährleisten Integration ins Frontend: • Ausliefern durch Microservice • Viele parallele Requests (~6K/s) • Bulkrequest nicht praktikabel für Client • Kein Blockieren des Clients während der Requests Calculator API Service
14. Lösung: Reaktives System mit Eventloop • Auslieferung mit einem Thread pro Request nicht geeignet • Parallele Verarbeitung von Requests in einem Thread? • Nicht blockierende Verarbeitung im API Service und im Client • Zugriffe auf externe Systeme nicht blockierend • Request / Response als Events in einem reaktiven System
15. Nicht blockierendes Ausliefern mit vert.x Verticle Reaktiver Treiber Query & Callback Request Event Response Event API Client Eventbus Monolith API Service
16. Überblick Gesamtsystem Feeder Queue Calculator DS1 DS2 DS3 DS4 API Service Client API API reaktive Welt synchrone Welt
17. DataSource im Detail Calculator ReadVerticle query CreateVerticle ScheduledUpdater External API insert update create read
18. Vert.x Integration in Spring Boot Technische Herausforderungen: • Integration in den idealo Spring Boot - Stack ◦ Nutzung vorhandener Lösungen für Deployment und Monitoring • Konfiguration und Starten des Clusters ◦ Einbettung des asynchronen Startvorgangs von vert.x • Integration von Verticles in den Spring Bean - Lifecycle ◦ Verwendung von Dependency Injection in Verticles ◦ Deklarative Erzeugung von Verticles • Einfache Einbindung im Client ◦ Schnittstelle zu anderen Teams Lösungsansatz: Shared Libraries
19. Codebeispiel: Service @Verticle(address=”my-eventbus-address”) public class MyVerticle extends CommonRxVerticle<RequestEvent> { private final ReactiveRepo reactiveRepo; ... @Override public void handleMessage(Message<RequestEvent> message) reactiveRepo.find(message.body()) .onErrorReturn( FALLBACK) .defaultIfEmpty( FALLBACK) .subscribe( message::reply); } } @Value public class RequestEvent { Long identifier; String field; } @Value public class ResponseEvent { String field1; Long field2; }
20. Codebeispiel: Client @Component @Getter public class ApiSendOptions implements VertxEventSenderOptions { @Value("${vertx.timeout:100}") private long timeout; @Value("${vertx.event.address") private String address; } @Component public class ApiClientService { private final VertxEventSender sender; private final ApiSendOptions options; ... public Observable<ResponseEvent> sendEvent( RequestEvent event) { return sender .send(event, options) .onErrorReturn(throwable -> CLIENT_FALLBACK) } }
21. Shared Libraries: Dependencies vertx-commons Eventbus Serialisierung vertx-client Resilienz Eventsender Monitoring vertx-node Verticles Betriebsmodi Monitoring Resilienz api-model Fachobjekte API Service API Implementierung Frontend API Konsument depends on
22. Learnings: DRY und SOLID • Shared Dependency “api-model” ◦ Fachobjekte nicht dupliziert und... ◦ ...Serialisierung / Deserialisierung zentralisiert,... ◦ ...aber Kopplung zwischen Clients und Service • DRY - Prinzip missverstanden ◦ Wichtig für Fachlogik,… ◦ ...aber nicht für Transportobjekte • Das D in SOLID (Dependency Inversion Principle) ◦ “High level policy should not depend on low level details” ◦ vertx-commons implementiert Infrastruktur - Details auf tiefster Ebene ◦ Änderungen führen zu neuen Releases sämtlicher Artefakte
23. Überblick Gesamtsystem Feeder Queue Calculator DS1 DS2 DS3 DS4 API Service Client API API reaktive Welt synchrone Welt
24. Backpressure mit vert.x Pump ReadStream Reaktives Lesen WriteStream -credits Eventbus ReadStream Event, credits-- credits++ Pump WriteStream Reaktives Schreiben Upstream Downstream
25. Fazit Calculator • Single Responsibility der beteiligten Applikationen... • … aber Kopplung Calculator / API Service über die Datenbank • Verarbeitung erinnert an CQRS ◦ Command => Ergebnisse des Calculators ◦ Query => Abfrage des API Service ◦ Materialized View => Datenbank • Resilienz ◦ Backpressure (das System passt seine Geschwindigkeit an) ◦ Entkopplung externer Systeme
26. Schöne neue reaktive Welt Status Quo und Ausblick
27. Schöne neue reaktive Welt? Web Web
28. CQRS: Schöne neue reaktive Welt! SEO Service Produktservice Preisservice Command Model Query Model aka Web Tier Materialized View Neues Produkt Neuer Preis Neuer SEO Status
29. Team Mindset
30. Danke für Eure Aufmerksamkeit
31. Noch Fragen ? »Mit allen einschlägigen Daten«, fügte der Direktor hinzu. »Jeden Morgen aktualisiert.« »Und nachmittags korreliert.« »Die Basis der Kalkulationen.« »Soundso viele Einzelwesen der verlangten Qualität«, sagte Mr Foster. »In der und der Stückmenge geliefert.« »Fortlaufend optimierte Dekantier-Rate.« »Unverzüglicher Ausgleich aller Ausfälle.« »Unverzüglich«, wiederholte Mr Foster. Aldous Huxley - Schöne neue Welt
32. CANVAS