Lutz Hühnken - Solution Architect
Twitter - @lutzhuehnken
Blog (neu) - http://www.huehnken.de
Von Enterprise zu Reactive
JUGH - Von Enterprise zu Reactive
Reactive „for the rest of us“..
2
Big Data
Web Scale
HFT
Tomcat
Web MVC
RDBMS
JUGH - Von Enterprise zu Reactive
Was ist Enterprise?
Im Sinne dieses Vortrags:
• Alles, was auf Java EE basiert
• Insbeso...
Was ist Reactive?
Behauptet doch jeder von sich…
Alles Akka, oder was?
Echte Fragen …
WAR?
Servlet Container?
Library X
(nutzt
ThreadLocal)
?
RDBMS/
JDBC?
Wie mache ich 2PC?
… drehen sich oft um:
Deployment
Concurrency Model
I/O
Verteilung
The Pragmatic Reactive Manifesto ;)
Threads vs. task level concurrency
JUGH - Von Enterprise zu Reactive
Threads … scheinbar eine gute Idee
• Threads sind (im Gegensatz zu Prozessen)
• „leichtg...
JUGH - Von Enterprise zu Reactive
Lightweight?
12
Slide from John Rose, Java VM Architect, JFokus, Stockholm, February 2015
JUGH - Von Enterprise zu Reactive
The problem with Threads
13
They discard the most essential and
appealing properties of ...
JUGH - Von Enterprise zu Reactive
Threads
• nicht effizient
• Speicherverbrauch
• Scheduling / context switch
• nicht opti...
JUGH - Von Enterprise zu Reactive
Was wäre also besser?
Ziele
• Task-Level (sub-thread) concurrency
• „share nothing“
• Th...
JUGH - Von Enterprise zu Reactive
Thread Alternativen (Nachfolger?)
• Green threads / coroutines / fibres
• feinere Granul...
JUGH - Von Enterprise zu Reactive
Beispiel: Http Request handling
Java EE: Threads. Servlet API: Thread per Request
18
JUGH - Von Enterprise zu Reactive
Beispiel: Http Request handling
Reactive: Sub-Thread (Play, Akka HTTP, vert.x..)
19
JUGH - Von Enterprise zu Reactive
Konsequenzen
• Wir sind (ohne explizit Aktoren o.ä. zu
verwenden) in einem anderen
Concu...
JUGH - Von Enterprise zu Reactive
Reactive Checkliste
• Reactive bringt Sub-Thread-Level
Concurrency mit sich. Darauf eins...
Blocking vs. non-blocking I/O
JUGH - Von Enterprise zu Reactive
High concurrency matters
23
But there’s one thing we can all agree on: At high levels of...
JUGH - Von Enterprise zu Reactive
Blocking I/O
Was wird eigentlich geblockt?
24
JUGH - Von Enterprise zu Reactive
Non-blocking
25
Bei Task-Level (Sub-Thread-Level) Concurrency
• Ist jeder Thread für n T...
JUGH - Von Enterprise zu Reactive
Aber wenn ich so etwas benötige?
26
try {
stmt = con.createStatement();
ResultSet rs = s...
JUGH - Von Enterprise zu Reactive
Isolieren!
27
vert.x hat „worker verticles“
Play/Akka: Dispatcher-Konfiguration
Slick 3 h...
JUGH - Von Enterprise zu Reactive
Reactive Checkliste (Fortsetzung)
• Reactive bringt Sub-Thread-Level
Concurrency mit sic...
„Distributed Transactions“
vs. Distributed Systems
JUGH - Von Enterprise zu Reactive 30
@Transactional
public static class GreetingService {
@Inject
private JmsTemplate jmsT...
JUGH - Von Enterprise zu Reactive 31
JUGH - Von Enterprise zu Reactive
Vermeiden
32
@Transactional
public static class GreetingService {
@Inject
private JmsTem...
JUGH - Von Enterprise zu Reactive
Trennen ( = die Schritte trennen)
33
Behauptung: Jeder 2PC kann durch
asynchrone Nachric...
JUGH - Von Enterprise zu Reactive
Life beyond Distributed Transactions
34
In general, application
developers simply do not...
35
Want Almost-Infinite Scaling

• More of everything… Year by year, bigger and bigger
• If it fits on your machines, mult...
JUGH - Von Enterprise zu Reactive
2 PC => messaging
36
Item-BCancellation Tentative
Op
Item-A
Restriktionen bzw. Anforderu...
JUGH - Von Enterprise zu Reactive
Mögliche Umsetzung: Saga Pattern
37
Tipp: http://kellabyte.com/2012/05/30/clarifying-the...
JUGH - Von Enterprise zu Reactive 38
Noch ein Tipp: https://speakerdeck.com/caitiem20/applying-the-saga-pattern
Mögliche U...
JUGH - Von Enterprise zu Reactive
Verteilte Transaktionen
39
Verteilte Transaktionen („2PC“) sind eine häufige Quelle
für ...
JUGH - Von Enterprise zu Reactive 40
Service A
(Reactive)
Service B
(Legacy)
Verwerten
JUGH - Von Enterprise zu Reactive
Ausblick / Gedankenspiele
41
Die Datenbanklandschaft ändert sind, wir bewegen uns in
Ric...
JUGH - Von Enterprise zu Reactive
Reactive Checkliste (Fortsetzung)
• Reactive bringt Sub-Thread-Level
Concurrency mit sic...
App Servers vs. Standalone
JUGH - Von Enterprise zu Reactive 44
JUGH - Von Enterprise zu Reactive 45
JUGH - Von Enterprise zu Reactive
Java EE Application Servers
46
Die Servlet API wurde für Thread-per-Request
und synchron...
JUGH - Von Enterprise zu Reactive
Reactive Checkliste (Fortsetzung)
• Reactive bringt Sub-Thread-Level
Concurrency mit sic...
Zusammenfassung
JUGH - Von Enterprise zu Reactive
Schlussfolgerung
49
Wenn
• Threads die kleinste Concurrency-Einheit in
deinem Code sind,...
JUGH - Von Enterprise zu Reactive
The Pragmatic Reactive Checklist
50
• Task-level (sub-thread level)
concurrency
• Non-bl...
Reactive Manifesto revisited
Wir haben eigentlich nur über den
„elastic“ - Teil gesprochen
führt zu
führt zu
JUGH - Von Enterprise zu Reactive
Reactive - Warum das Ganze?
• Wir haben gesehen: Ich kann auch meine
„normale“ Geschäfts...
JUGH - Von Enterprise zu Reactive
• Heißt nicht nur „web scale“.
• Effizient sein. Moderne Hardware nutzen
(Many Core, NUM...
JUGH - Von Enterprise zu Reactive
• Prinzipien der Supervision & Isolation
• Let it crash!
56
JUGH - Von Enterprise zu Reactive
• Spaß!!
• Wirklich. All das ist nicht entwickelt worden,
um unser Leben komplizierter z...
Lutz Hühnken - Solution Architect
Twitter - @lutzhuehnken
Blog (neu) - http://www.huehnken.de
Danke!
Von Enterprise zu Reactive bei der JUG Hessen am 3.12.2015
Nächste SlideShare
Wird geladen in …5
×

Von Enterprise zu Reactive bei der JUG Hessen am 3.12.2015

437 Aufrufe

Veröffentlicht am

Slides zu http://www.meetup.com/de/Java-User-Group-Hessen-JUGH/events/226419997/

Wer eine Weile mit der Java Enterprise Edition gearbeitet hat und sich für asynchrone, verteilte, "reaktive" Architekturen interessiert, muss erst einmal einiges in der Vergangenheit Gelerntes aus dem Weg schaffen.

Denn die üblichen Architekturmuster mit „Thread per Request“, Nutzung von „ThreadLocals“ für Session-Caches, synchrone Aufrufe von Services und Datenbanken und (möglicherweise verteilte) Transaktionen mit 2-Phasen-Commit lassen sich nicht eins zu eins in ein System, das auf Aktoren basiert, übertragen.

Wie können wir ihre Transition einfacher machen? Was tritt an die Stelle dieser Enterprise-Ansätze? Welche Tools muss ich aus meinem Werkzeugkasten entfernen? Und warum lohnt sich das Ganze?

Veröffentlicht in: Software
0 Kommentare
1 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

Keine Downloads
Aufrufe
Aufrufe insgesamt
437
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
16
Aktionen
Geteilt
0
Downloads
3
Kommentare
0
Gefällt mir
1
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Von Enterprise zu Reactive bei der JUG Hessen am 3.12.2015

  1. 1. Lutz Hühnken - Solution Architect Twitter - @lutzhuehnken Blog (neu) - http://www.huehnken.de Von Enterprise zu Reactive
  2. 2. JUGH - Von Enterprise zu Reactive Reactive „for the rest of us“.. 2 Big Data Web Scale HFT Tomcat Web MVC RDBMS
  3. 3. 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
  4. 4. Was ist Reactive?
  5. 5. Behauptet doch jeder von sich…
  6. 6. Alles Akka, oder was?
  7. 7. Echte Fragen … WAR? Servlet Container? Library X (nutzt ThreadLocal) ? RDBMS/ JDBC? Wie mache ich 2PC?
  8. 8. … drehen sich oft um: Deployment Concurrency Model I/O Verteilung
  9. 9. The Pragmatic Reactive Manifesto ;)
  10. 10. Threads vs. task level concurrency
  11. 11. 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
  12. 12. JUGH - Von Enterprise zu Reactive Lightweight? 12 Slide from John Rose, Java VM Architect, JFokus, Stockholm, February 2015
  13. 13. 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.
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. JUGH - Von Enterprise zu Reactive Beispiel: Http Request handling Java EE: Threads. Servlet API: Thread per Request 18
  18. 18. JUGH - Von Enterprise zu Reactive Beispiel: Http Request handling Reactive: Sub-Thread (Play, Akka HTTP, vert.x..) 19
  19. 19. 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
  20. 20. JUGH - Von Enterprise zu Reactive Reactive Checkliste • Reactive bringt Sub-Thread-Level Concurrency mit sich. Darauf einstellen. 21
  21. 21. Blocking vs. non-blocking I/O
  22. 22. 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/
  23. 23. JUGH - Von Enterprise zu Reactive Blocking I/O Was wird eigentlich geblockt? 24
  24. 24. 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!
  25. 25. 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 +
  26. 26. JUGH - Von Enterprise zu Reactive Isolieren! 27 vert.x hat „worker verticles“ Play/Akka: Dispatcher-Konfiguration Slick 3 hat das schon „eingebaut“
  27. 27. 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
  28. 28. „Distributed Transactions“ vs. Distributed Systems
  29. 29. 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?
  30. 30. JUGH - Von Enterprise zu Reactive 31
  31. 31. 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
  32. 32. JUGH - Von Enterprise zu Reactive Trennen ( = die Schritte trennen) 33 Behauptung: Jeder 2PC kann durch asynchrone Nachrichten ersetzt werden.
  33. 33. 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. [..]
  34. 34. 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
  35. 35. JUGH - Von Enterprise zu Reactive 2 PC => messaging 36 Item-BCancellation Tentative Op Item-A Restriktionen bzw. Anforderungen •at-least-once Delivery •idempotente Nachrichten •vorläufige Operationen
  36. 36. JUGH - Von Enterprise zu Reactive Mögliche Umsetzung: Saga Pattern 37 Tipp: http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/
  37. 37. JUGH - Von Enterprise zu Reactive 38 Noch ein Tipp: https://speakerdeck.com/caitiem20/applying-the-saga-pattern Mögliche Umsetzung: Saga Pattern
  38. 38. 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.
  39. 39. JUGH - Von Enterprise zu Reactive 40 Service A (Reactive) Service B (Legacy) Verwerten
  40. 40. 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.
  41. 41. 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
  42. 42. App Servers vs. Standalone
  43. 43. JUGH - Von Enterprise zu Reactive 44
  44. 44. JUGH - Von Enterprise zu Reactive 45
  45. 45. 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.
  46. 46. 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
  47. 47. Zusammenfassung
  48. 48. 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.
  49. 49. JUGH - Von Enterprise zu Reactive The Pragmatic Reactive Checklist 50 • Task-level (sub-thread level) concurrency • Non-blocking I/O • Distributed • Containerless
  50. 50. Reactive Manifesto revisited
  51. 51. Wir haben eigentlich nur über den „elastic“ - Teil gesprochen
  52. 52. führt zu führt zu
  53. 53. 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
  54. 54. JUGH - Von Enterprise zu Reactive • Heißt nicht nur „web scale“. • Effizient sein. Moderne Hardware nutzen (Many Core, NUMA) • Von Innovation profitieren 55
  55. 55. JUGH - Von Enterprise zu Reactive • Prinzipien der Supervision & Isolation • Let it crash! 56
  56. 56. 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
  57. 57. Lutz Hühnken - Solution Architect Twitter - @lutzhuehnken Blog (neu) - http://www.huehnken.de Danke!

×