Resilient Software Design Patterns

Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim

Version:

17.1

www.oio.de [email protected]

Ihr Sprecher

Thorsten Maier Trainer, Berater, Entwickler

© Orientation in Objects GmbH

Resilient Software Design Patterns

2

Resilient Software?

© Orientation in Objects GmbH

Resilient Software Design Patterns

3

Resilient Software?

Widerstandsfähig gegen Fehler

© Orientation in Objects GmbH

Resilient Software Design Patterns

4

Warum?

© Orientation in Objects GmbH

Resilient Software Design Patterns

5

Warum?

… weil jeder Ausfall viel Geld kostet und viele User verärgert

© Orientation in Objects GmbH

Resilient Software Design Patterns

6

Warum?

… weil jeder Ausfall viel Geld kostet und viele User verärgert

© Orientation in Objects GmbH

Resilient Software Design Patterns

7

Was ist daran neu?

© Orientation in Objects GmbH

Resilient Software Design Patterns

8

Was ist daran neu? …mehr User …mehr Daten

…schnellere Anpassungen

© Orientation in Objects GmbH

Resilient Software Design Patterns

9

Wie machen wir eine Software „resilient“?

© Orientation in Objects GmbH

Resilient Software Design Patterns

10

Wie machen wir eine Software „resilient“?

Redundanz

© Orientation in Objects GmbH

Resilient Software Design Patterns

11

Wie machen wir eine Software „resilient“?

Redundanz Isolation

© Orientation in Objects GmbH

Resilient Software Design Patterns

12

Wie machen wir eine Software „resilient“?

Redundanz Isolation Lose Kopplung

© Orientation in Objects GmbH

Resilient Software Design Patterns

13

Wie machen wir eine Software „resilient“?

Redundanz Isolation Lose Kopplung Fallback © Orientation in Objects GmbH

Resilient Software Design Patterns

14

Wie machen wir eine Software „resilient“?

Redundanz Isolation Lose Kopplung Fallback © Orientation in Objects GmbH

Resilient Software Design Patterns

15

ISOLATION

© Orientation in Objects GmbH

Resilient Software Design Patterns

16

© Orientation in Objects GmbH

Resilient Software Design Patterns

17

© Orientation in Objects GmbH

Resilient Software Design Patterns

18

BULKHEADS © Orientation in Objects GmbH

Resilient Software Design Patterns

19

Bulkheads im Kleinen:

Methodenaufrufe

© Orientation in Objects GmbH

Resilient Software Design Patterns

20

public int fakultaet(int n) { return (n == 0) ? 1 : n * fakultaet(n - 1); }

Mögliche Probleme? © Orientation in Objects GmbH

Resilient Software Design Patterns

21

public int fakultaet(int n) { if (n < 0) { throw new IllegalArgumentException(); } return (n == 0) ? 1 : n * fakultaet(n - 1); }

Schon besser… © Orientation in Objects GmbH

Resilient Software Design Patterns

22

Validierung der Aufrufparameter Datentypen korrekt? Wertebereiche eingehalten? Vorbedingungen erfüllt? != null Kreditkartennummer valide …

„Freundliche“ Rückgabewerte Niemals „null“ zurückliefern Datenmengen beschränken …

© Orientation in Objects GmbH

Resilient Software Design Patterns

23

Bulkheads im Großen:

Software-Bausteine

© Orientation in Objects GmbH

Resilient Software Design Patterns

24

3 Bausteine

© Orientation in Objects GmbH

Resilient Software Design Patterns

25

Anwendung mit 3 Bausteinen

© Orientation in Objects GmbH

Resilient Software Design Patterns

26

Anwendung mit 3 Bausteinen

Deployment auf einem Server

© Orientation in Objects GmbH

Resilient Software Design Patterns

27

Anwendung mit 3 Bausteinen

Baustein © Orientation in Objects GmbH

wird 4 mal benötigt Resilient Software Design Patterns

28

Anwendung mit 3 Bausteinen

Nachteile wird nur 2 mal benötigt Änderung an erfordert Reploy von

Baustein © Orientation in Objects GmbH

wird 4 mal benötigt Resilient Software Design Patterns

29

Anwendung mit 3 Bausteinen

Baustein © Orientation in Objects GmbH

Unabhängige Artefakte

wird 4 mal benötigt Resilient Software Design Patterns

30

Anwendung mit 3 Bausteinen

Baustein © Orientation in Objects GmbH

wird 4 mal benötigt

Unabhängige Artefakte

Flexible Skalierung auf 3 Server Resilient Software Design Patterns

31

Vorteile

Unabhängige Artefakte

Isolierte Entwicklung Isolierte Fehler Isoliertes Deployment …

Flexible Skalierung auf 3 Server © Orientation in Objects GmbH

Resilient Software Design Patterns

32

Nachteil

Unabhängige Artefakte

Kommunikation über Prozess- und Netzwerkgrenzen  Verteilte Datenverarbeitung

Flexible Skalierung auf 3 Server © Orientation in Objects GmbH

Resilient Software Design Patterns

33

8 Irrtümer der verteilten Datenverarbeitung Netzwerk ist ausfallsicher Latenzzeit = 0 Datendurchsatz ∞ Netzwerk ist sicher Netzwerktopologie ist stabil … 1 Netzwerkadministrator Kosten des Datentransports = 0 Netzwerk ist homogen Bill Joy, Tom Lyon, L Peter Deutsch und James Gosling © Orientation in Objects GmbH

Resilient Software Design Patterns

34

In Kürze:

Zuverlässigkeit und Konsistenz existieren nicht mehr

© Orientation in Objects GmbH

Resilient Software Design Patterns

35

Verhalten und Standorte der Komponenten unseres Systems verändern sich ständig

© Orientation in Objects GmbH

Resilient Software Design Patterns

36

Komponenten liefern unzuverlässige Daten oder verschwinden völlig

© Orientation in Objects GmbH

Resilient Software Design Patterns

37

Ok, wir brauchen ISOLATION

Aber wie kommen die Teile wieder zusammen?

© Orientation in Objects GmbH

Resilient Software Design Patterns

38

LOSE KOPPLUNG

© Orientation in Objects GmbH

Resilient Software Design Patterns

39

LOSE KOPPLUNG synchron © Orientation in Objects GmbH

asynchron Resilient Software Design Patterns

40

? Startet gerade

nicht erreichbar

Mit wem kann / soll ich kommunizieren? © Orientation in Objects GmbH

Resilient Software Design Patterns

41

? Startet gerade

nicht erreichbar

Als

© Orientation in Objects GmbH

Architekt lassen sich alle Probleme mit „Boxes and Lines“ lösen  Resilient Software Design Patterns

42

2. Dienst finden

3. Dienst nutzen

Verzeichnisdienst 1. registrieren

© Orientation in Objects GmbH

Resilient Software Design Patterns

43

2. Dienst finden

3. Dienst nutzen

Verzeichnisdienst 1. registrieren

Als

© Orientation in Objects GmbH

Entwickler brauchen wir etwas mehr Resilient Software Design Patterns

44

2. Dienst finden

3. Dienst nutzen

Eureka 1. registrieren

@SpringBootApplication @EnableEurekaServer public class Application { public static void main(String[] args) { // ... } } © Orientation in Objects GmbH

Resilient Software Design Patterns

45

Security? © Orientation in Objects GmbH

Resilient Software Design Patterns

46

Security! © Orientation in Objects GmbH

Resilient Software Design Patterns

47

„Soll ich mich etwa 2x einloggen?“

© Orientation in Objects GmbH

Resilient Software Design Patterns

48

„Meine Session wird geteilt “

External Session Store

© Orientation in Objects GmbH

Resilient Software Design Patterns

49

Netter Nebeneffekt:

Anwendung wird zustandslos!

External Session Store

© Orientation in Objects GmbH

Resilient Software Design Patterns

50

@EnableRedisHttpSession public class SpringSessionConfig { @Bean public JedisConnectionFactory connectionFactory() { return new JedisConnectionFactory(); } }

Redis

© Orientation in Objects GmbH

Resilient Software Design Patterns

51

Problem:

Doppelte Implementierung

Redis

© Orientation in Objects GmbH

Resilient Software Design Patterns

52

External Session Store

Security

API Gateway

© Orientation in Objects GmbH

Resilient Software Design Patterns

53

External Session Store

Security

Zuul @EnableZuulProxy @EnableDiscoveryClient @SpringBootApplication public class ZuulProxy { public static void main(String[] args) { SpringApplication.run(ZuulProxy.class, args); } } © Orientation in Objects GmbH

Resilient Software Design Patterns

54

LOSE KOPPLUNG synchron © Orientation in Objects GmbH

asynchron Resilient Software Design Patterns

55

Asynchrone Kommunikation Entkoppelt Sender und Empfänger Verhindert Fehlerketten Sender muss nicht warten

Sender

© Orientation in Objects GmbH

Message Queue

Resilient Software Design Patterns

Empfänger

56

„Starbucks Does Not Use Two-Phase Commit” Kunde

Kassierer

Ausgabe

Becherwarteschlange

Barista

http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html © Orientation in Objects GmbH

Resilient Software Design Patterns

57

JmsTemplate jmsTemplate = context.getBean(JmsTemplate.class); jmsTemplate.convertAndSend("coffeeOrderQueue", new CoffeeOrder("Thorsten", "Cappuccino"));

Kassierer

coffeeOrderQueue

Barista

@Component public class Barista { @JmsListener(destination = "coffeeOrderQueue") public void receiveMessage(CoffeeOrder coffeeOrder) { System.out.println("Received "); } }

© Orientation in Objects GmbH

Resilient Software Design Patterns

58

Weiche zeitliche Anforderungen

Strict Consistency Eventual Consistency

türschloss = geschlossen

letzte_reise = 523km

(engl. „irgendwann“ nicht „eventuell“)

© Orientation in Objects GmbH

Resilient Software Design Patterns

59

Exactly OnceKommunikation notwendig Sender

Empfänger tuerschloss=offen

toggleTuerschloss()

Nicht idempotent © Orientation in Objects GmbH

Resilient Software Design Patterns

60

At Least OnceKommunikation möglich Sender

Empfänger tuerschloss=offen

schliesseTuerschloss()

Idempotent! © Orientation in Objects GmbH

Resilient Software Design Patterns

61

FALLBACK

© Orientation in Objects GmbH

Resilient Software Design Patterns

62

2. Dienst finden

3. Dienst nutzen

Verzeichnisdienst 1. registrieren

zur Erinnerung © Orientation in Objects GmbH

Resilient Software Design Patterns

63

Instanz fällt kurz NACH der Auswahl aus © Orientation in Objects GmbH

Resilient Software Design Patterns

64

Circuit Breaker

© Orientation in Objects GmbH

Resilient Software Design Patterns

65

Circuit Breaker

© Orientation in Objects GmbH

Resilient Software Design Patterns

66

Circuit Breaker errorCount = 3

© Orientation in Objects GmbH

Resilient Software Design Patterns

67

Hystrix @HystrixCommand(fallbackMethod = "fallback") public String readString() { return remoteServiceCall(); } public String fallback() { return "Fallback result"; }

© Orientation in Objects GmbH

Resilient Software Design Patterns

68

Alternative finden

Hystrix

Eureka registrieren

© Orientation in Objects GmbH

Resilient Software Design Patterns

69

Resilient Software Design

Patterns?! © Orientation in Objects GmbH

Resilient Software Design Patterns

70

Bulkheads

Parameter Checking Microservice Async Communication

Discovery Service

Exactly Once- und At Least OnceLocation Transparency Kommunikation External Session Store Idempotenz Circuit Breaker Eventual Consistency Stateless

API Gateway © Orientation in Objects GmbH

Resilient Software Design Patterns

71

?

?

?

Fragen ?

? Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de [email protected]

? 72

Vielen Dank für Ihre Aufmerksamkeit!

Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de [email protected]