Grundlagen, Konzepte und Rezepte
E-Book, Deutsch, 328 Seiten
ISBN: 978-3-96088-461-3
Verlag: dpunkt
Format: PDF
Kopierschutz: 1 - PDF Watermark
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.
Autoren/Hrsg.
Weitere Infos & Material
1;Inhaltsverzeichnis;7
2;Einleitung;13
3;Teil I: Architekturgrundlagen;21
3.1;1 Microservices;23
3.1.1;1.1 Microservices: Definition;23
3.1.1.1;1.1.1 Vorteile der Microservices-Definition;24
3.1.1.2;1.1.2 Deployment-Monolith;24
3.1.1.3;1.1.3 Größe eines Microservice;24
3.1.2;1.2 Gründe für Microservices;25
3.1.2.1;1.2.1 Microservices zum Skalieren der Entwicklung;25
3.1.2.2;1.2.2 Legacy-Systeme ablösen;25
3.1.2.3;1.2.3 Nachhaltige Entwicklung;26
3.1.2.4;1.2.4 Continuous Delivery;27
3.1.2.5;1.2.5 Robustheit;28
3.1.2.6;1.2.6 Unabhängige Skalierung;29
3.1.2.7;1.2.7 Technologiewahlfreiheit;29
3.1.2.8;1.2.8 Sicherheit;29
3.1.2.9;1.2.9 Allgemein: Isolation;29
3.1.2.10;1.2.10 Vorteile priorisieren;30
3.1.2.11;1.2.11 Microservices sind ein Trade-Off;31
3.1.2.12;1.2.12 Zwei Ebenen von Microservices: fachlich und technisch;31
3.1.2.13;1.2.13 Typische Anzahl von Microservices in einem System;32
3.1.3;1.3 Herausforderungen;32
3.1.3.1;1.3.1 Vorteile und Nachteile abwägen;33
3.1.4;1.4 Independent-Systems-Architecture-Prinzipien (ISA);33
3.1.5;1.5 Bedingungen;33
3.1.6;1.6 Prinzipien;33
3.1.7;1.7 Bewertung;34
3.1.8;1.8 Variationen;35
3.1.8.1;1.8.1 Technologische Varationen;35
3.1.8.2;1.8.2 Experimente;35
3.1.9;1.9 Fazit;36
3.2;2 Mikro- und Makro-Architektur;37
3.2.1;2.1 Bounded Context und Strategic Design;38
3.2.1.1;2.1.1 Ein Beispiel für eine fachliche Architektur;38
3.2.1.2;2.1.2 Domain-driven Design: Definition;39
3.2.1.3;2.1.3 Bounded Context: Definition;39
3.2.1.4;2.1.4 Strategic Design;40
3.2.1.5;2.1.5 Strategic Design Patterns;40
3.2.1.6;2.1.6 Auswahl der Patterns;44
3.2.1.7;2.1.7 Domain Events zwischen Bounded Contexts;44
3.2.1.8;2.1.8 Bounded Contexts und Microservices;44
3.2.2;2.2 Technische Mikro- und Makro-Architektur;44
3.2.2.1;2.2.1 Mikro- oder Makro-Architektur-Entscheidungen;45
3.2.2.2;2.2.2 Typische Makro-Architektur-Entscheidungen;46
3.2.2.3;2.2.3 Typische Mikro-Architektur-Entscheidungen;47
3.2.3;2.3 Betrieb: Mikro- oder Makro-Architektur;48
3.2.3.1;2.3.1 Betriebs-Makro-Architektur bei getrennter Betriebsmannschaft;49
3.2.3.2;2.3.2 Nur Technologien standardisieren!;50
3.2.3.3;2.3.3 Betriebs-Makro-Architektur testen;50
3.2.3.4;2.3.4 Betriebs-Mikro-Architektur bei »You build it – you run it«;50
3.2.3.5;2.3.5 Betrieb als Ganzes ist Mikro- oder Makro-Architektur.;51
3.2.4;2.4 Mikro-Architektur bevorzugen!;51
3.2.4.1;2.4.1 Evolution der Makro-Architektur;52
3.2.4.2;2.4.2 Best Practices und Beratung;52
3.2.5;2.5 Organisatorische Aspekte;52
3.2.5.1;2.5.1 Wildwuchs?;52
3.2.5.2;2.5.2 Wer macht Makro-Architektur?;53
3.2.5.3;2.5.3 Wie durchsetzen?;53
3.2.6;2.6 Variationen;54
3.2.6.1;2.6.1 Komplexere Regeln;54
3.2.6.2;2.6.2 Experimente;55
3.2.7;2.7 Fazit;55
3.3;3 Self-contained System (SCS);57
3.3.1;3.1 Gründe für den Begriff Self-contained Systems;57
3.3.2;3.2 Self-contained Systems: Definition;58
3.3.2.1;3.2.1 Regeln für Kommunikation;58
3.3.2.2;3.2.2 Regeln für die Organisation;59
3.3.2.3;3.2.3 Regel: Minimale gemeinsame Basis;60
3.3.3;3.3 Ein Beispiel;61
3.3.3.1;3.3.1 Kommunikation;62
3.3.4;3.4 SCS und Microservices;62
3.3.5;3.5 Herausforderungen;63
3.3.5.1;3.5.1 Einschränkung auf Web-Anwendungen;63
3.3.5.2;3.5.2 Single Page App (SPA);64
3.3.5.3;3.5.3 Mobile Anwendungen;64
3.3.5.4;3.5.4 Look & Feel;65
3.3.6;3.6 Variationen;65
3.3.6.1;3.6.1 Typische Änderungen;66
3.3.6.2;3.6.2 Kombinationsmöglichkeiten;66
3.3.7;3.7 Fazit;66
3.4;4 Migration;67
3.4.1;4.1 Gründe für eine Migration;67
3.4.1.1;4.1.1 Microservice bieten einen Neuanfang.;67
3.4.1.2;4.1.2 Gründe sind schon bekannt.;68
3.4.1.3;4.1.3 Typischer Grund: Entwicklungsgeschwindigkeit;68
3.4.2;4.2 Typische Migrationsstrategie;68
3.4.2.1;4.2.1 Ein typisches Szenario;69
3.4.2.2;4.2.2 Asynchrone Kommunikation bervorzugen;69
3.4.2.3;4.2.3 UI-Integration bevorzugen;70
3.4.2.4;4.2.4 Synchrone Kommunikation vermeiden;70
3.4.2.5;4.2.5 Alte Schnittstellen weiter nutzen?;71
3.4.2.6;4.2.6 Authentifizierung integrieren;71
3.4.2.7;4.2.7 Daten replizieren;71
3.4.2.8;4.2.8 Ersten Microservice für die Migration auswählen;71
3.4.2.9;4.2.9 Extreme Migrationsstrategie: alle Änderungen in Microservices;72
3.4.2.10;4.2.10 Weiteres Vorgehen: schrittweise Migration;72
3.4.3;4.3 Alternative Strategien;73
3.4.3.1;4.3.1 Migration nach Schichten;73
3.4.3.2;4.3.2 Copy/Change;74
3.4.4;4.4 Build, Betrieb und Organisation;74
3.4.4.1;4.4.1 Koexistenz Microservices und Legacy-System;75
3.4.4.2;4.4.2 Integrationstest Microservices und Legacy-System;75
3.4.4.3;4.4.3 Koordiniertes Deloyment zwischen Legacy-System und Microservices;76
3.4.4.4;4.4.4 Organisatorische Aspekte;76
3.4.4.5;4.4.5 Empfehlung: nicht alle Aspekte auf einmal umsetzen;76
3.4.5;4.5 Variationen;76
3.4.5.1;4.5.1 Experimente;77
3.4.6;4.6 Fazit;78
4;Teil II: Technologie-Stacks;79
4.1;5 Docker-Einführung;81
4.1.1;5.1 Docker für Microservices: Gründe;82
4.1.1.1;5.1.1 Prozesse reichen für Microservices nicht aus.;82
4.1.1.2;5.1.2 Virtuelle Maschinen sind zu schwergewichtig für Microservices;82
4.1.2;5.2 Docker-Grundlagen;83
4.1.2.1;5.2.1 Ein Prozess pro Container;84
4.1.2.2;5.2.2 Docker-Image und Docker-Registry;84
4.1.2.3;5.2.3 Unterstützte Betriebssysteme;85
4.1.2.4;5.2.4 Betriebssysteme für Docker;85
4.1.2.5;5.2.5 Überblick;86
4.1.2.6;5.2.6 Muss es immer Docker sein?;86
4.1.2.7;5.2.7 Microservices als WARs in Java Application Servern;87
4.1.3;5.3 Docker-Installation und Docker-Kommandos;87
4.1.4;5.4 Docker-Hosts mit Docker Machine installieren;87
4.1.4.1;5.4.1 Überblick;88
4.1.4.2;5.4.2 Docker-Machine-Treiber;88
4.1.4.3;5.4.3 Vorteil: getrennte Umgebungen und Docker auf Servern;89
4.1.5;5.5 Dockerfiles;89
4.1.5.1;5.5.1 Ein Beispiel für ein Dockerfile;90
4.1.5.2;5.5.2 Dateisystemschichten im Beispiel;90
4.1.5.3;5.5.3 Probleme mit Caching und Schichten;91
4.1.5.4;5.5.4 Docker Multi Stage Builds;91
4.1.5.5;5.5.5 Immutable Server mit Docker;92
4.1.5.6;5.5.6 Docker und Werkzeuge wie Puppet, Chef oder Ansible;92
4.1.6;5.6 Docker Compose;92
4.1.6.1;5.6.1 Service Discovery mit Docker-Compose-Links;93
4.1.6.2;5.6.2 Ports;93
4.1.6.3;5.6.3 Volumes;93
4.1.6.4;5.6.4 YAML-Konfiguration;93
4.1.6.5;5.6.5 Weitere Möglichkeiten;94
4.1.6.6;5.6.6 Docker-Compose-Kommandos;95
4.1.7;5.7 Variationen;95
4.1.7.1;5.7.1 Cluster;95
4.1.7.2;5.7.2 Docker ohne Scheduler;96
4.1.7.3;5.7.3 PaaS;97
4.1.7.4;5.7.4 Experimente;97
4.1.8;5.8 Fazit;97
4.2;6 Technische Mikro-Architektur;99
4.2.1;6.1 Anforderungen;99
4.2.1.1;6.1.1 Kommunikation;100
4.2.1.2;6.1.2 Betrieb;100
4.2.1.3;6.1.3 Neue Microservices;101
4.2.1.4;6.1.4 Resilience;101
4.2.2;6.2 Reactive;101
4.2.2.1;6.2.1 Reactive Programming;102
4.2.2.2;6.2.2 Klassische Server-Anwendungen;102
4.2.2.3;6.2.3 Reactive-Server-Anwendungen;102
4.2.2.4;6.2.4 Reactive Programming und das Reactive Manifesto;103
4.2.2.5;6.2.5 Reactive Programming ist für Microservices nicht notwendig.;103
4.2.3;6.3 Spring Boot;104
4.2.3.1;6.3.1 Java-Code;104
4.2.3.2;6.3.2 Build;105
4.2.3.3;6.3.3 spring-boot-starter-web als einzige Abhängigkeit;106
4.2.3.4;6.3.4 Spring Cloud;106
4.2.3.5;6.3.5 Maven-Plug-In;106
4.2.3.6;6.3.6 Spring Boot für Microservices?;106
4.2.3.7;6.3.7 Kommunikation;106
4.2.3.8;6.3.8 Betrieb;107
4.2.3.9;6.3.9 Neue Microservices;108
4.2.3.10;6.3.10 Resilience;109
4.2.4;6.4 Go;109
4.2.4.1;6.4.1 Code;109
4.2.4.2;6.4.2 Build;110
4.2.4.3;6.4.3 Docker Multi Stage Builds;110
4.2.4.4;6.4.4 Multi Stage Builds: Vorteile;111
4.2.4.5;6.4.5 Go für Microservices?;111
4.2.4.6;6.4.6 Kommunikation;111
4.2.4.7;6.4.7 Betrieb;112
4.2.4.8;6.4.8 Neue Microservices;112
4.2.4.9;6.4.9 Resilience;112
4.2.5;6.5 Variationen;112
4.2.5.1;6.5.1 Alternativen zu Spring Boot;113
4.2.6;6.6 Fazit;113
4.3;7 Konzept: Frontend-Integration;115
4.3.1;7.1 Frontend: Monolith oder modular?;115
4.3.1.1;7.1.1 Option: monolithisches Frontend und Backend;116
4.3.1.2;7.1.2 Option: modular entwickeltes Frontend;116
4.3.1.3;7.1.3 Gründe für einen Frontend-Monolithen;117
4.3.1.4;7.1.4 Modularisiertes Frontend;118
4.3.1.5;7.1.5 Modularisiertes Frontend und Frontend-Integration;118
4.3.2;7.2 Optionen;118
4.3.3;7.3 Resource-oriented Client Architecture (ROCA);119
4.3.3.1;7.3.1 ROCA-Prinzipien;119
4.3.3.2;7.3.2 Vorteile der ROCA-Architektur;121
4.3.3.3;7.3.3 ROCA vs SPAs;121
4.3.3.4;7.3.4 Integrationsmöglichkeiten;121
4.3.4;7.4 Herausforderungen;122
4.3.4.1;7.4.1 Einheitliches Look & Feel;122
4.3.4.2;7.4.2 Schnittstellen in der Frontend-Integration;122
4.3.4.3;7.4.3 UI-Änderungen werden querschnittlich;122
4.3.5;7.5 Vorteile;123
4.3.5.1;7.5.1 Lose Kopplung;123
4.3.5.2;7.5.2 Logik und UI in einem Microservices;123
4.3.5.3;7.5.3 Freie Wahl von Frontend-Technologien;123
4.3.6;7.6 Variationen;124
4.3.7;7.7 Fazit;124
4.4;8 Rezept: Links und clientseitige Integration;127
4.4.1;8.1 Überblick;127
4.4.1.1;8.1.1 Suche;128
4.4.1.2;8.1.2 Postbox;128
4.4.1.3;8.1.3 Aufbau der Anwendung;129
4.4.1.4;8.1.4 Integration mit Redirects;130
4.4.1.5;8.1.5 Integration mit Links;131
4.4.1.6;8.1.6 Integration mit JavaScript;131
4.4.1.7;8.1.7 Darstellungslogik in der Postbox;132
4.4.1.8;8.1.8 Assets beim integrierten HTML;132
4.4.1.9;8.1.9 Resilience;133
4.4.1.10;8.1.10 Mit und ohne JavaScript;133
4.4.2;8.2 Beispiel;133
4.4.2.1;8.2.1 Aufteilung der Ports;134
4.4.3;8.3 Rezept-Variationen;135
4.4.3.1;8.3.1 Einfacherer JavaScript-Code;135
4.4.4;8.4 Experimente;136
4.4.5;8.5 Fazit;137
4.4.5.1;8.5.1 ROCA;137
4.4.5.2;8.5.2 Assets;137
4.4.5.3;8.5.3 Self-contained Systems;138
4.4.5.4;8.5.4 Vorteile;138
4.4.5.5;8.5.5 Herausforderungen;138
4.5;9 Rezept: serverseitige Integration mit Edge Side Includes (ESI);139
4.5.1;9.1 ESI: Konzepte;139
4.5.1.1;9.1.1 Caches implementieren ESI;140
4.5.1.2;9.1.2 CDN implementieren ESI.;140
4.5.2;9.2 Beispiel;140
4.5.2.1;9.2.1 Beispiel ablaufen lassen;142
4.5.3;9.3 Varnish;142
4.5.3.1;9.3.1 Lizenz und Support;142
4.5.3.2;9.3.2 Caching mit HTTP und HTTP-Headern;142
4.5.3.3;9.3.3 Varnish-Docker-Container;143
4.5.3.4;9.3.4 Varnish-Konfiguration;143
4.5.3.5;9.3.5 Bewertung von VCL;144
4.5.3.6;9.3.6 Order-Microservice;144
4.5.3.7;9.3.7 HTML mit ESI-Tags im Beispiel;145
4.5.3.8;9.3.8 ESI-Tags im head;145
4.5.3.9;9.3.9 ESI-Tags im restlichen HTML;145
4.5.3.10;9.3.10 Ergebnis: HTML beim Browser;145
4.5.3.11;9.3.11 Keine Tests ohne ESI-Infrastruktur;146
4.5.3.12;9.3.12 Auswirkungen auf die Anwendungen;146
4.5.3.13;9.3.13 Common-Microservice;146
4.5.3.14;9.3.14 Asset-Server;147
4.5.4;9.4 Rezept-Variationen;147
4.5.4.1;9.4.1 SSI;147
4.5.4.2;9.4.2 Tailor;148
4.5.4.3;9.4.3 Clientseitige Integration;148
4.5.4.4;9.4.4 Gemeinsame Bibliothek;148
4.5.4.5;9.4.5 Weitere Integration;148
4.5.5;9.5 Experimente;149
4.5.6;9.6 Fazit;150
4.5.6.1;9.6.1 Vorteile;150
4.5.6.2;9.6.2 Herausforderungen;150
4.6;10 Konzept: Asynchrone Microservices;151
4.6.1;10.1 Definition;151
4.6.1.1;10.1.1 Asynchrone Kommunikation ohne Antwort;153
4.6.1.2;10.1.2 Datenreplikation und Bounded Context;153
4.6.1.3;10.1.3 Synchrone Kommunikationsprotokolle;153
4.6.1.4;10.1.4 Asynchrone Kommunikationsprotokolle;153
4.6.2;10.2 Events;154
4.6.2.1;10.2.1 Events und DDD;154
4.6.2.2;10.2.2 Pattern aus dem Strategic Design;155
4.6.2.3;10.2.3 Minimale Daten im Event schicken;155
4.6.2.4;10.2.4 Event Sourcing;155
4.6.2.5;10.2.5 Eigener oder gemeinsamer Event Store?;156
4.6.3;10.3 Herausforderungen;157
4.6.3.1;10.3.1 Inkonsistenz;157
4.6.3.2;10.3.2 CAP-Theorem;157
4.6.3.3;10.3.3 Begründung des CAP-Theorems;158
4.6.3.4;10.3.4 Kompromisse bei CAP;159
4.6.3.5;10.3.5 CAP, Events und Datenreplikation;159
4.6.3.6;10.3.6 Sind Inkonsistenzen akzeptabel?;159
4.6.3.7;10.3.7 Inkonsistenzen reparieren;160
4.6.3.8;10.3.8 Garantierte Zustellung;160
4.6.3.9;10.3.9 Idempotenz;161
4.6.3.10;10.3.10 Ein Empfänger;161
4.6.3.11;10.3.11 Test;161
4.6.4;10.4 Vorteile;162
4.6.5;10.5 Variationen;162
4.6.6;10.6 Fazit;163
4.7;11 Rezept: Messaging und Kafka;165
4.7.1;11.1 Message-oriented Middleware (MOM);165
4.7.1.1;11.1.1 Spielarten von MOMs;166
4.7.2;11.2 Die Architektur von Kafka;166
4.7.2.1;11.2.1 Kafka speichert die Nachrichten-Historie.;167
4.7.2.2;11.2.2 Kafka: Lizenz und Committer;167
4.7.2.3;11.2.3 APIs;167
4.7.2.4;11.2.4 Records;167
4.7.2.5;11.2.5 Topics;168
4.7.2.6;11.2.6 Partitionen;168
4.7.2.7;11.2.7 Commit;168
4.7.2.8;11.2.8 Polling;169
4.7.2.9;11.2.9 Records, Topics, Partitionen und Commits im Überblick;169
4.7.2.10;11.2.10 Replikation;170
4.7.2.11;11.2.11 Leader und Follower;170
4.7.2.12;11.2.12 Schreiben wiederholen;170
4.7.2.13;11.2.13 Consumer Groups;171
4.7.2.14;11.2.14 Persistenz;171
4.7.2.15;11.2.15 Log Compaction;172
4.7.3;11.3 Events mit Kafka;172
4.7.3.1;11.3.1 Events verschicken;172
4.7.4;11.4 Beispiel;173
4.7.4.1;11.4.1 Datenmodell für die Kommunikation;173
4.7.4.2;11.4.2 Domain-Driven Design und Strategic Design;174
4.7.4.3;11.4.3 Technische Umsetzung der Kommunikation;174
4.7.4.4;11.4.4 Datenmodell für die Datenbank;175
4.7.4.5;11.4.5 Inkonsistenzen;176
4.7.4.6;11.4.6 Technischer Aufbau;176
4.7.4.7;11.4.7 Key für die Records;177
4.7.4.8;11.4.8 Alle Informationen über die Bestellung im Record mitschicken;178
4.7.4.9;11.4.9 Aufteilung der Records auf Partitionen selber implementieren;178
4.7.4.10;11.4.10 Technische Parameter der Partitionen und Topics;178
4.7.4.11;11.4.11 Keine Replikation im Beispiel;179
4.7.4.12;11.4.12 Producer;179
4.7.4.13;11.4.13 Consumer;180
4.7.4.14;11.4.14 Consumer Groups;180
4.7.4.15;11.4.15 Tests mit Embedded Kafka;181
4.7.4.16;11.4.16 Avro als Datenformat;181
4.7.5;11.5 Rezept-Variationen;182
4.7.5.1;11.5.1 Andere MOM;182
4.7.6;11.6 Experimente;183
4.7.7;11.7 Fazit;184
4.7.7.1;11.7.1 Vorteile;184
4.7.7.2;11.7.2 Herausforderungen;184
4.8;12 Rezept: Asynchrone Kommunikation mit Atom und REST;185
4.8.1;12.1 Das Atom-Format;185
4.8.1.1;12.1.1 MIME-Typ;186
4.8.1.2;12.1.2 Feed;186
4.8.1.3;12.1.3 Entry;187
4.8.1.4;12.1.4 Tools;188
4.8.1.5;12.1.5 Effizientes Polling des Atom-Feeds;188
4.8.1.6;12.1.6 HTTP-Caching;189
4.8.1.7;12.1.7 ETags;190
4.8.1.8;12.1.8 Paginierung und Filterung;190
4.8.1.9;12.1.9 Push vs. Pull;191
4.8.1.10;12.1.10 Alte Ereignisse;191
4.8.2;12.2 Beispiel;191
4.8.2.1;12.2.1 Technische Umsetzung des Atom Views;193
4.8.2.2;12.2.2 Umsetzung des Controllers;193
4.8.2.3;12.2.3 Umsetzung des HTTP-Caching auf dem Server;193
4.8.2.4;12.2.4 Umsetzung des HTTP-Caching auf dem Client;194
4.8.2.5;12.2.5 Verarbeitung der Daten und Skalierung;194
4.8.2.6;12.2.6 Atom kann keine Daten an nur einen Empfänger schicken.;195
4.8.3;12.3 Rezept-Variationen;195
4.8.3.1;12.3.1 RSS;195
4.8.3.2;12.3.2 JSON-Feed;196
4.8.3.3;12.3.3 Eigenes Datenformat;196
4.8.3.4;12.3.4 Alternativen zu HTTP;196
4.8.3.5;12.3.5 Event-Daten mitschicken;197
4.8.4;12.4 Experimente;197
4.8.5;12.5 Fazit;198
4.8.5.1;12.5.1 Vorteile;199
4.8.5.2;12.5.2 Herausforderungen;199
4.9;13 Konzept: Synchrone Microservices;201
4.9.1;13.1 Definition;201
4.9.1.1;13.1.1 Ein Beispiel;202
4.9.1.2;13.1.2 Konsistenz;203
4.9.1.3;13.1.3 Bounded Context;203
4.9.1.4;13.1.4 Tests;203
4.9.1.5;13.1.5 Stubs;204
4.9.1.6;13.1.6 Consumer-driven Contract Tests;204
4.9.1.7;13.1.7 Das Pact-Test-Framework;204
4.9.2;13.2 Herausforderungen;204
4.9.2.1;13.2.1 Technische Lösungen;205
4.9.2.2;13.2.2 API-Gateways;206
4.9.3;13.3 Vorteile;207
4.9.4;13.4 Variationen;207
4.9.5;13.5 Fazit;208
4.10;14 Rezept: REST mit dem Netflix-Stack;209
4.10.1;14.1 Beispiel;209
4.10.1.1;14.1.1 Architektur des Beispiels;210
4.10.1.2;14.1.2 Beispiel bauen;210
4.10.1.3;14.1.3 Docker-Container und Ports;211
4.10.2;14.2 Eureka: Service Discovery;211
4.10.2.1;14.2.1 Server;212
4.10.2.2;14.2.2 Client;214
4.10.2.3;14.2.3 Registrierung;214
4.10.2.4;14.2.4 Andere Programmiersprachen;215
4.10.2.5;14.2.5 Sidecars;215
4.10.2.6;14.2.6 Zugriff auf andere Services;215
4.10.3;14.3 Router: Zuul;215
4.10.3.1;14.3.1 Zuul vs. Reverse Proxy;216
4.10.3.2;14.3.2 Zuul im Beispiel;216
4.10.4;14.4 Lastverteilung: Ribbon;217
4.10.4.1;14.4.1 Zentraler Load Balancer;217
4.10.4.2;14.4.2 Clientseitiges Load Balancing;217
4.10.4.3;14.4.3 Ribbon-API;218
4.10.4.4;14.4.4 Ribbon mit Consul;218
4.10.4.5;14.4.5 RestTemplate;219
4.10.5;14.5 Resilience: Hystrix;219
4.10.5.1;14.5.1 Resilience-Patterns;219
4.10.5.2;14.5.2 Implementierung;220
4.10.5.3;14.5.3 Monitoring;221
4.10.5.4;14.5.4 Hystrix-Dashboard;221
4.10.5.5;14.5.5 Andere Monitoring-Möglichkeiten;222
4.10.5.6;14.5.6 Turbine;222
4.10.6;14.6 Rezept-Variationen;223
4.10.7;14.7 Experimente;224
4.10.8;14.8 Fazit;226
4.10.8.1;14.8.1 Vorteile;226
4.10.8.2;14.8.2 Herausforderungen;226
4.11;15 Rezept: REST mit Consul und Apache httpd;227
4.11.1;15.1 Beispiel;227
4.11.1.1;15.1.1 Architektur des Beispiels;228
4.11.1.2;15.1.2 Beispiel bauen;229
4.11.2;15.2 Service Discovery: Consul;229
4.11.2.1;15.2.1 Consul Dashboard;230
4.11.2.2;15.2.2 Daten mit DNS auslesen;231
4.11.2.3;15.2.3 Consul-Docker-Image;231
4.11.3;15.3 Routing: Apache httpd;232
4.11.3.1;15.3.1 Reverse Proxy;232
4.11.3.2;15.3.2 Load Balancer;232
4.11.4;15.4 Consul Template;232
4.11.4.1;15.4.1 Das Template;233
4.11.4.2;15.4.2 Consul Template starten;233
4.11.4.3;15.4.3 Fazit;234
4.11.5;15.5 Consul und Spring Boot;234
4.11.5.1;15.5.1 Code-Abhängigkeiten;234
4.11.5.2;15.5.2 Health-Check mit Spring Boot Actuator;235
4.11.5.3;15.5.3 Consul und Ribbon;235
4.11.6;15.6 DNS und Registrator;235
4.11.6.1;15.6.1 Aufbau des Beispiels;235
4.11.6.2;15.6.2 Konfiguration ebenfalls transparent möglich;236
4.11.7;15.7 Rezept-Variationen;237
4.11.7.1;15.7.1 Kombination mit Frontend-Integration;237
4.11.7.2;15.7.2 Kombination mit asynchroner Kommunikation;237
4.11.7.3;15.7.3 Andere Load Balancer;237
4.11.8;15.8 Experimente;237
4.11.9;15.9 Fazit;239
4.11.9.1;15.9.1 Vorteile;240
4.11.9.2;15.9.2 Herausforderungen;240
4.12;16 Konzept: Microservices-Plattformen;241
4.12.1;16.1 Definition;241
4.12.1.1;16.1.1 Unterstützung für HTTP und REST;241
4.12.1.2;16.1.2 Aufwand bei Installation und Betrieb;242
4.12.1.3;16.1.3 Migration auf eine Microservices-Plattform;242
4.12.1.4;16.1.4 Einfluss auf die Makro-Architektur;243
4.12.1.5;16.1.5 Konkrete Plattformen;243
4.12.2;16.2 Variationen;244
4.12.2.1;16.2.1 Physische Hardware;244
4.12.2.2;16.2.2 Virtuelle Hardware;244
4.12.3;16.3 Fazit;245
4.13;17 Rezept: Docker-Container mit Kubernetes;247
4.13.1;17.1 Kubernetes;247
4.13.1.1;17.1.1 Lizenz und Community;247
4.13.1.2;17.1.2 Kubernetes-Versionen;247
4.13.1.3;17.1.3 Features;248
4.13.1.4;17.1.4 Kubernetes-Konzepte;248
4.13.2;17.2 Das Beispiel mit Kubernetes;249
4.13.2.1;17.2.1 Implementierung der Microservices mit Kubernetes;250
4.13.2.2;17.2.2 Service Discovery;250
4.13.2.3;17.2.3 Ausfallsicherheit;250
4.13.2.4;17.2.4 Lastverteilung;250
4.13.2.5;17.2.5 Service Discovery, Ausfallsicherheit und Lastverteilung ohne Code-Abhängigkeiten;251
4.13.2.6;17.2.6 Routing mit Apache httpd;251
4.13.2.7;17.2.7 Routing mit Node-Ports;251
4.13.2.8;17.2.8 Routing mit Load Balancern;251
4.13.2.9;17.2.9 Routing mit Ingress;252
4.13.3;17.3 Beispiel im Detail;252
4.13.3.1;17.3.1 Einige Minikube-Befehle;253
4.13.4;17.4 Weitere Kubernetes-Features;254
4.13.4.1;17.4.1 Monitoring mit Liveness und Readiness Probes;254
4.13.4.2;17.4.2 Konfiguration;255
4.13.4.3;17.4.3 Kubernetes-Umgebungen mit Namespaces trennen;255
4.13.4.4;17.4.4 Anwendungen mit Zustand;255
4.13.4.5;17.4.5 Erweiterungen mit Helm;256
4.13.5;17.5 Rezept-Variationen;256
4.13.5.1;17.5.1 MOMs in Kubernetes;256
4.13.5.2;17.5.2 Frontend-Integration mit Kubernetes;256
4.13.5.3;17.5.3 Docker Swarm und Docker Compose;257
4.13.5.4;17.5.4 Docker vs. Virtualisierung;257
4.13.6;17.6 Experimente;257
4.13.7;17.7 Fazit;259
4.13.7.1;17.7.1 Vorteile;260
4.13.7.2;17.7.2 Herausforderungen;260
4.14;18 Rezept: PaaS mit Cloud Foundry;261
4.14.1;18.1 PaaS: Definition;261
4.14.1.1;18.1.1 IaaS;261
4.14.1.2;18.1.2 SaaS;261
4.14.1.3;18.1.3 PaaS;262
4.14.1.4;18.1.4 PaaS schränken Flexibilität und Kontrolle ein.;262
4.14.1.5;18.1.5 Routing und Skalierung;262
4.14.1.6;18.1.6 Weitere Dienste;262
4.14.1.7;18.1.7 Public Cloud;263
4.14.1.8;18.1.8 PaaS im eigenen Rechenzentrum;263
4.14.1.9;18.1.9 Makro-Architektur;263
4.14.2;18.2 Cloud Foundry;264
4.14.2.1;18.2.1 Flexibilität;264
4.14.3;18.3 Das Beispiel mit Cloud Foundry;265
4.14.3.1;18.3.1 Cloud Foundry starten;265
4.14.3.2;18.3.2 Deployment der Microservices;266
4.14.3.3;18.3.3 Keine Code-Abhängigkeiten für Routing;267
4.14.3.4;18.3.4 Datenbank und andere Services nutzen;268
4.14.3.5;18.3.5 Beispiel für einen Service aus dem Marketplace;268
4.14.3.6;18.3.6 Services in Anwendungen nutzen;268
4.14.3.7;18.3.7 Services für asynchrone Kommunikation;269
4.14.4;18.4 Rezept-Variationen;269
4.14.5;18.5 Experimente;269
4.14.6;18.6 Serverless;270
4.14.6.1;18.6.1 REST mit AWS Lambda und dem API Gateway;271
4.14.6.2;18.6.2 Glue Code;271
4.14.7;18.7 Fazit;271
4.14.7.1;18.7.1 Vorteile;272
4.14.7.2;18.7.2 Herausforderungen;272
5;Teil III: Betrieb;273
5.1;19 Konzept: Betrieb;275
5.1.1;19.1 Warum Betrieb wichtig ist;275
5.1.1.1;19.1.1 Viele Microservices;275
5.1.1.2;19.1.2 Ergebnisse von Experimenten überprüfen;276
5.1.1.3;19.1.3 Verteiltes System;276
5.1.1.4;19.1.4 Schnellere Reaktion;277
5.1.1.5;19.1.5 Ergänzungen zu Tests;277
5.1.1.6;19.1.6 Dynamische Skalierung;278
5.1.2;19.2 Ansätze für den Betrieb von Microservices;278
5.1.2.1;19.2.1 Unabhängiges Deployment;279
5.1.2.2;19.2.2 Schrittweiser Aufbau des Betriebs;280
5.1.3;19.3 Auswirkungen der behandelten Technologien;280
5.1.4;19.4 Fazit;281
5.2;20 Rezept: Monitoring mit Prometheus;283
5.2.1;20.1 Grundlagen;283
5.2.1.1;20.1.1 Verarbeitung der Metriken;284
5.2.1.2;20.1.2 Unterschiedliche Metriken für unterschiedliche Stakeholder;285
5.2.2;20.2 Metriken bei Microservices;285
5.2.2.1;20.2.1 Mehr Services, mehr Metriken;285
5.2.2.2;20.2.2 Service statt Instanzen;285
5.2.2.3;20.2.3 Weg von Systemmetriken;286
5.2.2.4;20.2.4 Hin zu Applikationsmetriken;286
5.2.2.5;20.2.5 Fachliche Alerts;286
5.2.3;20.3 Metriken mit Prometheus;287
5.2.3.1;20.3.1 Beispiel für multidimensionale Metriken;287
5.2.4;20.4 Beispiel mit Prometheus;290
5.2.4.1;20.4.1 Umgebung starten;290
5.2.4.2;20.4.2 Code in Spring Boot;291
5.2.4.3;20.4.3 Prometheus-Konfiguration;291
5.2.4.4;20.4.4 Konfiguration im Beispiel;291
5.2.5;20.5 Rezept-Variationen;292
5.2.5.1;20.5.1 Weitere Werkzeuge;292
5.2.6;20.6 Experimente;293
5.2.6.1;20.6.1 Experimente: Metriken auswählen;293
5.2.6.2;20.6.2 Experimente: Prometheus ausbauen;293
5.2.7;20.7 Fazit;295
5.2.7.1;20.7.1 Vorteile;295
5.2.7.2;20.7.2 Herausforderungen;295
5.3;21 Rezept: Log-Analyse mit dem Elastic Stack;297
5.3.1;21.1 Grundlagen;297
5.3.1.1;21.1.1 Warum Logs?;297
5.3.1.2;21.1.2 Log bei Microservices;298
5.3.1.3;21.1.3 Log-Informationen;298
5.3.1.4;21.1.4 Logs verschicken und nicht speichern;299
5.3.1.5;21.1.5 Werkzeug: Map/Reduce;299
5.3.1.6;21.1.6 Werkzeug: Suchmaschinen;300
5.3.1.7;21.1.7 Elasticsearch;300
5.3.2;21.2 Logging mit dem Elastic Stack;300
5.3.3;21.3 Beispiel;302
5.3.4;21.4 Rezept-Variationen;304
5.3.5;21.5 Experimente;304
5.3.6;21.6 Fazit;305
5.3.6.1;21.6.1 Vorteile;305
5.3.6.2;21.6.2 Herausforderungen;305
5.4;22 Rezept: Tracing mit Zipkin;307
5.4.1;22.1 Grundlagen;307
5.4.1.1;22.1.1 Tracing notwendig?;307
5.4.2;22.2 Tracing mit Zipkin;308
5.4.2.1;22.2.1 Zipkin: Aufbau;308
5.4.2.2;22.2.2 Trace- und Span-ID;309
5.4.2.3;22.2.3 Tracing im Beispiel;309
5.4.3;22.3 Beispiel;311
5.4.4;22.4 Rezept-Variationen;312
5.4.5;22.5 Fazit;312
5.4.5.1;22.5.1 Vorteile;312
5.4.5.2;22.5.2 Herausforderungen;312
5.5;23 Und nun?;313
6;A Installation der Umgebung;317
7;B Maven-Kommandos;319
8;C Docker- und Docker-Compose- Kommandos;321
9;Index;325
10;www.dpunkt.de;0
