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
1
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
2
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
3
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
4
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
5
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
6
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
7
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
8
© Orientation in Objects GmbH
Resilient Software Design Patterns
17
© Orientation in Objects GmbH
Resilient Software Design Patterns
18
9
BULKHEADS © Orientation in Objects GmbH
Resilient Software Design Patterns
19
Bulkheads im Kleinen:
Methodenaufrufe
© Orientation in Objects GmbH
Resilient Software Design Patterns
20
10
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
11
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
12
3 Bausteine
© Orientation in Objects GmbH
Resilient Software Design Patterns
25
Resilient Software Design Patterns
26
Anwendung mit 3 Bausteinen
© Orientation in Objects GmbH
13
Anwendung mit 3 Bausteinen
Deployment auf einem Server
© Orientation in Objects GmbH
Resilient Software Design Patterns
27
Resilient Software Design Patterns
28
Anwendung mit 3 Bausteinen
Baustein © Orientation in Objects GmbH
wird 4 mal benötigt
14
Anwendung mit 3 Bausteinen
Nachteile wird nur 2 mal benötigt Änderung an erfordert Reploy von
Baustein
wird 4 mal benötigt Resilient Software Design Patterns
© Orientation in Objects GmbH
Anwendung mit 3 Bausteinen
Baustein © Orientation in Objects GmbH
29
Unabhängige Artefakte
wird 4 mal benötigt Resilient Software Design Patterns
30
15
Anwendung mit 3 Bausteinen
Baustein
wird 4 mal benötigt
Unabhängige Artefakte
Flexible Skalierung auf 3 Server Resilient Software Design Patterns
© Orientation in Objects GmbH
Vorteile
31
Unabhängige Artefakte
Isolierte Entwicklung Isolierte Fehler Isoliertes Deployment …
Flexible Skalierung auf 3 Server © Orientation in Objects GmbH
Resilient Software Design Patterns
32
16
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
17
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
18
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
19
LOSE KOPPLUNG
Resilient Software Design Patterns
© Orientation in Objects GmbH
39
LOSE KOPPLUNG synchron © Orientation in Objects GmbH
asynchron Resilient Software Design Patterns
40
20
? Startet gerade
nicht erreichbar
Mit wem kann / soll ich kommunizieren? Resilient Software Design Patterns
© Orientation in Objects GmbH
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
21
2. Dienst finden
3. Dienst nutzen
Verzeichnisdienst 1. registrieren
Resilient Software Design Patterns
© Orientation in Objects GmbH
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
22
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
23
Security! © Orientation in Objects GmbH
Resilient Software Design Patterns
47
Resilient Software Design Patterns
48
„Soll ich mich etwa 2x einloggen?“
© Orientation in Objects GmbH
24
„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
25
@EnableRedisHttpSession public class SpringSessionConfig { @Bean public JedisConnectionFactory connectionFactory() { return new JedisConnectionFactory(); } }
Redis
Resilient Software Design Patterns
© Orientation in Objects GmbH
51
Problem:
Doppelte Implementierung
Redis
© Orientation in Objects GmbH
Resilient Software Design Patterns
52
26
External Session Store
Security API Gateway
Resilient Software Design Patterns
© Orientation in Objects GmbH
External Session Store
53
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
27
LOSE KOPPLUNG asynchron
synchron Resilient Software Design Patterns
© Orientation in Objects GmbH
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
28
„Starbucks Does Not Use Two-Phase Commit” Kunde
Kassierer
Becherwarteschlange
Ausgabe
Barista
http://www.enterpriseintegrationpatterns.com/ramblings/18_starbucks.html Resilient Software Design Patterns
© Orientation in Objects GmbH
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
29
Weiche zeitliche Anforderungen
Strict Consistency Eventual Consistency
türschloss = geschlossen
letzte_reise = 523km
(engl. „irgendwann“ nicht „eventuell“)
Resilient Software Design Patterns
© Orientation in Objects GmbH
59
Exactly OnceKommunikation notwendig Sender
Empfänger tuerschloss=offen
toggleTuerschloss()
Nicht idempotent © Orientation in Objects GmbH
Resilient Software Design Patterns
60
30
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
31
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
32
Circuit Breaker
© Orientation in Objects GmbH
Resilient Software Design Patterns
65
Circuit Breaker
© Orientation in Objects GmbH
Resilient Software Design Patterns
66
33
Circuit Breaker errorCount = 3
© Orientation in Objects GmbH
Resilient Software Design Patterns
67
Resilient Software Design Patterns
68
Hystrix @HystrixCommand(fallbackMethod = "fallback") public String readString() { return remoteServiceCall(); } public String fallback() { return "Fallback result"; }
© Orientation in Objects GmbH
34
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
35
Bulkheads Parameter Checking Microservice Async Communication
Discovery Service
Exactly Once- und At Least OnceLocation Transparency Kommunikation External Session Store Idempotenz Circuit Breaker Stateless Eventual Consistency API Gateway Resilient Software Design Patterns
© Orientation in Objects GmbH
71
? ? ? ? ? ?
?
?
Fragen ?
Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de
[email protected]
72
36
Vielen Dank für Ihre Aufmerksamkeit!
Orientation in Objects GmbH Weinheimer Str. 68 68309 Mannheim www.oio.de
[email protected]
ZENTRALE DIENSTE
© Orientation in Objects GmbH
Resilient Software Design Patterns
74
37
Wo liegt unsere Konfiguration? db.url=green.dbserver.de
db.url=blue.dbserver.de db.url=green.dbserver.de
db.url=yellow.dbserver.de
© Orientation in Objects GmbH
Resilient Software Design Patterns
75
Central Configuration
© Orientation in Objects GmbH
Resilient Software Design Patterns
76
38
@SpringBootApplication @EnableConfigServer public class ConfigServerApplication { public static void main(String[] args) { SpringApplication.run(ConfigServerApplication.class, args); } }
Spring Cloud Config
© Orientation in Objects GmbH
Resilient Software Design Patterns
77
@SpringBootApplication @EnableConfigServer public class ConfigServerApplication { public static void main(String[] args) { SpringApplication.run(ConfigServerApplication.class, args); } }
Spring Cloud Config
@Value("${db.url}") private String url;
© Orientation in Objects GmbH
Resilient Software Design Patterns
78
39
