Sie sind hier
E-Book

Das Microservices-Praxisbuch

Grundlagen, Konzepte und Rezepte

AutorEberhard Wolff
Verlagdpunkt
Erscheinungsjahr2018
Seitenanzahl328 Seiten
ISBN9783960884613
FormatPDF
KopierschutzWasserzeichen/DRM
GerätePC/MAC/eReader/Tablet
Preis36,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
Inhaltsverzeichnis7
Einleitung13
Teil I: Architekturgrundlagen21
1 Microservices23
1.1 Microservices: Definition23
1.1.1 Vorteile der Microservices-Definition24
1.1.2 Deployment-Monolith24
1.1.3 Größe eines Microservice24
1.2 Gründe für Microservices25
1.2.1 Microservices zum Skalieren der Entwicklung25
1.2.2 Legacy-Systeme ablösen25
1.2.3 Nachhaltige Entwicklung26
1.2.4 Continuous Delivery27
1.2.5 Robustheit28
1.2.6 Unabhängige Skalierung29
1.2.7 Technologiewahlfreiheit29
1.2.8 Sicherheit29
1.2.9 Allgemein: Isolation29
1.2.10 Vorteile priorisieren30
1.2.11 Microservices sind ein Trade-Off31
1.2.12 Zwei Ebenen von Microservices: fachlich und technisch31
1.2.13 Typische Anzahl von Microservices in einem System32
1.3 Herausforderungen32
1.3.1 Vorteile und Nachteile abwägen33
1.4 Independent-Systems-Architecture-Prinzipien (ISA)33
1.5 Bedingungen33
1.6 Prinzipien33
1.7 Bewertung34
1.8 Variationen35
1.8.1 Technologische Varationen35
1.8.2 Experimente35
1.9 Fazit36
2 Mikro- und Makro-Architektur37
2.1 Bounded Context und Strategic Design38
2.1.1 Ein Beispiel für eine fachliche Architektur38
2.1.2 Domain-driven Design: Definition39
2.1.3 Bounded Context: Definition39
2.1.4 Strategic Design40
2.1.5 Strategic Design Patterns40
2.1.6 Auswahl der Patterns44
2.1.7 Domain Events zwischen Bounded Contexts44
2.1.8 Bounded Contexts und Microservices44
2.2 Technische Mikro- und Makro-Architektur44
2.2.1 Mikro- oder Makro-Architektur-Entscheidungen45
2.2.2 Typische Makro-Architektur-Entscheidungen46
2.2.3 Typische Mikro-Architektur-Entscheidungen47
2.3 Betrieb: Mikro- oder Makro-Architektur48
2.3.1 Betriebs-Makro-Architektur bei getrennter Betriebsmannschaft49
2.3.2 Nur Technologien standardisieren!50
2.3.3 Betriebs-Makro-Architektur testen50
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-Architektur52
2.4.2 Best Practices und Beratung52
2.5 Organisatorische Aspekte52
2.5.1 Wildwuchs?52
2.5.2 Wer macht Makro-Architektur?53
2.5.3 Wie durchsetzen?53
2.6 Variationen54
2.6.1 Komplexere Regeln54
2.6.2 Experimente55
2.7 Fazit55
3 Self-contained System (SCS)57
3.1 Gründe für den Begriff Self-contained Systems57
3.2 Self-contained Systems: Definition58
3.2.1 Regeln für Kommunikation58
3.2.2 Regeln für die Organisation59
3.2.3 Regel: Minimale gemeinsame Basis60
3.3 Ein Beispiel61
3.3.1 Kommunikation62
3.4 SCS und Microservices62
3.5 Herausforderungen63
3.5.1 Einschränkung auf Web-Anwendungen63
3.5.2 Single Page App (SPA)64
3.5.3 Mobile Anwendungen64
3.5.4 Look & Feel65
3.6 Variationen65
3.6.1 Typische Änderungen66
3.6.2 Kombinationsmöglichkeiten66
3.7 Fazit66
4 Migration67
4.1 Gründe für eine Migration67
4.1.1 Microservice bieten einen Neuanfang.67
4.1.2 Gründe sind schon bekannt.68
4.1.3 Typischer Grund: Entwicklungsgeschwindigkeit68
4.2 Typische Migrationsstrategie68
4.2.1 Ein typisches Szenario69
4.2.2 Asynchrone Kommunikation bervorzugen69
4.2.3 UI-Integration bevorzugen70
4.2.4 Synchrone Kommunikation vermeiden70
4.2.5 Alte Schnittstellen weiter nutzen?71
4.2.6 Authentifizierung integrieren71
4.2.7 Daten replizieren71
4.2.8 Ersten Microservice für die Migration auswählen71
4.2.9 Extreme Migrationsstrategie: alle Änderungen in Microservices72
4.2.10 Weiteres Vorgehen: schrittweise Migration72
4.3 Alternative Strategien73
4.3.1 Migration nach Schichten73
4.3.2 Copy/Change74
4.4 Build, Betrieb und Organisation74
4.4.1 Koexistenz Microservices und Legacy-System75
4.4.2 Integrationstest Microservices und Legacy-System75
4.4.3 Koordiniertes Deloyment zwischen Legacy-System und Microservices76
4.4.4 Organisatorische Aspekte76
4.4.5 Empfehlung: nicht alle Aspekte auf einmal umsetzen76
4.5 Variationen76
4.5.1 Experimente77
4.6 Fazit78
Teil II: Technologie-Stacks79
5 Docker-Einführung81
5.1 Docker für Microservices: Gründe82
5.1.1 Prozesse reichen für Microservices nicht aus.82
5.1.2 Virtuelle Maschinen sind zu schwergewichtig für Microservices82
5.2 Docker-Grundlagen83
5.2.1 Ein Prozess pro Container84
5.2.2 Docker-Image und Docker-Registry84
5.2.3 Unterstützte Betriebssysteme85
5.2.4 Betriebssysteme für Docker85
5.2.5 Überblick86
5.2.6 Muss es immer Docker sein?86
5.2.7 Microservices als WARs in Java Application Servern87
5.3 Docker-Installation und Docker-Kommandos87
5.4 Docker-Hosts mit Docker Machine installieren87
5.4.1 Überblick88
5.4.2 Docker-Machine-Treiber88
5.4.3 Vorteil: getrennte Umgebungen und Docker auf Servern89
5.5 Dockerfiles89
5.5.1 Ein Beispiel für ein Dockerfile90
5.5.2 Dateisystemschichten im Beispiel90
5.5.3 Probleme mit Caching und Schichten91
5.5.4 Docker Multi Stage Builds91
5.5.5 Immutable Server mit Docker92
5.5.6 Docker und Werkzeuge wie Puppet, Chef oder Ansible92
5.6 Docker Compose92
5.6.1 Service Discovery mit Docker-Compose-Links93
5.6.2 Ports93
5.6.3 Volumes93
5.6.4 YAML-Konfiguration93
5.6.5 Weitere Möglichkeiten94
5.6.6 Docker-Compose-Kommandos95
5.7 Variationen95
5.7.1 Cluster95
5.7.2 Docker ohne Scheduler96
5.7.3 PaaS97
5.7.4 Experimente97
5.8 Fazit97
6 Technische Mikro-Architektur99
6.1 Anforderungen99
6.1.1 Kommunikation100
6.1.2 Betrieb100
6.1.3 Neue Microservices101
6.1.4 Resilience101
6.2 Reactive101
6.2.1 Reactive Programming102
6.2.2 Klassische Server-Anwendungen102
6.2.3 Reactive-Server-Anwendungen102
6.2.4 Reactive Programming und das Reactive Manifesto103
6.2.5 Reactive Programming ist für Microservices nicht notwendig.103
6.3 Spring Boot104
6.3.1 Java-Code104
6.3.2 Build105
6.3.3 spring-boot-starter-web als einzige Abhängigkeit106
6.3.4 Spring Cloud106
6.3.5 Maven-Plug-In106
6.3.6 Spring Boot für Microservices?106
6.3.7 Kommunikation106
6.3.8 Betrieb107
6.3.9 Neue Microservices108
6.3.10 Resilience109
6.4 Go109
6.4.1 Code109
6.4.2 Build110
6.4.3 Docker Multi Stage Builds110
6.4.4 Multi Stage Builds: Vorteile111
6.4.5 Go für Microservices?111
6.4.6 Kommunikation111
6.4.7 Betrieb112
6.4.8 Neue Microservices112
6.4.9 Resilience112
6.5 Variationen112
6.5.1 Alternativen zu Spring Boot113
6.6 Fazit113
7 Konzept: Frontend-Integration115
7.1 Frontend: Monolith oder modular?115
7.1.1 Option: monolithisches Frontend und Backend116
7.1.2 Option: modular entwickeltes Frontend116
7.1.3 Gründe für einen Frontend-Monolithen117
7.1.4 Modularisiertes Frontend118
7.1.5 Modularisiertes Frontend und Frontend-Integration118
7.2 Optionen118
7.3 Resource-oriented Client Architecture (ROCA)119
7.3.1 ROCA-Prinzipien119
7.3.2 Vorteile der ROCA-Architektur121
7.3.3 ROCA vs SPAs121
7.3.4 Integrationsmöglichkeiten121
7.4 Herausforderungen122
7.4.1 Einheitliches Look & Feel122
7.4.2 Schnittstellen in der Frontend-Integration122
7.4.3 UI-Änderungen werden querschnittlich122
7.5 Vorteile123
7.5.1 Lose Kopplung123
7.5.2 Logik und UI in einem Microservices123
7.5.3 Freie Wahl von Frontend-Technologien123
7.6 Variationen124
7.7 Fazit124
8 Rezept: Links und clientseitige Integration127
8.1 Überblick127
8.1.1 Suche128
8.1.2 Postbox128
8.1.3 Aufbau der Anwendung129
8.1.4 Integration mit Redirects130
8.1.5 Integration mit Links131
8.1.6 Integration mit JavaScript131
8.1.7 Darstellungslogik in der Postbox132
8.1.8 Assets beim integrierten HTML132
8.1.9 Resilience133
8.1.10 Mit und ohne JavaScript133
8.2 Beispiel133
8.2.1 Aufteilung der Ports134
8.3 Rezept-Variationen135
8.3.1 Einfacherer JavaScript-Code135
8.4 Experimente136
8.5 Fazit137
8.5.1 ROCA137
8.5.2 Assets137
8.5.3 Self-contained Systems138
8.5.4 Vorteile138
8.5.5 Herausforderungen138
9 Rezept: serverseitige Integration mit Edge Side Includes (ESI)139
9.1 ESI: Konzepte139
9.1.1 Caches implementieren ESI140
9.1.2 CDN implementieren ESI.140
9.2 Beispiel140
9.2.1 Beispiel ablaufen lassen142
9.3 Varnish142
9.3.1 Lizenz und Support142
9.3.2 Caching mit HTTP und HTTP-Headern142
9.3.3 Varnish-Docker-Container143
9.3.4 Varnish-Konfiguration143
9.3.5 Bewertung von VCL144
9.3.6 Order-Microservice144
9.3.7 HTML mit ESI-Tags im Beispiel145
9.3.8 ESI-Tags im head145
9.3.9 ESI-Tags im restlichen HTML145
9.3.10 Ergebnis: HTML beim Browser145
9.3.11 Keine Tests ohne ESI-Infrastruktur146
9.3.12 Auswirkungen auf die Anwendungen146
9.3.13 Common-Microservice146
9.3.14 Asset-Server147
9.4 Rezept-Variationen147
9.4.1 SSI147
9.4.2 Tailor148
9.4.3 Clientseitige Integration148
9.4.4 Gemeinsame Bibliothek148
9.4.5 Weitere Integration148
9.5 Experimente149
9.6 Fazit150
9.6.1 Vorteile150
9.6.2 Herausforderungen150
10 Konzept: Asynchrone Microservices151
10.1 Definition151
10.1.1 Asynchrone Kommunikation ohne Antwort153
10.1.2 Datenreplikation und Bounded Context153
10.1.3 Synchrone Kommunikationsprotokolle153
10.1.4 Asynchrone Kommunikationsprotokolle153
10.2 Events154
10.2.1 Events und DDD154
10.2.2 Pattern aus dem Strategic Design155
10.2.3 Minimale Daten im Event schicken155
10.2.4 Event Sourcing155
10.2.5 Eigener oder gemeinsamer Event Store?156
10.3 Herausforderungen157
10.3.1 Inkonsistenz157
10.3.2 CAP-Theorem157
10.3.3 Begründung des CAP-Theorems158
10.3.4 Kompromisse bei CAP159
10.3.5 CAP, Events und Datenreplikation159
10.3.6 Sind Inkonsistenzen akzeptabel?159
10.3.7 Inkonsistenzen reparieren160
10.3.8 Garantierte Zustellung160
10.3.9 Idempotenz161
10.3.10 Ein Empfänger161
10.3.11 Test161
10.4 Vorteile162
10.5 Variationen162
10.6 Fazit163
11 Rezept: Messaging und Kafka165
11.1 Message-oriented Middleware (MOM)165
11.1.1 Spielarten von MOMs166
11.2 Die Architektur von Kafka166
11.2.1 Kafka speichert die Nachrichten-Historie.167
11.2.2 Kafka: Lizenz und Committer167
11.2.3 APIs167
11.2.4 Records167
11.2.5 Topics168
11.2.6 Partitionen168
11.2.7 Commit168
11.2.8 Polling169
11.2.9 Records, Topics, Partitionen und Commits im Überblick169
11.2.10 Replikation170
11.2.11 Leader und Follower170
11.2.12 Schreiben wiederholen170
11.2.13 Consumer Groups171
11.2.14 Persistenz171
11.2.15 Log Compaction172
11.3 Events mit Kafka172
11.3.1 Events verschicken172
11.4 Beispiel173
11.4.1 Datenmodell für die Kommunikation173
11.4.2 Domain-Driven Design und Strategic Design174
11.4.3 Technische Umsetzung der Kommunikation174
11.4.4 Datenmodell für die Datenbank175
11.4.5 Inkonsistenzen176
11.4.6 Technischer Aufbau176
11.4.7 Key für die Records177
11.4.8 Alle Informationen über die Bestellung im Record mitschicken178
11.4.9 Aufteilung der Records auf Partitionen selber implementieren178
11.4.10 Technische Parameter der Partitionen und Topics178
11.4.11 Keine Replikation im Beispiel179
11.4.12 Producer179
11.4.13 Consumer180
11.4.14 Consumer Groups180
11.4.15 Tests mit Embedded Kafka181
11.4.16 Avro als Datenformat181
11.5 Rezept-Variationen182
11.5.1 Andere MOM182
11.6 Experimente183
11.7 Fazit184
11.7.1 Vorteile184
11.7.2 Herausforderungen184
12 Rezept: Asynchrone Kommunikation mit Atom und REST185
12.1 Das Atom-Format185
12.1.1 MIME-Typ186
12.1.2 Feed186
12.1.3 Entry187
12.1.4 Tools188
12.1.5 Effizientes Polling des Atom-Feeds188
12.1.6 HTTP-Caching189
12.1.7 ETags190
12.1.8 Paginierung und Filterung190
12.1.9 Push vs. Pull191
12.1.10 Alte Ereignisse191
12.2 Beispiel191
12.2.1 Technische Umsetzung des Atom Views193
12.2.2 Umsetzung des Controllers193
12.2.3 Umsetzung des HTTP-Caching auf dem Server193
12.2.4 Umsetzung des HTTP-Caching auf dem Client194
12.2.5 Verarbeitung der Daten und Skalierung194
12.2.6 Atom kann keine Daten an nur einen Empfänger schicken.195
12.3 Rezept-Variationen195
12.3.1 RSS195
12.3.2 JSON-Feed196
12.3.3 Eigenes Datenformat196
12.3.4 Alternativen zu HTTP196
12.3.5 Event-Daten mitschicken197
12.4 Experimente197
12.5 Fazit198
12.5.1 Vorteile199
12.5.2 Herausforderungen199
13 Konzept: Synchrone Microservices201
13.1 Definition201
13.1.1 Ein Beispiel202
13.1.2 Konsistenz203
13.1.3 Bounded Context203
13.1.4 Tests203
13.1.5 Stubs204
13.1.6 Consumer-driven Contract Tests204
13.1.7 Das Pact-Test-Framework204
13.2 Herausforderungen204
13.2.1 Technische Lösungen205
13.2.2 API-Gateways206
13.3 Vorteile207
13.4 Variationen207
13.5 Fazit208
14 Rezept: REST mit dem Netflix-Stack209
14.1 Beispiel209
14.1.1 Architektur des Beispiels210
14.1.2 Beispiel bauen210
14.1.3 Docker-Container und Ports211
14.2 Eureka: Service Discovery211
14.2.1 Server212
14.2.2 Client214
14.2.3 Registrierung214
14.2.4 Andere Programmiersprachen215
14.2.5 Sidecars215
14.2.6 Zugriff auf andere Services215
14.3 Router: Zuul215
14.3.1 Zuul vs. Reverse Proxy216
14.3.2 Zuul im Beispiel216
14.4 Lastverteilung: Ribbon217
14.4.1 Zentraler Load Balancer217
14.4.2 Clientseitiges Load Balancing217
14.4.3 Ribbon-API218
14.4.4 Ribbon mit Consul218
14.4.5 RestTemplate219
14.5 Resilience: Hystrix219
14.5.1 Resilience-Patterns219
14.5.2 Implementierung220
14.5.3 Monitoring221
14.5.4 Hystrix-Dashboard221
14.5.5 Andere Monitoring-Möglichkeiten222
14.5.6 Turbine222
14.6 Rezept-Variationen223
14.7 Experimente224
14.8 Fazit226
14.8.1 Vorteile226
14.8.2 Herausforderungen226
15 Rezept: REST mit Consul und Apache httpd227
15.1 Beispiel227
15.1.1 Architektur des Beispiels228
15.1.2 Beispiel bauen229
15.2 Service Discovery: Consul229
15.2.1 Consul Dashboard230
15.2.2 Daten mit DNS auslesen231
15.2.3 Consul-Docker-Image231
15.3 Routing: Apache httpd232
15.3.1 Reverse Proxy232
15.3.2 Load Balancer232
15.4 Consul Template232
15.4.1 Das Template233
15.4.2 Consul Template starten233
15.4.3 Fazit234
15.5 Consul und Spring Boot234
15.5.1 Code-Abhängigkeiten234
15.5.2 Health-Check mit Spring Boot Actuator235
15.5.3 Consul und Ribbon235
15.6 DNS und Registrator235
15.6.1 Aufbau des Beispiels235
15.6.2 Konfiguration ebenfalls transparent möglich236
15.7 Rezept-Variationen237
15.7.1 Kombination mit Frontend-Integration237
15.7.2 Kombination mit asynchroner Kommunikation237
15.7.3 Andere Load Balancer237
15.8 Experimente237
15.9 Fazit239
15.9.1 Vorteile240
15.9.2 Herausforderungen240
16 Konzept: Microservices-Plattformen241
16.1 Definition241
16.1.1 Unterstützung für HTTP und REST241
16.1.2 Aufwand bei Installation und Betrieb242
16.1.3 Migration auf eine Microservices-Plattform242
16.1.4 Einfluss auf die Makro-Architektur243
16.1.5 Konkrete Plattformen243
16.2 Variationen244
16.2.1 Physische Hardware244
16.2.2 Virtuelle Hardware244
16.3 Fazit245
17 Rezept: Docker-Container mit Kubernetes247
17.1 Kubernetes247
17.1.1 Lizenz und Community247
17.1.2 Kubernetes-Versionen247
17.1.3 Features248
17.1.4 Kubernetes-Konzepte248
17.2 Das Beispiel mit Kubernetes249
17.2.1 Implementierung der Microservices mit Kubernetes250
17.2.2 Service Discovery250
17.2.3 Ausfallsicherheit250
17.2.4 Lastverteilung250
17.2.5 Service Discovery, Ausfallsicherheit und Lastverteilung ohne Code-Abhängigkeiten251
17.2.6 Routing mit Apache httpd251
17.2.7 Routing mit Node-Ports251
17.2.8 Routing mit Load Balancern251
17.2.9 Routing mit Ingress252
17.3 Beispiel im Detail252
17.3.1 Einige Minikube-Befehle253
17.4 Weitere Kubernetes-Features254
17.4.1 Monitoring mit Liveness und Readiness Probes254
17.4.2 Konfiguration255
17.4.3 Kubernetes-Umgebungen mit Namespaces trennen255
17.4.4 Anwendungen mit Zustand255
17.4.5 Erweiterungen mit Helm256
17.5 Rezept-Variationen256
17.5.1 MOMs in Kubernetes256
17.5.2 Frontend-Integration mit Kubernetes256
17.5.3 Docker Swarm und Docker Compose257
17.5.4 Docker vs. Virtualisierung257
17.6 Experimente257
17.7 Fazit259
17.7.1 Vorteile260
17.7.2 Herausforderungen260
18 Rezept: PaaS mit Cloud Foundry261
18.1 PaaS: Definition261
18.1.1 IaaS261
18.1.2 SaaS261
18.1.3 PaaS262
18.1.4 PaaS schränken Flexibilität und Kontrolle ein.262
18.1.5 Routing und Skalierung262
18.1.6 Weitere Dienste262
18.1.7 Public Cloud263
18.1.8 PaaS im eigenen Rechenzentrum263
18.1.9 Makro-Architektur263
18.2 Cloud Foundry264
18.2.1 Flexibilität264
18.3 Das Beispiel mit Cloud Foundry265
18.3.1 Cloud Foundry starten265
18.3.2 Deployment der Microservices266
18.3.3 Keine Code-Abhängigkeiten für Routing267
18.3.4 Datenbank und andere Services nutzen268
18.3.5 Beispiel für einen Service aus dem Marketplace268
18.3.6 Services in Anwendungen nutzen268
18.3.7 Services für asynchrone Kommunikation269
18.4 Rezept-Variationen269
18.5 Experimente269
18.6 Serverless270
18.6.1 REST mit AWS Lambda und dem API Gateway271
18.6.2 Glue Code271
18.7 Fazit271
18.7.1 Vorteile272
18.7.2 Herausforderungen272
Teil III: Betrieb273
19 Konzept: Betrieb275
19.1 Warum Betrieb wichtig ist275
19.1.1 Viele Microservices275
19.1.2 Ergebnisse von Experimenten überprüfen276
19.1.3 Verteiltes System276
19.1.4 Schnellere Reaktion277
19.1.5 Ergänzungen zu Tests277
19.1.6 Dynamische Skalierung278
19.2 Ansätze für den Betrieb von Microservices278
19.2.1 Unabhängiges Deployment279
19.2.2 Schrittweiser Aufbau des Betriebs280
19.3 Auswirkungen der behandelten Technologien280
19.4 Fazit281
20 Rezept: Monitoring mit Prometheus283
20.1 Grundlagen283
20.1.1 Verarbeitung der Metriken284
20.1.2 Unterschiedliche Metriken für unterschiedliche Stakeholder285
20.2 Metriken bei Microservices285
20.2.1 Mehr Services, mehr Metriken285
20.2.2 Service statt Instanzen285
20.2.3 Weg von Systemmetriken286
20.2.4 Hin zu Applikationsmetriken286
20.2.5 Fachliche Alerts286
20.3 Metriken mit Prometheus287
20.3.1 Beispiel für multidimensionale Metriken287
20.4 Beispiel mit Prometheus290
20.4.1 Umgebung starten290
20.4.2 Code in Spring Boot291
20.4.3 Prometheus-Konfiguration291
20.4.4 Konfiguration im Beispiel291
20.5 Rezept-Variationen292
20.5.1 Weitere Werkzeuge292
20.6 Experimente293
20.6.1 Experimente: Metriken auswählen293
20.6.2 Experimente: Prometheus ausbauen293
20.7 Fazit295
20.7.1 Vorteile295
20.7.2 Herausforderungen295
21 Rezept: Log-Analyse mit dem Elastic Stack297
21.1 Grundlagen297
21.1.1 Warum Logs?297
21.1.2 Log bei Microservices298
21.1.3 Log-Informationen298
21.1.4 Logs verschicken und nicht speichern299
21.1.5 Werkzeug: Map/Reduce299
21.1.6 Werkzeug: Suchmaschinen300
21.1.7 Elasticsearch300
21.2 Logging mit dem Elastic Stack300
21.3 Beispiel302
21.4 Rezept-Variationen304
21.5 Experimente304
21.6 Fazit305
21.6.1 Vorteile305
21.6.2 Herausforderungen305
22 Rezept: Tracing mit Zipkin307
22.1 Grundlagen307
22.1.1 Tracing notwendig?307
22.2 Tracing mit Zipkin308
22.2.1 Zipkin: Aufbau308
22.2.2 Trace- und Span-ID309
22.2.3 Tracing im Beispiel309
22.3 Beispiel311
22.4 Rezept-Variationen312
22.5 Fazit312
22.5.1 Vorteile312
22.5.2 Herausforderungen312
23 Und nun?313
A Installation der Umgebung317
B Maven-Kommandos319
C Docker- und Docker-Compose- Kommandos321
Index325
www.dpunkt.de0

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

Softwaretechnik

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

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

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

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

E-Book 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…

Weitere Zeitschriften

arznei-telegramm

arznei-telegramm

Das arznei-telegramm® informiert bereits im 53. Jahrgang Ärzte, Apotheker und andere Heilberufe über Nutzen und Risiken von Arzneimitteln. Das arznei-telegramm®  ist neutral und ...

FREIE WERKSTATT

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 Gehalt

Berufsstart Gehalt

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

Card Forum International

Card Forum International

Card Forum International, Magazine for Card Technologies and Applications, is a leading source for information in the field of card-based payment systems, related technologies, and required reading ...

elektrobörse handel

elektrobörse handel

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

Evangelische Theologie

Evangelische Theologie

Über »Evangelische Theologie« In interdisziplinären Themenheften gibt die Evangelische Theologie entscheidende Impulse, die komplexe Einheit der Theologie wahrzunehmen. Neben den Themenheften ...