Slide 1

Slide 1 text

Lutz Hühnken - Solution Architect Twitter - @lutzhuehnken Blog (neu) - http://www.huehnken.de Von Enterprise zu Reactive

Slide 2

Slide 2 text

JUGH - Von Enterprise zu Reactive Reactive „for the rest of us“.. 2 Big Data Web Scale HFT Tomcat Web MVC RDBMS

Slide 3

Slide 3 text

JUGH - Von Enterprise zu Reactive Was ist Enterprise? Im Sinne dieses Vortrags: • Alles, was auf Java EE basiert • Insbesondere Servlet API basierte Webapps, z.B. auf Tomcat 3

Slide 4

Slide 4 text

Was ist Reactive?

Slide 5

Slide 5 text

Behauptet doch jeder von sich…

Slide 6

Slide 6 text

Alles Akka, oder was?

Slide 7

Slide 7 text

Echte Fragen … WAR? Servlet Container? Library X (nutzt ThreadLocal) ? RDBMS/ JDBC? Wie mache ich 2PC?

Slide 8

Slide 8 text

… drehen sich oft um: Deployment Concurrency Model I/O Verteilung

Slide 9

Slide 9 text

The Pragmatic Reactive Manifesto ;)

Slide 10

Slide 10 text

Threads vs. task level concurrency

Slide 11

Slide 11 text

JUGH - Von Enterprise zu Reactive Threads … scheinbar eine gute Idee • Threads sind (im Gegensatz zu Prozessen) • „leichtgewichtig“ • einfacher zu programmieren (keine Inter- Prozess-Kommunikation) 11

Slide 12

Slide 12 text

JUGH - Von Enterprise zu Reactive Lightweight? 12 Slide from John Rose, Java VM Architect, JFokus, Stockholm, February 2015

Slide 13

Slide 13 text

JUGH - Von Enterprise zu Reactive The problem with Threads 13 They discard the most essential and appealing properties of sequential computation: understandability, predictability, and determinism. Threads, as a model of computation, are wildly nondeterministic, and the job of the programmer becomes one of pruning that nondeterminism.

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

JUGH - Von Enterprise zu Reactive Threads • nicht effizient • Speicherverbrauch • Scheduling / context switch • nicht optimal für NUMA • „contention“
 • kein gutes Programmiermodell • „shared mutual state“ ist schwer nachzuvollziehen 15

Slide 16

Slide 16 text

JUGH - Von Enterprise zu Reactive Was wäre also besser? Ziele • Task-Level (sub-thread) concurrency • „share nothing“ • Threads darunter, als 
 Anzahl Threads ~ Anzahl Kerne 16

Slide 17

Slide 17 text

JUGH - Von Enterprise zu Reactive Thread Alternativen (Nachfolger?) • Green threads / coroutines / fibres • feinere Granularität, aber im Prinzip gleiches Programmiermodell • Event-loop (e.g. vert.x, Reactor) • sehr lose Kopplung, „Bus“-Architektur vorgegeben • Aktoren ! • Share-nothing, Flexibel, in der Praxis bewährt 17

Slide 18

Slide 18 text

JUGH - Von Enterprise zu Reactive Beispiel: Http Request handling Java EE: Threads. Servlet API: Thread per Request 18

Slide 19

Slide 19 text

JUGH - Von Enterprise zu Reactive Beispiel: Http Request handling Reactive: Sub-Thread (Play, Akka HTTP, vert.x..) 19

Slide 20

Slide 20 text

JUGH - Von Enterprise zu Reactive Konsequenzen • Wir sind (ohne explizit Aktoren o.ä. zu verwenden) in einem anderen Concurrency-Modell. • ThreadLocal ist jetzt ein Anti-Pattern! Am besten vermeiden, oder es ist zusätzliche Arbeit nötig. • Noch zu klären: Was heißt das eigentlich für I/O? 20

Slide 21

Slide 21 text

JUGH - Von Enterprise zu Reactive Reactive Checkliste • Reactive bringt Sub-Thread-Level Concurrency mit sich. Darauf einstellen. 21

Slide 22

Slide 22 text

Blocking vs. non-blocking I/O

Slide 23

Slide 23 text

JUGH - Von Enterprise zu Reactive High concurrency matters 23 But there’s one thing we can all agree on: At high levels of concurrency (thousands of connections) your server needs to go to asynchronous non-blocking. [..] any part of your server code blocks you’re going to need a thread. And at these levels of concurrency, you can’t go creating threads for every connection. From https://strongloop.com/strongblog/node-js-is-faster-than-java/

Slide 24

Slide 24 text

JUGH - Von Enterprise zu Reactive Blocking I/O Was wird eigentlich geblockt? 24

Slide 25

Slide 25 text

JUGH - Von Enterprise zu Reactive Non-blocking 25 Bei Task-Level (Sub-Thread-Level) Concurrency • Ist jeder Thread für n Tasks zuständig • Das n kann ziemlich groß sein So einen Thread wollen wir sicher nicht für Blocking I/O verschwenden!

Slide 26

Slide 26 text

JUGH - Von Enterprise zu Reactive Aber wenn ich so etwas benötige? 26 try { stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(query); while (rs.next()) { String coffeeName = rs.getString("COF_NAME"); int supplierID = rs.getInt("SUP_ID"); float price = rs.getFloat("PRICE"); int sales = rs.getInt("SALES"); int total = rs.getInt("TOTAL"); System.out.println(coffeeName + "\t" + supplierID + "\t" + price + "\t" + sales +

Slide 27

Slide 27 text

JUGH - Von Enterprise zu Reactive Isolieren! 27 vert.x hat „worker verticles“ Play/Akka: Dispatcher-Konfiguration Slick 3 hat das schon „eingebaut“

Slide 28

Slide 28 text

JUGH - Von Enterprise zu Reactive Reactive Checkliste (Fortsetzung) • Reactive bringt Sub-Thread-Level Concurrency mit sich. Darauf einstellen. • Non-Blocking I/O verwenden. Wenn es wirklich gar nicht geht: Blocking I/O isolieren. 28

Slide 29

Slide 29 text

„Distributed Transactions“ vs. Distributed Systems

Slide 30

Slide 30 text

JUGH - Von Enterprise zu Reactive 30 @Transactional public static class GreetingService { @Inject private JmsTemplate jmsTemplate; @PersistenceContext private EntityManager entityManager; public void createGreeting(String name) { Greeting greeting = new Greeting(name); this.entityManager.persist(greeting); this.jmsTemplate.convertAndSend("greetings", greeting); … Aber wenn ich so etwas benötige?

Slide 31

Slide 31 text

JUGH - Von Enterprise zu Reactive 31

Slide 32

Slide 32 text

JUGH - Von Enterprise zu Reactive Vermeiden 32 @Transactional public static class GreetingService { @Inject private JmsTemplate jmsTemplate; @PersistenceContext private EntityManager entityManager; public void createGreeting(String name) { Greeting greeting = new Greeting(name); this.entityManager.persist(greeting); this.jmsTemplate.convertAndSend("greetings", greeting); … Nicht wirklich „all or nothing“, lediglich Abgleich

Slide 33

Slide 33 text

JUGH - Von Enterprise zu Reactive Trennen ( = die Schritte trennen) 33 Behauptung: Jeder 2PC kann durch asynchrone Nachrichten ersetzt werden.

Slide 34

Slide 34 text

JUGH - Von Enterprise zu Reactive Life beyond Distributed Transactions 34 In general, application developers simply do not implement large scalable applications assuming distributed transactions. When they attempt to use distributed transactions, the projects founder because the performance costs and fragility make them impractical. [..]

Slide 35

Slide 35 text

35 Want Almost-Infinite Scaling
 • More of everything… Year by year, bigger and bigger • If it fits on your machines, multiply by 10, if that fits, multiply by 1000… • Strive to scale almost linearly (N log N for some big log). Assumptions
 (Don’t Have to Prove These… Just Plain Believe Them) Grown-Ups Don’t Use Distributed Transactions •The apps using distributed transactions become too fragile… • Let’s just consider local transactions. ! Multiple disjoint scopes of serializability Want Scale-Agnostic Apps
 • Two layers to the application: 
 scale-agnostic and scale-aware • Consider scale-agnostic API Scale Agnostic Code Scale-Aware-Code Application Upper Layer Lower Layer Scale Agnostic API

Slide 36

Slide 36 text

JUGH - Von Enterprise zu Reactive 2 PC => messaging 36 Item-B Cancellation Tentative Op Item-A Restriktionen bzw. Anforderungen •at-least-once Delivery •idempotente Nachrichten •vorläufige Operationen

Slide 37

Slide 37 text

JUGH - Von Enterprise zu Reactive Mögliche Umsetzung: Saga Pattern 37 Tipp: http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/

Slide 38

Slide 38 text

JUGH - Von Enterprise zu Reactive 38 Noch ein Tipp: https://speakerdeck.com/caitiem20/applying-the-saga-pattern Mögliche Umsetzung: Saga Pattern

Slide 39

Slide 39 text

JUGH - Von Enterprise zu Reactive Verteilte Transaktionen 39 Verteilte Transaktionen („2PC“) sind eine häufige Quelle für Abbrüche und Contention. Sie können oft vermieden werden. Generell können lokale Transaktionen und at-least-once Delivery sie ersetzen. Das Saga-Pattern ist eine praktische Umsetzung von „all- or-nothing“ für verteilte Systeme.

Slide 40

Slide 40 text

JUGH - Von Enterprise zu Reactive 40 Service A (Reactive) Service B (Legacy) Verwerten

Slide 41

Slide 41 text

JUGH - Von Enterprise zu Reactive Ausblick / Gedankenspiele 41 Die Datenbanklandschaft ändert sind, wir bewegen uns in Richtung „event sourcing“ und „Immutability“. Das ist interessant für Reaktive Systeme! „All-or-nothing“ Probleme hängen zusammen mit dem Wunsch, eine globale Wahrheit zu kennen im „Jetzt“. Aber was ist jetzt? Ein Zeitpunkt - oder der Ergebnis einer Folge von Ereignissen? Empfehlung: „The Illusion of Present“ von Jonas Bonér.

Slide 42

Slide 42 text

JUGH - Von Enterprise zu Reactive Reactive Checkliste (Fortsetzung) • Reactive bringt Sub-Thread-Level Concurrency mit sich. Darauf einstellen. • Non-Blocking I/O verwenden. Wenn es wirklich gar nicht geht: Blocking I/O isolieren. • Keine verteilten Transaktionen verwenden. Wenn es wirklich gar nicht anders geht: Isolieren. 42

Slide 43

Slide 43 text

App Servers vs. Standalone

Slide 44

Slide 44 text

JUGH - Von Enterprise zu Reactive 44

Slide 45

Slide 45 text

JUGH - Von Enterprise zu Reactive 45

Slide 46

Slide 46 text

JUGH - Von Enterprise zu Reactive Java EE Application Servers 46 Die Servlet API wurde für Thread-per-Request und synchrone I/O entwickelt. Wenn man Application Servers nicht als Container für mehrere Applikationen nutzt - was unterscheidet sie von einer Library? Erfordert Ops-Änderungen, aber Tools etablieren sich.

Slide 47

Slide 47 text

JUGH - Von Enterprise zu Reactive Reactive Checkliste (Fortsetzung) • Reactive bringt Sub-Thread-Level Concurrency mit sich. Darauf einstellen. • Non-Blocking I/O verwenden. Wenn es wirklich gar nicht geht: Blocking I/O isolieren. • Keine verteilten Transaktionen verwenden. Wenn es wirklich gar nicht anders geht: Isolieren. • Keinen App-Server / Servlet-Container verwenden. 47

Slide 48

Slide 48 text

Zusammenfassung

Slide 49

Slide 49 text

JUGH - Von Enterprise zu Reactive Schlussfolgerung 49 Wenn • Threads die kleinste Concurrency-Einheit in deinem Code sind, oder • Du Blocking I/O verwendest (ohne klare Trennung), oder • Du 2-Phase-Commit verwendest, oder • Du einen Java EE Application Server / Servlet Container verwendest dann ist deine Applikation nicht Reactive.

Slide 50

Slide 50 text

JUGH - Von Enterprise zu Reactive The Pragmatic Reactive Checklist 50 • Task-level (sub-thread level) concurrency • Non-blocking I/O • Distributed • Containerless

Slide 51

Slide 51 text

Reactive Manifesto revisited

Slide 52

Slide 52 text

Wir haben eigentlich nur über den „elastic“ - Teil gesprochen

Slide 53

Slide 53 text

führt zu führt zu

Slide 54

Slide 54 text

JUGH - Von Enterprise zu Reactive Reactive - Warum das Ganze? • Wir haben gesehen: Ich kann auch meine „normale“ Geschäftsanwendung reactive machen, und dabei Kompromisse eingehen. • Was bringt mir das? 54

Slide 55

Slide 55 text

JUGH - Von Enterprise zu Reactive • Heißt nicht nur „web scale“. • Effizient sein. Moderne Hardware nutzen (Many Core, NUMA) • Von Innovation profitieren 55

Slide 56

Slide 56 text

JUGH - Von Enterprise zu Reactive • Prinzipien der Supervision & Isolation • Let it crash! 56

Slide 57

Slide 57 text

JUGH - Von Enterprise zu Reactive • Spaß!! • Wirklich. All das ist nicht entwickelt worden, um unser Leben komplizierter zu machen. Sondern einfacher! • Wie würdest du es mit Menschen lösen..? 57

Slide 58

Slide 58 text

Lutz Hühnken - Solution Architect Twitter - @lutzhuehnken Blog (neu) - http://www.huehnken.de Danke!