Das Microservices-Praxisbuch

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