Das Microservices-Praxisbuch (eBook)

Grundlagen, Konzepte und Rezepte

Eberhard Wolff (Autor)

eBook Download: PDF

2018 | 1. Auflage
328 Seiten
dpunkt (Verlag)
978-3-96088-461-3 (ISBN)

Infos

Microservices haben viele Vorteile: Effizient mehr Features umsetzen, Software schneller in Produktion bringen, Robustheit und einfache Skalierbarkeit zählen dazu. Aber die Implementierung einer Microservices-Architektur und die Auswahl der notwendigen Technologien sind schwierige Herausforderungen. Dieses Buch zeigt Microservices-Rezepte, die Architekten anpassen und zu einem Microservices-Menü kombinieren können. So kann die Implementierung der Microservices individuell auf die Anforderungen im Projekt angepasst werden. Eberhard Wolff führt zunächst in Microservices, Self-contained Systems, Mikro- und Makro-Architektur und die Migration hin zu Microservices ein. Der zweite Teil zeigt die Microservices-Rezepte: Basis-Technologien wie Docker oder PaaS, Frontend-Integration mit Links, JavaScript oder ESI (Edge Side Includes). Es schließen sich asynchrone Microservices mit Apache Kafka oder REST Atom an. Bei den synchronen Ansätzen bespricht das Buch REST mit dem Netflix-Stack, Consul und Kubernetes. Zu jedem Rezept gibt es Hinweise zu Variations- und Kombinationsmöglichkeiten. Der Ausblick greift den Betrieb von Microservices auf und zeigt außerdem, wie der Leser ganz konkret mit Microservices beginnen kann. Das Buch bietet das technische Rüstzeug, um eine Microservices-Architektur umzusetzen. Demo-Projekte und Anregungen für die Vertiefung im Selbststudium runden das Buch ab.

Eberhard Wolff arbeitet seit mehr als fünfzehn Jahren als Architekt und Berater - oft an der Schnittstelle zwischen Business und Technologie. Er ist Fellow bei der innoQ. Als Autor hat er über hundert Artikel und Bücher geschrieben - u.a. über Continuous Delivery - und als Sprecher auf internationalen Konferenzen vorgetragen. Sein technologischer Schwerpunkt liegt auf modernen Architekturansätzen - Cloud, Continuous Delivery, DevOps, Microservices oder NoSQL spielen oft eine Rolle.

Inhalt

Inhaltsverzeichnis 7
Einleitung 13
Teil I: Architekturgrundlagen 21
1 Microservices 23
1.1 Microservices: Definition 23
1.1.1 Vorteile der Microservices-Definition 24
1.1.2 Deployment-Monolith 24
1.1.3 Größe eines Microservice 24
1.2 Gründe für Microservices 25
1.2.1 Microservices zum Skalieren der Entwicklung 25
1.2.2 Legacy-Systeme ablösen 25
1.2.3 Nachhaltige Entwicklung 26
1.2.4 Continuous Delivery 27
1.2.5 Robustheit 28
1.2.6 Unabhängige Skalierung 29
1.2.7 Technologiewahlfreiheit 29
1.2.8 Sicherheit 29
1.2.9 Allgemein: Isolation 29
1.2.10 Vorteile priorisieren 30
1.2.11 Microservices sind ein Trade-Off 31
1.2.12 Zwei Ebenen von Microservices: fachlich und technisch 31
1.2.13 Typische Anzahl von Microservices in einem System 32
1.3 Herausforderungen 32
1.3.1 Vorteile und Nachteile abwägen 33
1.4 Independent-Systems-Architecture-Prinzipien (ISA) 33
1.5 Bedingungen 33
1.6 Prinzipien 33
1.7 Bewertung 34
1.8 Variationen 35
1.8.1 Technologische Varationen 35
1.8.2 Experimente 35
1.9 Fazit 36
2 Mikro- und Makro-Architektur 37
2.1 Bounded Context und Strategic Design 38
2.1.1 Ein Beispiel für eine fachliche Architektur 38
2.1.2 Domain-driven Design: Definition 39
2.1.3 Bounded Context: Definition 39
2.1.4 Strategic Design 40
2.1.5 Strategic Design Patterns 40
2.1.6 Auswahl der Patterns 44
2.1.7 Domain Events zwischen Bounded Contexts 44
2.1.8 Bounded Contexts und Microservices 44
2.2 Technische Mikro- und Makro-Architektur 44
2.2.1 Mikro- oder Makro-Architektur-Entscheidungen 45
2.2.2 Typische Makro-Architektur-Entscheidungen 46
2.2.3 Typische Mikro-Architektur-Entscheidungen 47
2.3 Betrieb: Mikro- oder Makro-Architektur 48
2.3.1 Betriebs-Makro-Architektur bei getrennter Betriebsmannschaft 49
2.3.2 Nur Technologien standardisieren! 50
2.3.3 Betriebs-Makro-Architektur testen 50
2.3.4 Betriebs-Mikro-Architektur bei »You build it – you run it« 50
2.3.5 Betrieb als Ganzes ist Mikro- oder Makro-Architektur. 51
2.4 Mikro-Architektur bevorzugen! 51
2.4.1 Evolution der Makro-Architektur 52
2.4.2 Best Practices und Beratung 52
2.5 Organisatorische Aspekte 52
2.5.1 Wildwuchs? 52
2.5.2 Wer macht Makro-Architektur? 53
2.5.3 Wie durchsetzen? 53
2.6 Variationen 54
2.6.1 Komplexere Regeln 54
2.6.2 Experimente 55
2.7 Fazit 55
3 Self-contained System (SCS) 57
3.1 Gründe für den Begriff Self-contained Systems 57
3.2 Self-contained Systems: Definition 58
3.2.1 Regeln für Kommunikation 58
3.2.2 Regeln für die Organisation 59
3.2.3 Regel: Minimale gemeinsame Basis 60
3.3 Ein Beispiel 61
3.3.1 Kommunikation 62
3.4 SCS und Microservices 62
3.5 Herausforderungen 63
3.5.1 Einschränkung auf Web-Anwendungen 63
3.5.2 Single Page App (SPA) 64
3.5.3 Mobile Anwendungen 64
3.5.4 Look & Feel
3.6 Variationen 65
3.6.1 Typische Änderungen 66
3.6.2 Kombinationsmöglichkeiten 66
3.7 Fazit 66
4 Migration 67
4.1 Gründe für eine Migration 67
4.1.1 Microservice bieten einen Neuanfang. 67
4.1.2 Gründe sind schon bekannt. 68
4.1.3 Typischer Grund: Entwicklungsgeschwindigkeit 68
4.2 Typische Migrationsstrategie 68
4.2.1 Ein typisches Szenario 69
4.2.2 Asynchrone Kommunikation bervorzugen 69
4.2.3 UI-Integration bevorzugen 70
4.2.4 Synchrone Kommunikation vermeiden 70
4.2.5 Alte Schnittstellen weiter nutzen? 71
4.2.6 Authentifizierung integrieren 71
4.2.7 Daten replizieren 71
4.2.8 Ersten Microservice für die Migration auswählen 71
4.2.9 Extreme Migrationsstrategie: alle Änderungen in Microservices 72
4.2.10 Weiteres Vorgehen: schrittweise Migration 72
4.3 Alternative Strategien 73
4.3.1 Migration nach Schichten 73
4.3.2 Copy/Change 74
4.4 Build, Betrieb und Organisation 74
4.4.1 Koexistenz Microservices und Legacy-System 75
4.4.2 Integrationstest Microservices und Legacy-System 75
4.4.3 Koordiniertes Deloyment zwischen Legacy-System und Microservices 76
4.4.4 Organisatorische Aspekte 76
4.4.5 Empfehlung: nicht alle Aspekte auf einmal umsetzen 76
4.5 Variationen 76
4.5.1 Experimente 77
4.6 Fazit 78
Teil II: Technologie-Stacks 79
5 Docker-Einführung 81
5.1 Docker für Microservices: Gründe 82
5.1.1 Prozesse reichen für Microservices nicht aus. 82
5.1.2 Virtuelle Maschinen sind zu schwergewichtig für Microservices 82
5.2 Docker-Grundlagen 83
5.2.1 Ein Prozess pro Container 84
5.2.2 Docker-Image und Docker-Registry 84
5.2.3 Unterstützte Betriebssysteme 85
5.2.4 Betriebssysteme für Docker 85
5.2.5 Überblick 86
5.2.6 Muss es immer Docker sein? 86
5.2.7 Microservices als WARs in Java Application Servern 87
5.3 Docker-Installation und Docker-Kommandos 87
5.4 Docker-Hosts mit Docker Machine installieren 87
5.4.1 Überblick 88
5.4.2 Docker-Machine-Treiber 88
5.4.3 Vorteil: getrennte Umgebungen und Docker auf Servern 89
5.5 Dockerfiles 89
5.5.1 Ein Beispiel für ein Dockerfile 90
5.5.2 Dateisystemschichten im Beispiel 90
5.5.3 Probleme mit Caching und Schichten 91
5.5.4 Docker Multi Stage Builds 91
5.5.5 Immutable Server mit Docker 92
5.5.6 Docker und Werkzeuge wie Puppet, Chef oder Ansible 92
5.6 Docker Compose 92
5.6.1 Service Discovery mit Docker-Compose-Links 93
5.6.2 Ports 93
5.6.3 Volumes 93
5.6.4 YAML-Konfiguration 93
5.6.5 Weitere Möglichkeiten 94
5.6.6 Docker-Compose-Kommandos 95
5.7 Variationen 95
5.7.1 Cluster 95
5.7.2 Docker ohne Scheduler 96
5.7.3 PaaS 97
5.7.4 Experimente 97
5.8 Fazit 97
6 Technische Mikro-Architektur 99
6.1 Anforderungen 99
6.1.1 Kommunikation 100
6.1.2 Betrieb 100
6.1.3 Neue Microservices 101
6.1.4 Resilience 101
6.2 Reactive 101
6.2.1 Reactive Programming 102
6.2.2 Klassische Server-Anwendungen 102
6.2.3 Reactive-Server-Anwendungen 102
6.2.4 Reactive Programming und das Reactive Manifesto 103
6.2.5 Reactive Programming ist für Microservices nicht notwendig. 103
6.3 Spring Boot 104
6.3.1 Java-Code 104
6.3.2 Build 105
6.3.3 spring-boot-starter-web als einzige Abhängigkeit 106
6.3.4 Spring Cloud 106
6.3.5 Maven-Plug-In 106
6.3.6 Spring Boot für Microservices? 106
6.3.7 Kommunikation 106
6.3.8 Betrieb 107
6.3.9 Neue Microservices 108
6.3.10 Resilience 109
6.4 Go 109
6.4.1 Code 109
6.4.2 Build 110
6.4.3 Docker Multi Stage Builds 110
6.4.4 Multi Stage Builds: Vorteile 111
6.4.5 Go für Microservices? 111
6.4.6 Kommunikation 111
6.4.7 Betrieb 112
6.4.8 Neue Microservices 112
6.4.9 Resilience 112
6.5 Variationen 112
6.5.1 Alternativen zu Spring Boot 113
6.6 Fazit 113
7 Konzept: Frontend-Integration 115
7.1 Frontend: Monolith oder modular? 115
7.1.1 Option: monolithisches Frontend und Backend 116
7.1.2 Option: modular entwickeltes Frontend 116
7.1.3 Gründe für einen Frontend-Monolithen 117
7.1.4 Modularisiertes Frontend 118
7.1.5 Modularisiertes Frontend und Frontend-Integration 118
7.2 Optionen 118
7.3 Resource-oriented Client Architecture (ROCA) 119
7.3.1 ROCA-Prinzipien 119
7.3.2 Vorteile der ROCA-Architektur 121
7.3.3 ROCA vs SPAs 121
7.3.4 Integrationsmöglichkeiten 121
7.4 Herausforderungen 122
7.4.1 Einheitliches Look & Feel
7.4.2 Schnittstellen in der Frontend-Integration 122
7.4.3 UI-Änderungen werden querschnittlich 122
7.5 Vorteile 123
7.5.1 Lose Kopplung 123
7.5.2 Logik und UI in einem Microservices 123
7.5.3 Freie Wahl von Frontend-Technologien 123
7.6 Variationen 124
7.7 Fazit 124
8 Rezept: Links und clientseitige Integration 127
8.1 Überblick 127
8.1.1 Suche 128
8.1.2 Postbox 128
8.1.3 Aufbau der Anwendung 129
8.1.4 Integration mit Redirects 130
8.1.5 Integration mit Links 131
8.1.6 Integration mit JavaScript 131
8.1.7 Darstellungslogik in der Postbox 132
8.1.8 Assets beim integrierten HTML 132
8.1.9 Resilience 133
8.1.10 Mit und ohne JavaScript 133
8.2 Beispiel 133
8.2.1 Aufteilung der Ports 134
8.3 Rezept-Variationen 135
8.3.1 Einfacherer JavaScript-Code 135
8.4 Experimente 136
8.5 Fazit 137
8.5.1 ROCA 137
8.5.2 Assets 137
8.5.3 Self-contained Systems 138
8.5.4 Vorteile 138
8.5.5 Herausforderungen 138
9 Rezept: serverseitige Integration mit Edge Side Includes (ESI) 139
9.1 ESI: Konzepte 139
9.1.1 Caches implementieren ESI 140
9.1.2 CDN implementieren ESI. 140
9.2 Beispiel 140
9.2.1 Beispiel ablaufen lassen 142
9.3 Varnish 142
9.3.1 Lizenz und Support 142
9.3.2 Caching mit HTTP und HTTP-Headern 142
9.3.3 Varnish-Docker-Container 143
9.3.4 Varnish-Konfiguration 143
9.3.5 Bewertung von VCL 144
9.3.6 Order-Microservice 144
9.3.7 HTML mit ESI-Tags im Beispiel 145
9.3.8 ESI-Tags im head 145
9.3.9 ESI-Tags im restlichen HTML 145
9.3.10 Ergebnis: HTML beim Browser 145
9.3.11 Keine Tests ohne ESI-Infrastruktur 146
9.3.12 Auswirkungen auf die Anwendungen 146
9.3.13 Common-Microservice 146
9.3.14 Asset-Server 147
9.4 Rezept-Variationen 147
9.4.1 SSI 147
9.4.2 Tailor 148
9.4.3 Clientseitige Integration 148
9.4.4 Gemeinsame Bibliothek 148
9.4.5 Weitere Integration 148
9.5 Experimente 149
9.6 Fazit 150
9.6.1 Vorteile 150
9.6.2 Herausforderungen 150
10 Konzept: Asynchrone Microservices 151
10.1 Definition 151
10.1.1 Asynchrone Kommunikation ohne Antwort 153
10.1.2 Datenreplikation und Bounded Context 153
10.1.3 Synchrone Kommunikationsprotokolle 153
10.1.4 Asynchrone Kommunikationsprotokolle 153
10.2 Events 154
10.2.1 Events und DDD 154
10.2.2 Pattern aus dem Strategic Design 155
10.2.3 Minimale Daten im Event schicken 155
10.2.4 Event Sourcing 155
10.2.5 Eigener oder gemeinsamer Event Store? 156
10.3 Herausforderungen 157
10.3.1 Inkonsistenz 157
10.3.2 CAP-Theorem 157
10.3.3 Begründung des CAP-Theorems 158
10.3.4 Kompromisse bei CAP 159
10.3.5 CAP, Events und Datenreplikation 159
10.3.6 Sind Inkonsistenzen akzeptabel? 159
10.3.7 Inkonsistenzen reparieren 160
10.3.8 Garantierte Zustellung 160
10.3.9 Idempotenz 161
10.3.10 Ein Empfänger 161
10.3.11 Test 161
10.4 Vorteile 162
10.5 Variationen 162
10.6 Fazit 163
11 Rezept: Messaging und Kafka 165
11.1 Message-oriented Middleware (MOM) 165
11.1.1 Spielarten von MOMs 166
11.2 Die Architektur von Kafka 166
11.2.1 Kafka speichert die Nachrichten-Historie. 167
11.2.2 Kafka: Lizenz und Committer 167
11.2.3 APIs 167
11.2.4 Records 167
11.2.5 Topics 168
11.2.6 Partitionen 168
11.2.7 Commit 168
11.2.8 Polling 169
11.2.9 Records, Topics, Partitionen und Commits im Überblick 169
11.2.10 Replikation 170
11.2.11 Leader und Follower 170
11.2.12 Schreiben wiederholen 170
11.2.13 Consumer Groups 171
11.2.14 Persistenz 171
11.2.15 Log Compaction 172
11.3 Events mit Kafka 172
11.3.1 Events verschicken 172
11.4 Beispiel 173
11.4.1 Datenmodell für die Kommunikation 173
11.4.2 Domain-Driven Design und Strategic Design 174
11.4.3 Technische Umsetzung der Kommunikation 174
11.4.4 Datenmodell für die Datenbank 175
11.4.5 Inkonsistenzen 176
11.4.6 Technischer Aufbau 176
11.4.7 Key für die Records 177
11.4.8 Alle Informationen über die Bestellung im Record mitschicken 178
11.4.9 Aufteilung der Records auf Partitionen selber implementieren 178
11.4.10 Technische Parameter der Partitionen und Topics 178
11.4.11 Keine Replikation im Beispiel 179
11.4.12 Producer 179
11.4.13 Consumer 180
11.4.14 Consumer Groups 180
11.4.15 Tests mit Embedded Kafka 181
11.4.16 Avro als Datenformat 181
11.5 Rezept-Variationen 182
11.5.1 Andere MOM 182
11.6 Experimente 183
11.7 Fazit 184
11.7.1 Vorteile 184
11.7.2 Herausforderungen 184
12 Rezept: Asynchrone Kommunikation mit Atom und REST 185
12.1 Das Atom-Format 185
12.1.1 MIME-Typ 186
12.1.2 Feed 186
12.1.3 Entry 187
12.1.4 Tools 188
12.1.5 Effizientes Polling des Atom-Feeds 188
12.1.6 HTTP-Caching 189
12.1.7 ETags 190
12.1.8 Paginierung und Filterung 190
12.1.9 Push vs. Pull 191
12.1.10 Alte Ereignisse 191
12.2 Beispiel 191
12.2.1 Technische Umsetzung des Atom Views 193
12.2.2 Umsetzung des Controllers 193
12.2.3 Umsetzung des HTTP-Caching auf dem Server 193
12.2.4 Umsetzung des HTTP-Caching auf dem Client 194
12.2.5 Verarbeitung der Daten und Skalierung 194
12.2.6 Atom kann keine Daten an nur einen Empfänger schicken. 195
12.3 Rezept-Variationen 195
12.3.1 RSS 195
12.3.2 JSON-Feed 196
12.3.3 Eigenes Datenformat 196
12.3.4 Alternativen zu HTTP 196
12.3.5 Event-Daten mitschicken 197
12.4 Experimente 197
12.5 Fazit 198
12.5.1 Vorteile 199
12.5.2 Herausforderungen 199
13 Konzept: Synchrone Microservices 201
13.1 Definition 201
13.1.1 Ein Beispiel 202
13.1.2 Konsistenz 203
13.1.3 Bounded Context 203
13.1.4 Tests 203
13.1.5 Stubs 204
13.1.6 Consumer-driven Contract Tests 204
13.1.7 Das Pact-Test-Framework 204
13.2 Herausforderungen 204
13.2.1 Technische Lösungen 205
13.2.2 API-Gateways 206
13.3 Vorteile 207
13.4 Variationen 207
13.5 Fazit 208
14 Rezept: REST mit dem Netflix-Stack 209
14.1 Beispiel 209
14.1.1 Architektur des Beispiels 210
14.1.2 Beispiel bauen 210
14.1.3 Docker-Container und Ports 211
14.2 Eureka: Service Discovery 211
14.2.1 Server 212
14.2.2 Client 214
14.2.3 Registrierung 214
14.2.4 Andere Programmiersprachen 215
14.2.5 Sidecars 215
14.2.6 Zugriff auf andere Services 215
14.3 Router: Zuul 215
14.3.1 Zuul vs. Reverse Proxy 216
14.3.2 Zuul im Beispiel 216
14.4 Lastverteilung: Ribbon 217
14.4.1 Zentraler Load Balancer 217
14.4.2 Clientseitiges Load Balancing 217
14.4.3 Ribbon-API 218
14.4.4 Ribbon mit Consul 218
14.4.5 RestTemplate 219
14.5 Resilience: Hystrix 219
14.5.1 Resilience-Patterns 219
14.5.2 Implementierung 220
14.5.3 Monitoring 221
14.5.4 Hystrix-Dashboard 221
14.5.5 Andere Monitoring-Möglichkeiten 222
14.5.6 Turbine 222
14.6 Rezept-Variationen 223
14.7 Experimente 224
14.8 Fazit 226
14.8.1 Vorteile 226
14.8.2 Herausforderungen 226
15 Rezept: REST mit Consul und Apache httpd 227
15.1 Beispiel 227
15.1.1 Architektur des Beispiels 228
15.1.2 Beispiel bauen 229
15.2 Service Discovery: Consul 229
15.2.1 Consul Dashboard 230
15.2.2 Daten mit DNS auslesen 231
15.2.3 Consul-Docker-Image 231
15.3 Routing: Apache httpd 232
15.3.1 Reverse Proxy 232
15.3.2 Load Balancer 232
15.4 Consul Template 232
15.4.1 Das Template 233
15.4.2 Consul Template starten 233
15.4.3 Fazit 234
15.5 Consul und Spring Boot 234
15.5.1 Code-Abhängigkeiten 234
15.5.2 Health-Check mit Spring Boot Actuator 235
15.5.3 Consul und Ribbon 235
15.6 DNS und Registrator 235
15.6.1 Aufbau des Beispiels 235
15.6.2 Konfiguration ebenfalls transparent möglich 236
15.7 Rezept-Variationen 237
15.7.1 Kombination mit Frontend-Integration 237
15.7.2 Kombination mit asynchroner Kommunikation 237
15.7.3 Andere Load Balancer 237
15.8 Experimente 237
15.9 Fazit 239
15.9.1 Vorteile 240
15.9.2 Herausforderungen 240
16 Konzept: Microservices-Plattformen 241
16.1 Definition 241
16.1.1 Unterstützung für HTTP und REST 241
16.1.2 Aufwand bei Installation und Betrieb 242
16.1.3 Migration auf eine Microservices-Plattform 242
16.1.4 Einfluss auf die Makro-Architektur 243
16.1.5 Konkrete Plattformen 243
16.2 Variationen 244
16.2.1 Physische Hardware 244
16.2.2 Virtuelle Hardware 244
16.3 Fazit 245
17 Rezept: Docker-Container mit Kubernetes 247
17.1 Kubernetes 247
17.1.1 Lizenz und Community 247
17.1.2 Kubernetes-Versionen 247
17.1.3 Features 248
17.1.4 Kubernetes-Konzepte 248
17.2 Das Beispiel mit Kubernetes 249
17.2.1 Implementierung der Microservices mit Kubernetes 250
17.2.2 Service Discovery 250
17.2.3 Ausfallsicherheit 250
17.2.4 Lastverteilung 250
17.2.5 Service Discovery, Ausfallsicherheit und Lastverteilung ohne Code-Abhängigkeiten 251
17.2.6 Routing mit Apache httpd 251
17.2.7 Routing mit Node-Ports 251
17.2.8 Routing mit Load Balancern 251
17.2.9 Routing mit Ingress 252
17.3 Beispiel im Detail 252
17.3.1 Einige Minikube-Befehle 253
17.4 Weitere Kubernetes-Features 254
17.4.1 Monitoring mit Liveness und Readiness Probes 254
17.4.2 Konfiguration 255
17.4.3 Kubernetes-Umgebungen mit Namespaces trennen 255
17.4.4 Anwendungen mit Zustand 255
17.4.5 Erweiterungen mit Helm 256
17.5 Rezept-Variationen 256
17.5.1 MOMs in Kubernetes 256
17.5.2 Frontend-Integration mit Kubernetes 256
17.5.3 Docker Swarm und Docker Compose 257
17.5.4 Docker vs. Virtualisierung 257
17.6 Experimente 257
17.7 Fazit 259
17.7.1 Vorteile 260
17.7.2 Herausforderungen 260
18 Rezept: PaaS mit Cloud Foundry 261
18.1 PaaS: Definition 261
18.1.1 IaaS 261
18.1.2 SaaS 261
18.1.3 PaaS 262
18.1.4 PaaS schränken Flexibilität und Kontrolle ein. 262
18.1.5 Routing und Skalierung 262
18.1.6 Weitere Dienste 262
18.1.7 Public Cloud 263
18.1.8 PaaS im eigenen Rechenzentrum 263
18.1.9 Makro-Architektur 263
18.2 Cloud Foundry 264
18.2.1 Flexibilität 264
18.3 Das Beispiel mit Cloud Foundry 265
18.3.1 Cloud Foundry starten 265
18.3.2 Deployment der Microservices 266
18.3.3 Keine Code-Abhängigkeiten für Routing 267
18.3.4 Datenbank und andere Services nutzen 268
18.3.5 Beispiel für einen Service aus dem Marketplace 268
18.3.6 Services in Anwendungen nutzen 268
18.3.7 Services für asynchrone Kommunikation 269
18.4 Rezept-Variationen 269
18.5 Experimente 269
18.6 Serverless 270
18.6.1 REST mit AWS Lambda und dem API Gateway 271
18.6.2 Glue Code 271
18.7 Fazit 271
18.7.1 Vorteile 272
18.7.2 Herausforderungen 272
Teil III: Betrieb 273
19 Konzept: Betrieb 275
19.1 Warum Betrieb wichtig ist 275
19.1.1 Viele Microservices 275
19.1.2 Ergebnisse von Experimenten überprüfen 276
19.1.3 Verteiltes System 276
19.1.4 Schnellere Reaktion 277
19.1.5 Ergänzungen zu Tests 277
19.1.6 Dynamische Skalierung 278
19.2 Ansätze für den Betrieb von Microservices 278
19.2.1 Unabhängiges Deployment 279
19.2.2 Schrittweiser Aufbau des Betriebs 280
19.3 Auswirkungen der behandelten Technologien 280
19.4 Fazit 281
20 Rezept: Monitoring mit Prometheus 283
20.1 Grundlagen 283
20.1.1 Verarbeitung der Metriken 284
20.1.2 Unterschiedliche Metriken für unterschiedliche Stakeholder 285
20.2 Metriken bei Microservices 285
20.2.1 Mehr Services, mehr Metriken 285
20.2.2 Service statt Instanzen 285
20.2.3 Weg von Systemmetriken 286
20.2.4 Hin zu Applikationsmetriken 286
20.2.5 Fachliche Alerts 286
20.3 Metriken mit Prometheus 287
20.3.1 Beispiel für multidimensionale Metriken 287
20.4 Beispiel mit Prometheus 290
20.4.1 Umgebung starten 290
20.4.2 Code in Spring Boot 291
20.4.3 Prometheus-Konfiguration 291
20.4.4 Konfiguration im Beispiel 291
20.5 Rezept-Variationen 292
20.5.1 Weitere Werkzeuge 292
20.6 Experimente 293
20.6.1 Experimente: Metriken auswählen 293
20.6.2 Experimente: Prometheus ausbauen 293
20.7 Fazit 295
20.7.1 Vorteile 295
20.7.2 Herausforderungen 295
21 Rezept: Log-Analyse mit dem Elastic Stack 297
21.1 Grundlagen 297
21.1.1 Warum Logs? 297
21.1.2 Log bei Microservices 298
21.1.3 Log-Informationen 298
21.1.4 Logs verschicken und nicht speichern 299
21.1.5 Werkzeug: Map/Reduce 299
21.1.6 Werkzeug: Suchmaschinen 300
21.1.7 Elasticsearch 300
21.2 Logging mit dem Elastic Stack 300
21.3 Beispiel 302
21.4 Rezept-Variationen 304
21.5 Experimente 304
21.6 Fazit 305
21.6.1 Vorteile 305
21.6.2 Herausforderungen 305
22 Rezept: Tracing mit Zipkin 307
22.1 Grundlagen 307
22.1.1 Tracing notwendig? 307
22.2 Tracing mit Zipkin 308
22.2.1 Zipkin: Aufbau 308
22.2.2 Trace- und Span-ID 309
22.2.3 Tracing im Beispiel 309
22.3 Beispiel 311
22.4 Rezept-Variationen 312
22.5 Fazit 312
22.5.1 Vorteile 312
22.5.2 Herausforderungen 312
23 Und nun? 313
A Installation der Umgebung 317
B Maven-Kommandos 319
C Docker- und Docker-Compose- Kommandos 321
Index 325
www.dpunkt.de 0

Produkt-Details

• Erscheint lt. Verlag: 2.3.2018
• Verlagsort: Heidelberg
• Sprache: deutsch
• Themenwelt: Mathematik / Informatik ► Informatik
• Schlagworte: Continuous Delivery • DevOps • Docker • IaaS • Java • Java EE • Microservice • Nanoservices • Netflix • Paas • SaaS • SOA • Softwarearchitektur • Spring Boot • Vagrant • Vert.x
• ISBN-10: 3-96088-461-3 / 3960884613
• ISBN-13: 978-3-96088-461-3 / 9783960884613