Sie sind hier

E-Book

Das Microservices-Praxisbuch

Grundlagen, Konzepte und Rezepte

Autor	Eberhard Wolff
Verlag	dpunkt
Erscheinungsjahr	2018
Seitenanzahl	328 Seiten
ISBN	9783960884613
Format	PDF
Kopierschutz	Wasserzeichen/DRM
Geräte	PC/MAC/eReader/Tablet
Preis	36,90 EUR

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.

Kaufen Sie hier:

Horizontale Tabs

Blick ins Buch

Inhaltsverzeichnis

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

Weitere E-Books zum Thema: Informatik - Algorithmen - Softwaresysteme

Einführung in die Informatik für Naturwissenschaftler und Ingenieure

Format: PDF

Grundlagenwissen im Bereich Informatik Es gibt kaum ein technisches oder naturwissenschaftliches Problem, das nicht von der Informatik beeinflusst wird. Deshalb gehören die Grundlagen der…

Einführung in die Informatik für Naturwissenschaftler und Ingenieure

Format: PDF

Grundlagenwissen im Bereich Informatik Es gibt kaum ein technisches oder naturwissenschaftliches Problem, das nicht von der Informatik beeinflusst wird. Deshalb gehören die Grundlagen der…

Einführung in die Informatik für Naturwissenschaftler und Ingenieure

Format: PDF

Grundlagenwissen im Bereich Informatik Es gibt kaum ein technisches oder naturwissenschaftliches Problem, das nicht von der Informatik beeinflusst wird. Deshalb gehören die Grundlagen der…

Softwaretechnik

Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Softwaretechnik

Format: PDF

Software-Projekte geraten oft in Schwierigkeiten: Zeit und Budget werden überschritten; das Projekt tritt auf der Stelle; im schlimmsten Fall wird es ohne Ergebnis abgebrochen. Manche…

Software Engineering

Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Software Engineering

Architektur-Design und Prozessorientierung Format: PDF

Das Lehrbuch behandelt alle Aspekte der Software-Entwicklung, besonders aber Methoden und Richtlinien zur Herstellung großer und qualitativ hochwertiger Softwareprodukte. Es vermittelt das zur…

Corporate Performance Management mit Business Intelligence Werkzeugen

Format: PDF

Vertrauen ist gut - Corporate Performance Management ist besser - Management- und Technologieaspekte werden gemeinsam und verständlich dargestellt - Zahlreiche Praxisbeispiele aus der…

Corporate Performance Management mit Business Intelligence Werkzeugen

Format: PDF

Vertrauen ist gut - Corporate Performance Management ist besser - Management- und Technologieaspekte werden gemeinsam und verständlich dargestellt - Zahlreiche Praxisbeispiele aus der…

Weitere Zeitschriften

A&D - Automation & Digitalisierung

Rubriken: Digital Factory - Industrielle Softwarelösungen - Robotik & Handling - Antreiben & Bewegen - Industrielle Kommunikation - Steuerungstechnik - Sensorik & Messtechnik - ...

Arzneimittel Zeitung

Die Arneimittel Zeitung ist die Zeitung für Entscheider und Mitarbeiter in der Pharmabranche. Sie informiert branchenspezifisch über Gesundheits- und Arzneimittelpolitik, über Unternehmen und ...

aufstieg

Zeitschrift der NaturFreunde in Württemberg Die Natur ist unser Lebensraum: Ort für Erholung und Bewegung, zum Erleben und Forschen; sie ist ein schützenswertes Gut. Wir sind aktiv in der Natur ...

FREIE WERKSTATT

Die Fachzeitschrift FREIE WERKSTATT berichtet seit der ersten Ausgaben 1994 über die Entwicklungen des Independent Aftermarkets (IAM). Hauptzielgruppe sind Inhaberinnen und Inhaber, Kfz-Meisterinnen ...

Berufsstart Bewerbung

»Berufsstart Bewerbung« erscheint jährlich zum Wintersemester im November mit einer Auflage von 50.000 Exemplaren und ermöglicht Unternehmen sich bei Studenten und Absolventen mit einer ...

bank und markt

Zeitschrift für Banking - die führende Fachzeitschrift für den Markt und Wettbewerb der Finanzdienstleister, erscheint seit 1972 monatlich. Leitthemen Absatz und Akquise im Multichannel ...

cards Karten cartes

Die führende Zeitschrift für Zahlungsverkehr und Payments – international und branchenübergreifend, erscheint seit 1990 monatlich (viermal als Fachmagazin, achtmal als ...

Computerwoche

Die COMPUTERWOCHE berichtet schnell und detailliert über alle Belange der Informations- und Kommunikationstechnik in Unternehmen – über Trends, neue Technologien, Produkte und Märkte. IT-Manager ...

elektrobörse handel

elektrobörse handel gibt einen facettenreichen Überblick über den Elektrogerätemarkt: Produktneuheiten und -trends, Branchennachrichten, Interviews, Messeberichte uvm.. In den monatlichen ...

VideoMarkt

VideoMarkt – besser unterhalten. VideoMarkt deckt die gesamte Videobranche ab: Videoverkauf, Videoverleih und digitale Distribution. Das komplette Serviceangebot von VideoMarkt unterstützt die ...