Systeme modernisieren mit Microservices, Hystrix und RxJava

Die Vortrag wurde auf der Javaland-Konferenz 2015 gehalten: http://www.javaland.eu/javaland-2015/

Als Softwareentwickler ist man nur sehr selten in der Situation, ein völlig neues System auf der Basis neuester Technologien entwickeln zu dürfen. Oft sollen bestehende Systeme nur um viele kleinere Features erweitert werden. Die Renovierung der grundlegenden Systemarchitektur und die Einführung neuer Programmierparadigmen ist in diesem Umfeld schwierig. Umso wichtiger ist es, dass man die Modernisierung von Altsystemen zu einem fortlaufenden Bestandteil auch des Feature-getriebenen Entwicklungsprozesses macht. In diesem Vortrag möchten wir zeigen wie auch größere, monolithische Altsysteme mithilfe der offenen Netflix-Bibliotheken schrittweise in Richtung einer Microservice-Achitektur weiterentwickelt werden können. Hystrix kann dabei einen wertvollen Beitrag zur Gesamtstabilität des entstehenden verteilten System leisten. Der Einsatz von RxJava ein gute Möglichkeit den Anteil von asynchronen Prozessen innerhalb der Legacy-Architektur zu erhöhen. Der Vortrag wird anhand von Beispielen demonstrieren, wie der hier angedeutete Modernisierungsprozess umgesetzt werden kann.

Transcript

1. Wir lösen das – persönlich! Systeme modernisieren mit Microservices, Hystrix und RxJava Holger Kraus, Arne Landwehr Javaland, Brühl 24.03.2015 !
2. © 2011 innoQ Deutschland GmbH Ein (typisches) System monozon inc.
3. © 2011 innoQ Deutschland GmbH Im Kontext
4. © 2011 innoQ Deutschland GmbH Im Detail
5. © 2011 innoQ Deutschland GmbH Akute Probleme ‣ kaum zu warten ‣ kaum zu erweitern ‣ instabil ‣ buggy ‣ frustrierend ‣ veraltet
6. © 2011 innoQ Deutschland GmbH Und nun? ‣ Arbeit einstellen? ‣ neues System bauen? ‣ stabilisieren? ‣ weiter machen? ‣ System zerlegen?
7. © 2011 innoQ Deutschland GmbH Stabilisieren !
8. © 2011 innoQ Deutschland GmbH Problem: Integrationspunkte
9. © 2011 innoQ Deutschland GmbH Cascading Failures https://www.flickr.com/photos/benstassen/2991003141/
10. © 2011 innoQ Deutschland GmbH Stabilitätspattern ‣ Timeouts ‣ Circuit Breaker ‣ Bulkheads ‣ Fail Fast ! … Steady State , Handshaking, Test Harness, Decoupling Middleware
11. © 2011 innoQ Deutschland GmbH Timeout https://www.flickr.com/photos/55293400@N07/15564061004
12. © 2011 innoQ Deutschland GmbH Bulkheads https://www.flickr.com/photos/10413717@N08/6935206524
13. © 2011 innoQ Deutschland GmbH In der Schifffahrt http://de.wikipedia.org/wiki/RMS_Titanic#/media/File:Titanic_Structure_de.svg
14. © 2011 innoQ Deutschland GmbH In der IT ‣ Thread-Pools ‣ DB-Connection-Pools ‣ Instanzen ‣ Server ‣ Datacenter
15. © 2011 innoQ Deutschland GmbH Circuit Breaker https://www.flickr.com/photos/leafbug/409950515/
16. © 2011 innoQ Deutschland GmbH ‣ von Netflix ‣ Resilience Library ‣ Command Pattern ‣ Metriken ‣ Dashboard Hystrix
17. © 2011 innoQ Deutschland GmbH Naive Implementierung public List<Products> findExternalProducts(String type) { ClientResponse clientResponse = Client.create() .resource("http://merchant1/products/") .queryParam("type", type.toString()) .get(ClientResponse.class); return toProducts(clientResponse); } !
18. © 2011 innoQ Deutschland GmbH Einfacher Command public class GetProductsFromMerchant1 extends HystrixCommand<List<Products>> { ! GetProductsFromMerchant1() { super(HystrixCommandGroupKey.Factory.asKey("merchant1")); } ! @Override protected List<Products> run() throws Exception { return findExternalProducts(type); } }
19. © 2011 innoQ Deutschland GmbH Fallbacks @Override protected List<Products> getFallback(){ return Collections.emptyList(); } ! // oder mit Cache ! @Override protected List<Products> getFallback(){ return Cache.get(type); } ! // oder geschachtelt ! @Override protected List<Products> getFallback(){ return new FallbackCommand.execute(); }
20. © 2011 innoQ Deutschland GmbH Parallele Abfrage public Iterable<Products> search(String type) { HystrixCommand com1 = new GetProductsFromMerchant1(type); HystrixCommand com2 = new GetProductsFromMerchant2(type); Future fut1 = com1.queue(); Future fut2 = com2.queue(); try { List<Products> products1 = fut1.get(); List<Products> products2 = fut2.get(); return CollectionUtils.union(products1, products2); } catch (InterruptedException | ExecutionException e) { logger.error("unexpected exception", e); return Collections.emptyList(); } }
21. © 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)
22. © 2011 innoQ Deutschland GmbH Im Paket enthalten ‣ Hystrix intern mit Rx gebaut ‣ keine weitere Dependency ‣ „observe“ statt „queue“ ‣ oder „toObservable“ ! !
23. © 2011 innoQ Deutschland GmbH Ein Beispiel: zip http://rxmarbles.com/#zip
24. © 2011 innoQ Deutschland GmbH Hystrix + RxJava HystrixCommand com1 = new GetProductsFromMerchant1(type); HystrixCommand com2 = new GetProductsFromMerchant2(type); ! Observable<List<Products>>obs1 = com1.observe(); Observable<List<Products>>obs2 = com2.observe(); ! Collection<Products>combinedResult = Observable .zip(obs1,obs2,CollectionUtils::union) .toBlocking() .first();
25. © 2011 innoQ Deutschland GmbH Und nun? ‣ Anwendung stabilisiert ‣ wieder Luft zum Atmen ‣ weitere Systeme können integriert werden ! ‣ Entwicklung weiterhin zäh…
26. © 2011 innoQ Deutschland GmbH https://www.flickr.com/photos/donmaedi/116013352 monozon inc.
27. © 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
28. © 2011 innoQ Deutschland GmbH Woran liegt das? ‣ unklare Abhängigkeiten ‣ unscharfe Modulgrenzen ‣ verteilte fachliche Prozesse ‣ nur eine technische Plattform ‣ Alles hängt mit allem zusammen
29. © 2011 innoQ Deutschland GmbH Ziel ‣ Kleinere Einheiten schaffen, die ‣ man verstehen kann, ‣ beherrschbar sind, ‣ fachlich weiterentwickelt werden können ‣ und technologischen Wandel erlauben
30. © 2011 innoQ Deutschland GmbH Gebraucht wird ein klarer Schnitt! https://www.flickr.com/photos/taefit/8528632756
31. © 2011 innoQ Deutschland GmbH Horizontal
32. © 2011 innoQ Deutschland GmbH Vertikale Services, 1 UI
33. © 2011 innoQ Deutschland GmbH Vertikal
34. © 2011 innoQ Deutschland GmbH Systemeigenschaften ‣ Eigene Benutzeroberfläche ‣ Eigene Datenhaltung ‣ Eigene interne, unabhängige Logik ‣ Klar definierte Schnittstellen ‣ Separates Deployment ‣ Separater Betrieb möglich
35. © 2011 innoQ Deutschland GmbH Mikroarchitektur ‣ Autonome Entscheidung über ‣ Programmiersprache ‣ Frameworks ‣ Interne Module, Komponenten, ‣ Interne Abhängigkeiten ‣ Datenbanktechnologie
36. © 2011 innoQ Deutschland GmbH Was ist da eigentlich drin?
37. © 2011 innoQ Deutschland GmbH Fachlichkeit!
38. © 2011 innoQ Deutschland GmbH in unterschiedlicher Granularität
39. © 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
40. © 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
41. © 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
42. © 2011 innoQ Deutschland GmbH Verbindungen schaffen! https://www.flickr.com/photos/npobre/8189066572
43. © 2011 innoQ Deutschland GmbH Makroarchitektur ‣ legt systemübergreifende Standards fest ‣ UI-Integration ‣ Kommunikationsprotokolle ‣ Repräsentationsformate ‣ Umgang mit Datenredundanz ‣ Logging, Monitoring, Security
44. © 2011 innoQ Deutschland GmbH Smart endpoints, dump pipes! http://martinfowler.com/articles/microservices.html Martin Fowler, James Lewis
45. © 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
46. © 2011 innoQ Deutschland GmbH Aufbruch https://www.flickr.com/photos/epemsl/8790814488
47. © 2011 innoQ Deutschland GmbH Vorgehensmodelle ‣ Big Bang ‣ Evolutionäres Vorgehen
48. © 2011 innoQ Deutschland GmbH Big Bang ‣ komplette Neuentwicklung ‣ Monolith bleibt lange erhalten ‣ mehr Risiko, schlechter planbar ‣ weniger Kompromisse ‣ moderne Technologie
49. © 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
50. © 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
51. © 2011 innoQ Deutschland GmbH
52. © 2011 innoQ Deutschland GmbH
53. © 2011 innoQ Deutschland GmbH
54. © 2011 innoQ Deutschland GmbH Conway’s Law Organisationen die Systeme entwickeln, sind dazu verurteilt, Modelle zu entwerfen, die ein Abbild ihrer Kommunikationsstruktur darstellen.
55. © 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
56. © 2011 innoQ Deutschland GmbH Spannungsfelder ‣ Organisation vs. reale fachliche Beziehungen ‣ Größe der Services vs. Komplexität der Beziehungen untereinander
57. © 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
58. © 2011 innoQ Deutschland GmbH Vielen Dank!