von enterprise zu reactive bei der jug hessen am 3.12.2015

Post on 12-Jan-2017

474 Views

Category:

Software

1 Downloads

Preview:

Click to see full reader

TRANSCRIPT

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 DataWeb Scale

HFT

TomcatWeb MVCRDBMS

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

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) • „leichtgewichtig“ • einfacher zu programmieren (keine Inter-

Prozess-Kommunikation)

11

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 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.

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

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

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

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 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

JUGH - Von Enterprise zu Reactive

Reactive Checkliste

• Reactive bringt Sub-Thread-Level Concurrency mit sich. Darauf einstellen.

21

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 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/

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 Tasks zuständig • Das n kann ziemlich groß sein

So einen Thread wollen wir sicher nicht für Blocking I/O verschwenden!

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 +

JUGH - Von Enterprise zu Reactive

Isolieren!

27

vert.x hat „worker verticles“ Play/Akka: Dispatcher-Konfiguration

Slick 3 hat das schon „eingebaut“

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

„Distributed Transactions“ vs. Distributed Systems

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?

JUGH - Von Enterprise zu Reactive 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

JUGH - Von Enterprise zu Reactive

Trennen ( = die Schritte trennen)

33

Behauptung: Jeder 2PC kann durch asynchrone Nachrichten ersetzt

werden.

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. [..]

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

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

JUGH - Von Enterprise zu Reactive

Mögliche Umsetzung: Saga Pattern

37

Tipp: http://kellabyte.com/2012/05/30/clarifying-the-saga-pattern/

JUGH - Von Enterprise zu Reactive 38

Noch ein Tipp: https://speakerdeck.com/caitiem20/applying-the-saga-pattern

Mögliche Umsetzung: Saga Pattern

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.

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 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.

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

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 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.

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

Zusammenfassung

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.

JUGH - Von Enterprise zu Reactive

The Pragmatic Reactive Checklist

50

• Task-level (sub-thread level) concurrency

• Non-blocking I/O • Distributed • Containerless

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äftsanwendung reactive machen, und dabei Kompromisse eingehen.

•Was bringt mir das?

54

JUGH - Von Enterprise zu Reactive

• Heißt nicht nur „web scale“.

• Effizient sein. Moderne Hardware nutzen (Many Core, NUMA)

• Von Innovation profitieren

55

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 zu machen. Sondern einfacher!

•Wie würdest du es mit Menschen lösen..?

57

Lutz Hühnken - Solution Architect

Twitter - @lutzhuehnken Blog (neu) - http://www.huehnken.de

Danke!

top related