Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Systeme modernisieren mit Microservices, Hystri...

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.

Holger Kraus

March 24, 2015
Tweet

More Decks by Holger Kraus

Other Decks in Technology

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 Akute Probleme ‣ kaum zu

    warten ‣ kaum zu erweitern ‣ instabil ‣ buggy ‣ frustrierend ‣ veraltet
  3. © 2011 innoQ Deutschland GmbH Und nun? ‣ Arbeit einstellen?

    ‣ neues System bauen? ‣ stabilisieren? ‣ weiter machen? ‣ System zerlegen?
  4. © 2011 innoQ Deutschland GmbH Stabilitätspattern ‣ Timeouts ‣ Circuit

    Breaker ‣ Bulkheads ‣ Fail Fast ! … Steady State , Handshaking, Test Harness, Decoupling Middleware
  5. © 2011 innoQ Deutschland GmbH In der IT ‣ Thread-Pools

    ‣ DB-Connection-Pools ‣ Instanzen ‣ Server ‣ Datacenter
  6. © 2011 innoQ Deutschland GmbH ‣ von Netflix ‣ Resilience

    Library ‣ Command Pattern ‣ Metriken ‣ Dashboard Hystrix
  7. © 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); } !
  8. © 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); } }
  9. © 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(); }
  10. © 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(); } }
  11. © 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)
  12. © 2011 innoQ Deutschland GmbH Im Paket enthalten ‣ Hystrix

    intern mit Rx gebaut ‣ keine weitere Dependency ‣ „observe“ statt „queue“ ‣ oder „toObservable“ ! !
  13. © 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();
  14. © 2011 innoQ Deutschland GmbH Und nun? ‣ Anwendung stabilisiert

    ‣ wieder Luft zum Atmen ‣ weitere Systeme können integriert werden ! ‣ Entwicklung weiterhin zäh…
  15. © 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
  16. © 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
  17. © 2011 innoQ Deutschland GmbH Ziel ‣ Kleinere Einheiten schaffen,

    die ‣ man verstehen kann, ‣ beherrschbar sind, ‣ fachlich weiterentwickelt werden können ‣ und technologischen Wandel erlauben
  18. © 2011 innoQ Deutschland GmbH Gebraucht wird ein klarer Schnitt!

    https://www.flickr.com/photos/taefit/8528632756
  19. © 2011 innoQ Deutschland GmbH Systemeigenschaften ‣ Eigene Benutzeroberfläche ‣

    Eigene Datenhaltung ‣ Eigene interne, unabhängige Logik ‣ Klar definierte Schnittstellen ‣ Separates Deployment ‣ Separater Betrieb möglich
  20. © 2011 innoQ Deutschland GmbH Mikroarchitektur ‣ Autonome Entscheidung über

    ‣ Programmiersprache ‣ Frameworks ‣ Interne Module, Komponenten, ‣ Interne Abhängigkeiten ‣ Datenbanktechnologie
  21. © 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
  22. © 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
  23. © 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
  24. © 2011 innoQ Deutschland GmbH Makroarchitektur ‣ legt systemübergreifende Standards

    fest ‣ UI-Integration ‣ Kommunikationsprotokolle ‣ Repräsentationsformate ‣ Umgang mit Datenredundanz ‣ Logging, Monitoring, Security
  25. © 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
  26. © 2011 innoQ Deutschland GmbH Big Bang ‣ komplette Neuentwicklung

    ‣ Monolith bleibt lange erhalten ‣ mehr Risiko, schlechter planbar ‣ weniger Kompromisse ‣ moderne Technologie
  27. © 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
  28. © 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
  29. © 2011 innoQ Deutschland GmbH Conway’s Law Organisationen die Systeme

    entwickeln, sind dazu verurteilt, Modelle zu entwerfen, die ein Abbild ihrer Kommunikationsstruktur darstellen.
  30. © 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
  31. © 2011 innoQ Deutschland GmbH Spannungsfelder ‣ Organisation vs. reale

    fachliche Beziehungen ‣ Größe der Services vs. Komplexität der Beziehungen untereinander