Reactive Day auf der W-JAX 2014

Reactive Systems – Brauchen wir ein neues IT-Paradigma?

Lutz Hühnken

„Reactive Systems – Brauchen wir ein neues IT-Paradigma?“ war die Fragestellung für eine Diskussionsrunde am Dienstagabend der W-JAX. Ihre Antwort auf diese Frage haben vier Referenten schon vorher, im Laufe des Tages, im Rahmen des „Reactive Day“ gegeben.

Die Definition für „Reactive“ liefert das „Reactive Manifesto“. Es fordert von IT-Systemen die Eigenschaften „Responsive“ (Antwortbereitschaft), „Resilient“ (Robustheit), „Elastic“ (Elastizität) und „Message-driven“ (Nachrichten-basiert). Das kurze Papier ist nachzulesen unter http://www.reactivemanifesto.org.

If it needs to respond in failure case, that’s resilient (Dr. Roland Kuhn)

Reactive Streams

Nach kurzer Begrüßung durch Heiko Seeberger startete Dr. Roland Kuhn den Reactive Day mit einem Vortrag über „Akka Streams“. Diese sind eine Implementierung der „Reactive Streams„: Verschiedene Firmen, darunter Netflix, Pivotal, RedHat, Twitter und Typesafe, haben eine gemeinsame Spezifikation für den Umgang mit Datenströmen entwickelt. Die einfache API besteht aus lediglich 3 Java-Interfaces mit insgesamt 7 Methoden. Wichtige Innovation ist das Konzept des „Back Pressure“: Über einen Rückkanal kann der Stream-Empfänger der Quelle per „Gegendruck“ mitteilen, ob er bereit ist, weitere Daten entgegen zu nehmen.

Ein Anwendungsfall für Stream-Verarbeitung ist die Verarbeitung von großen Datenmengen – groß im Sinne von „mehr als in den Speicher passt“. Ein anderes Beispiel sind Daten, die nie vollständig vorliegen, sondern kontinuierlich generiert werden. „Complex Event Processing / CEP“ ist der entsprechende Begriff, als Beispiel wurde die Erkennung von Kreditkartenbetrug im Online-Shop genannt.

Streams sind also häufig flüchtige Daten – Werte treffen kontinuierlich ein und werden verarbeitet, es gibt kein Zurück. Die Länge kann unbegrenzt sein, die typische Verarbeitung ist die Transformation der Daten. Einen kompletten Stream zu aggregieren, kann hingegen unmöglich sein.

Die Akka-Implementierung der „reactive streams“ setzt auf eine einfache Abstraktion eines Streams als Quelle (Source), Fluss (Flow) und Senke (Sink), und für die Verarbeitung auf funktionale Programmierung.

Hierzu stehen aus der Collections API bekannte Funktionen höherer Ordnung zur Verfügung: map, filter, collect, grouped, drop, take und groupBy. Als Stream-spezifische neue Kategorien gibt es zudem zeitbegrenzte Transformationen (takeWithin, dropWith, groupedWithin), asynchrone (mapAsync, mapAsyncUnordered) und solche, die es erlauben, die Datenrate zu beeinflussen (expand, conflate, buffer).

Hinzu kommen noch „nicht-lineare“ Transformationen, d.h. mehrere Streams können zu einem zusammengefasst (merge, zip, concat), oder ein Stream in mehrere aufgeteilt (broadcast, route, balance, unzip) werden.

Nach diesem umfassenden Überblick über Akka Streams gab Dr. Roland Kuhn einen spannenden Einblick in die Erfahrung, in einer heterogenen Gruppe eine solche Spezifikation zu entwickeln. Wichtige Erkenntnis war die Notwendigkeit einer rigorosen Festlegung der Semantik und eine Überprüfung derselben durch Tests im Rahmen eines TCK (Technology Compatibility Kit).

Vert.x for World Domination

Nichts weniger als die Weltherrschaft strebte Jochen Mader in seinem Vortrag „Vert.x for World Domination“ an. Garantieren soll diese Allmacht eine Armee von Robotern. Zwei davon aus Lego, gesteuert mit Raspberry Pis und ausgestattet mit Schaumstoff-Munition, sind mit aufmarschiert.

Ein System zur Steuerung der 20cm großen Terror-Maschinen sollte auf jeden Fall „reactive“ sein, und vert.x als verteilter Event-Bus bietet die im Manifesto geforderten Eigenschaften.

Ausgangspunkt bildet die Betrachtung der JDK-Bordmittel in java.util.concurrent. Die API hat im Publikum wenig Freunde, und der Sprecher erntet auch keinen Widerspruch für die Aussage, dass mit der Beherrschung der API die eigentlichen Probleme erst losgehen: Contention und blockierende I/O. Das Konzept der Threads, die gemeinsam auf geteilten Speicher zugreifen, setzt der Skalierung schnell Grenzen. Zwar lässt sich der Contention mit lock-free Algorithmen entgegenwirken, es zeigt sich aber, dass Multithreading allein aktuelle Multicore-Rechner nicht effizient nutzt.

vert.x bietet als Alternative die „Verticles“. Diese kommunizieren ausschließlich über einen Event-Bus. Die Zuordnung erfolgt über plain-String „addresses“. Das Verticle kann sich als „Handler“ für eine bestimmte Adresse registrieren und Nachrichten an die geeigneten Abnehmer senden. Sehr einfach lässt sich so zum Beispiel ein Round-Robin-Scheduling einrichten – man muss nur mehrere Handler mit der gleichen Adresse anmelden.

Als zu Grunde liegende Infrastruktur verwendet vert.x Hazelcast, wobei dieses für den User transparent in vert.x eingebettet ist. Message-Format ist JSON, ab vert.x 3 wird die Möglichkeit geboten, stattdessen andere Serialisierungen zu verwenden.

Die 2-Roboter-Armee hat zwar nicht direkt die Welt erobert, aber zumindest das „Abschießen“ eines Cluster-Nodes anstandslos überstanden – und für einige Lacher gesorgt.

Reactive Micro Services

Stephane Maldini, ein Core-Committer des Reactor-Projektes, das er auch vorstellte, nahm in seinem Vortrag „Reactive micro-services with Reactor“ die Latenz als Ausgangspunkt für die Notwendigkeit, reactive zu werden.

Heutige Websites aggregieren im Hintergrund oft verschiedenste Services. Bei blockierenden Abfragen addieren sich Latenzen, es führt zu inakzeptablen Antwortzeiten – und damit zum Verlust von Usern, also Kunden. Die Gegenmaßnahme ist „aggressive“ Skalierung auf viele Knoten – mit entsprechenden Kosten.

So you take more nodes, and that is expensive. Because it’s Amazon. They need money too (Stephane Maldini)

Dem setzt Reactor die asynchrone Verarbeitung mit einem Event Bus entgegen. Reactor ist auch Teil der Reactive-Streams-Initiative und bietet folglich eine eigene Implementierung der API.

Die Stream-Verarbeitung unterscheidet sich in einigen Punkten grundsätzlich von der Event-Verarbeitung auf dem Bus. Streams sind typisiert, Sender und Empfänger haben eine direkte Verbindung zur Steuerung des Flusses, und im Stream folgen die Datensätze sequentiell aufeinander.

Wie schon im ersten Talk wurde noch einmal auf die Grundlagen von Streams eingegangen, inklusive üblicher Anwendungsfälle wie die Verarbeitung von kontinuierlich generierten Daten, Verarbeitung in Paketen (Micro-Batching) oder auch das Ermitteln von Metriken und Generieren von Statistiken.

Stephane Maldini unterscheidet dabei zwischen „hot“ und „cold“ Streams. „Hot“ sind Streams flüchtiger Daten, die in Echtzeit verarbeitet werden (Börsenkurse, Heartbeats, Mouse Clicks. WebSockets), während z.B. Dateien, die komplett vorliegen, aber ob ihrer Größe als Stream verarbeitet werden, in die Kategorie „cold“ fallen.

Auch hier folgte nach den Grundlagen der Einblick in die konkrete Implementierung der Reactive Streams. Interessant insbesondere, dass hier versucht wurde, möglichst RxJava nachzubilden. Dies macht den Umstieg für RxJava-Entwickler sicher einfacher, zumal darauf geachtet wurde, dass sich aus der Rx-Welt bekannte Patterns leicht übertragen lassen. In zukünftigen Versionen wird es Implementierungen für einige gängige Patterns, wie den „Circuit Breaker“ geben.

We use the sames names as RxJava. It’s easy to google the operations. (Stephane Maldini)

Wert wurde aber darauf gelegt, dass es sich bei Reactor’s Streams nicht einfach um einen Fork von RxJava handelt. Vielmehr ist Reactor auf hohen Durchsatz und eine problemlose Integration mit dem Pivotal Stack (Spring, RabbitMQ, Redis usw.) optimiert.

Reactive Apps mit Akka und AngularJS 

Eine echte „Hands-on“ Session mit viel Code war die Präsentation „Reactive Apps mit Akka und AngularJS“ von Heiko Seeberger.  Er zeigte reactive in Aktion mit einer Chat-Demo-Applikation, die er „Reactive Flows“ taufte. In einer einfachen AngularJS-Oberfläche werden Chat-Nachrichten eingegeben, die per Server-Sent-Events sofort an alle anderen verbundenen Browser gesendet werden.

In der App fand er die Möglichkeit, eine beeindruckende Anzahl von aktuellen und sich noch in der Entwicklung befindlichen Akka-Features unterzubringen. Mit wenigen Code-Zeilen wurde mit akka-http ein REST-Service erzeugt. Für die dauerhafte Speicherung kam akka-persistence zum Einsatz, Actor Sharding für die Lastverteilung und akka-data-replication für die Redundanz.

Der voll besetzte Raum folgte dem geballten Technologie-Einsatz mit erstauntem Schweigen.

Reactive Systems – Brauchen wir ein neues IT-Paradigma?

Gesprächiger wurde es dann wieder zum Abschluss des Reactive Day, der Podiumsdiskussion „Reactive Systems – Brauchen wir ein neues IT-Paradigma?“. Diskutanten waren Dr. Roland Kuhn, Jochen Mader, Heiko Seeberger und Uwe Friedrichsen. Kontoverse Standpunkte gab es nicht: Es herrschte Einigkeit darüber, dass hinter reactive wirklich Substanz steckt.

Was nicht heißt, dass es keine anregenden Einsichten gab. Es wurde hervorgehoben, dass der Thread als kleinste Einheit seine Berechtigung hatte, als es darum ging, einen einzelnen Prozessorkern maximal auszulasten. Heute ist aber das Multicore-System Standard, und diese Gegebenheiten der Hardware sind für effiziente Programme zu berücksichtigen.

Der Meinung, die Java-Welt hätte die Multicore-Entwicklung verschlafen, wurde entgegengehalten, dass die JVM nicht der Hinderungsgrund dafür ist, performante Programme zu entwickeln. Nicht jeder Entwickler kann und sollte sich aber intensiv mit Mechanical Sympathy auseinandersetzen, und wer Business-Logik implementiert, denkt dabei nicht an cache line padding.

Es müssen geeignete Abstraktionen oder Programmiermodelle gefunden werden – die auf dem Reactive Day präsentierten Projekte sind Angebote dafür.

Die anschließende Diskussion im Publikum kam schnell von technischen auf Probleme mit der Firmenkultur – viele der Anwesenden möchten gern reaktive Applikationen entwickeln, sehen aber am Arbeitsplatz keine Möglichkeit dafür.

Dort ist die Spezies des „Homo ja-aber“ sehr verbreitet. (Uwe Friedrichsen)

Insgesamt war der Reactive Day ein gelungener Tag, der deutlich macht, dass reactive ein Thema ist, das man im Auge behalten sollte.

 

 

Geschrieben von
Lutz Hühnken
Lutz Hühnken
Lutz Huehnken ist Solutions Architect bei Lightbend. Aktuell beschäftigt er sich mit der Entwicklung von Microservices mit Scala, Akka und Lagom. Er tweeted als @lutzhuehnken und blogged unter https://huehnken.de.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.