Systeme modernisieren mit Microservices, Hystrix und RxJava

Slide 1

Slide 1 text

Wir lösen das – persönlich! Systeme modernisieren mit Microservices, Hystrix und RxJava Holger Kraus, Arne Landwehr Javaland, Brühl 24.03.2015 !

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

© 2011 innoQ Deutschland GmbH Naive Implementierung public List findExternalProducts(String type) { ClientResponse clientResponse = Client.create() .resource("http://merchant1/products/") .queryParam("type", type.toString()) .get(ClientResponse.class); return toProducts(clientResponse); } !

Slide 18

Slide 18 text

© 2011 innoQ Deutschland GmbH Einfacher Command public class GetProductsFromMerchant1 extends HystrixCommand> { ! GetProductsFromMerchant1() { super(HystrixCommandGroupKey.Factory.asKey("merchant1")); } ! @Override protected List run() throws Exception { return findExternalProducts(type); } }

Slide 19

Slide 19 text

© 2011 innoQ Deutschland GmbH Fallbacks @Override protected List getFallback(){ return Collections.emptyList(); } ! // oder mit Cache ! @Override protected List getFallback(){ return Cache.get(type); } ! // oder geschachtelt ! @Override protected List getFallback(){ return new FallbackCommand.execute(); }

Slide 20

Slide 20 text

© 2011 innoQ Deutschland GmbH Parallele Abfrage public Iterable search(String type) { HystrixCommand com1 = new GetProductsFromMerchant1(type); HystrixCommand com2 = new GetProductsFromMerchant2(type); Future fut1 = com1.queue(); Future fut2 = com2.queue(); try { List products1 = fut1.get(); List products2 = fut2.get(); return CollectionUtils.union(products1, products2); } catch (InterruptedException | ExecutionException e) { logger.error("unexpected exception", e); return Collections.emptyList(); } }

Slide 21

Slide 21 text

© 2011 innoQ Deutschland GmbH Geht besser mit RxJava! ‣ „Reactive Extensions for the JVM „ ‣ arbeiten mit asynchronen Streams ‣ Observable als Abstraktion ‣ Java 8 ready ‣ Polyglot (Scala, Groovy, Clojure and Kotlin)

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

© 2011 innoQ Deutschland GmbH Hystrix + RxJava HystrixCommand com1 = new GetProductsFromMerchant1(type); HystrixCommand com2 = new GetProductsFromMerchant2(type); ! Observable>obs1 = com1.observe(); Observable>obs2 = com2.observe(); ! CollectioncombinedResult = Observable .zip(obs1,obs2,CollectionUtils::union) .toBlocking() .first();

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© 2011 innoQ Deutschland GmbH Typische Probleme mit Monolithen ‣ Hoher Aufwand bei kleinen Änderungen ‣ Technische Modernisierung schwierig ‣ Releases sind riskant und selten ‣ Skalierung nur sehr ungenau

Slide 28

Slide 28 text

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© 2011 innoQ Deutschland GmbH Systemeigenschaften ‣ Eigene Benutzeroberfläche ‣ Eigene Datenhaltung ‣ Eigene interne, unabhängige Logik ‣ Klar definierte Schnittstellen ‣ Separates Deployment ‣ Separater Betrieb möglich

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

© 2011 innoQ Deutschland GmbH Domänenarchitektur ‣ der Systemschnitt bildet fachlichen Domänen ab ‣ definiert wer für welche Daten verantwortlich ist ‣ verfolgt die Ziele ‣ lose Kopplung ‣ hohe Kohäsion

Slide 40

Slide 40 text

© 2011 innoQ Deutschland GmbH Bounded Context ‣ Monolith verfügt schon über viele Modelle ‣ diese gelten in spezifischen Kontexten ‣ und verfügen über eigene Prozesse ‣ oft nur implizit vorhanden, nicht deckungsgleich mit Modulgrenzen

Slide 41

Slide 41 text

© 2011 innoQ Deutschland GmbH Ausgangspunkt Monolith ‣ Bounded Contexts identifizieren ‣ Grenzen explizit definieren ‣ Grundlage für Domänenarchitektur ‣ Erfahrung mit dem Monolithen hilft Systemschnitt zu entwickeln

Slide 42

Slide 42 text

Slide 43

Slide 43 text

© 2011 innoQ Deutschland GmbH Makroarchitektur ‣ legt systemübergreifende Standards fest ‣ UI-Integration ‣ Kommunikationsprotokolle ‣ Repräsentationsformate ‣ Umgang mit Datenredundanz ‣ Logging, Monitoring, Security

Slide 44

Slide 44 text

Slide 45

Slide 45 text

© 2011 innoQ Deutschland GmbH Konsequenzen ‣ Transaktionskontext nur innerhalb des jeweiligen Systems ‣ Kommunikation zwischen Systemen meist asynchron ‣ Systemübergreifende Transaktionen sind deuten auf optimierteren Systemschnitt hin

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

Slide 49

Slide 49 text

© 2011 innoQ Deutschland GmbH Evolutionäres Vorgehen ‣ Neue Funktionalität daneben stellen, keine Integration in den Monolithen mehr ‣ Bestehende Bounded Contexts in eigenständigeSysteme transformieren ‣ Bestehender Code als Grundlage ‣ Einzelne Systeme neu entwickeln

Slide 50

Slide 50 text

© 2011 innoQ Deutschland GmbH Evolutionäres Vorgehen ‣ Monolith schmilzt langsam ‣ Einzelne Systeme werden schneller produktiv ‣ Direktes Feedback aus der Produktion ‣ Weniger risikoreich ‣ mehr Kompromisse notwendig

Slide 51

Slide 51 text

Slide 52

Slide 52 text

Slide 53

Slide 53 text

Slide 54

Slide 54 text

Slide 55

Slide 55 text

© 2011 innoQ Deutschland GmbH Erfahrungen ‣ Wenn alle für alles zuständig sind, entsteht auf Dauer wieder ein Monolith. ‣ Kleine Teams bilden, die jeweils für ein System verantwortlich sind ‣ Regelmäßiger Austausch über systemübergreifende Themen ist wichtig

Slide 56

Slide 56 text

Slide 57

Slide 57 text

© 2011 innoQ Deutschland GmbH Links ‣ http://martinfowler.com/articles/microservices.html ‣ http://www.infoq.com/presentations/Breaking-the-Monolith ‣ https://github.com/Netflix/Hystrix ‣ https://github.com/ReactiveX/RxJava

Slide 58

Slide 58 text