
Microservices
Description
Alles über E-Books | Antworten auf Fragen rund um E-Books, Kopierschutz und Dateiformate finden Sie in unserem Info- & Hilfebereich.
More details
Other editions
Additional editions

Person
Content
- Cover
- Titel
- Impressum
- Inhaltsverzeichnis
- Einleitung
- Über den Autor
- Kapitel 1: Microservices
- 1.1 Was sind Microservices?
- 1.1.1 Klein und darauf spezialisiert, eine bestimmte Aufgabe richtig gut zu erledigen
- 1.1.2 Eigenständigkeit
- 1.2 Die wichtigsten Vorteile
- 1.2.1 Verschiedenartige Technologien
- 1.2.2 Belastbarkeit
- 1.2.3 Skalierung
- 1.2.4 Komfortables Deployment
- 1.2.5 Betriebliche Abstimmung
- 1.2.6 Modularer Aufbau
- 1.2.7 Austauschbarkeit
- 1.3 Was ist mit serviceorientierten Architekturen?
- 1.4 Weitere Verfahren zur Aufspaltung
- 1.4.1 Programmbibliotheken
- 1.4.2 Module
- 1.5 Kein Patentrezept
- 1.6 Fazit
- Kapitel 2: Der fortentwickelte Systemarchitekt
- 2.1 Unangebrachte Vergleiche
- 2.2 Das Zukunftsbild eines Systemarchitekten
- 2.3 Zoneneinteilung
- 2.4 Ein grundsätzlicher Ansatz
- 2.4.1 Strategische Ziele
- 2.4.2 Prinzipien
- 2.4.3 Praktiken
- 2.4.4 Prinzipien und Praktiken vereinigen
- 2.4.5 Ein Praxisbeispiel
- 2.5 Mindestvorgaben
- 2.5.1 Monitoring
- 2.5.2 Schnittstellen
- 2.5.3 Architektonische Sicherheit
- 2.6 Lenkung durch Code
- 2.6.1 Musterbeispiele
- 2.6.2 Maßgeschneiderte Servicevorlagen
- 2.7 Technische Schulden
- 2.8 Ausnahmebehandlung
- 2.9 Governance und Steuerung aus der Mitte
- 2.10 Aufbau eines Entwicklerteams
- 2.11 Fazit
- Kapitel 3: Gestaltung von Services
- 3.1 Kurz vorgestellt: MusicCorp
- 3.2 Wodurch zeichnet sich ein guter Service aus?
- 3.2.1 Lose Kopplung
- 3.2.2 Hochgradige Geschlossenheit
- 3.3 Begrenzter Kontext
- 3.3.1 Geteilte und verborgene Modelle
- 3.3.2 Module und Services
- 3.3.3 Verfrühte Aufteilung
- 3.4 Funktionalitäten des Kontexts
- 3.5 Schildkröten bis ganz unten
- 3.6 Kommunikation unter geschäftlichen Aspekten
- 3.7 Der technische Rahmen
- 3.8 Fazit
- Kapitel 4: Integration
- 4.1 Die Suche nach der optimalen Integrationsmethode
- 4.1.1 Zu Ausfällen führende Änderungen vermeiden
- 4.1.2 Technologieunabhängige APIs verwenden
- 4.1.3 Services für den Nutzer vereinfachen
- 4.1.4 Implementierungsdetails verbergen
- 4.2 Kundendatensätze
- 4.3 Gemeinsame Nutzung der Datenbank
- 4.4 Synchrone kontra asynchrone Kommunikation
- 4.5 Orchestrierung kontra Choreografie
- 4.6 Aufruf entfernter Prozeduren (RPC)
- 4.6.1 Kopplung von Technologien
- 4.6.2 Lokale Aufrufe sind keine entfernten Aufrufe
- 4.6.3 Fragilität
- 4.6.4 Ist RPC ein Übel?
- 4.7 REST
- 4.7.1 REST und HTTP
- 4.7.2 HATEOAS
- 4.7.3 JSON, XML oder etwas anderes?
- 4.7.4 Vorsicht vor zu viel Komfort
- 4.7.5 Nachteile von REST über HTTP
- 4.8 Implementierung asynchroner ereignisgesteuerter Kollaboration
- 4.8.1 Verfügbare Technologien
- 4.8.2 Die Kompliziertheit asynchroner Architekturen
- 4.9 Services als Zustandsautomaten
- 4.10 Reactive Extensions
- 4.11 DRY und die Gefahren der Wiederverwendung von Code im Microservices-Umfeld
- 4.11.1 Client-Bibliotheken
- 4.12 Zugriff über Referenzen
- 4.13 Versionierung
- 4.13.1 Solange wie möglich hinauszögern
- 4.13.2 Zu Ausfällen führende Änderungen rechtzeitig erkennen
- 4.13.3 Verwendung semantischer Versionierung
- 4.13.4 Mehrere Endpunkte gleichzeitig betreiben
- 4.13.5 Mehrere Serviceversionen gleichzeitig betreiben
- 4.14 Benutzerschnittstellen
- 4.14.1 Zunehmend digital
- 4.14.2 Voraussetzungen
- 4.14.3 Aufbau der API
- 4.14.4 Bausteine der Benutzeroberfläche
- 4.14.5 Back-Ends für Front-Ends
- 4.14.6 Ein Hybridansatz
- 4.15 Integration der Software von Drittherstellern
- 4.15.1 Fehlende Entscheidungsmöglichkeiten
- 4.15.2 Anpassungen
- 4.15.3 Integrationswirrwarr
- 4.15.4 Auf sich selbst gestellt
- 4.15.5 Das Strangler-Pattern
- 4.16 Fazit
- Kapitel 5: Die Aufspaltung des Monolithen
- 5.1 Seams
- 5.2 Aufspaltung von MusicCorp
- 5.3 Gründe zur Aufspaltung des Monolithen
- 5.3.1 Tempo der Änderungen
- 5.3.2 Teamstruktur
- 5.3.3 Sicherheitsaspekte
- 5.3.4 Technologie
- 5.4 Verwickelte Abhängigkeiten
- 5.5 Die Datenbank
- 5.6 Dem Problem zu Leibe rücken
- 5.7 Beispiel: Auflösen von Fremdschlüssel-Relationen
- 5.8 Beispiel: Statische Daten gemeinsam nutzen
- 5.9 Beispiel: Veränderliche Daten gemeinsam nutzen
- 5.10 Beispiel: Tabellen gemeinsam nutzen
- 5.11 Refactoring von Datenbanken
- 5.11.1 Die Aufspaltung umsetzen
- 5.12 Abgrenzung von Transaktionen
- 5.12.1 Versuchen Sie es später noch mal
- 5.12.2 Abbruch des gesamten Vorgangs
- 5.12.3 Verteilte Transaktionen
- 5.12.4 Was also tun?
- 5.13 Berichte
- 5.14 Datenbanken zur Berichterstellung
- 5.15 Datenabruf über Serviceaufrufe
- 5.16 Datenpumpen
- 5.16.1 Alternative Ziele
- 5.17 Ereignis-Datenpumpen
- 5.18 Backup-Datenpumpe
- 5.19 Benachrichtigung in Echtzeit
- 5.20 Änderungen verursachen Aufwand
- 5.21 Erkennen der eigentlichen Ursachen
- 5.22 Fazit
- Kapitel 6: Deployment
- 6.1 Continuous Integration für Einsteiger
- 6.1.1 Machen Sie es auch richtig?
- 6.2 Continuous Integration und Microservices
- 6.3 Build Pipelines und Continuous Delivery
- 6.3.1 Die unvermeidlichen Ausnahmen
- 6.4 Plattformspezifische Artefakte
- 6.5 Betriebssystemspezifische Artefakte
- 6.6 Selbsterstellte Images
- 6.6.1 Images als Artefakte
- 6.6.2 Unveränderliche Server
- 6.7 Umgebungen
- 6.7.1 Servicekonfiguration
- 6.7.2 Zuordnung der Services zu den Hosts
- 6.7.3 Mehrere Services pro Host
- 6.7.4 Anwendungscontainer
- 6.7.5 Ein Service pro Host
- 6.7.6 Platform-as-a-Service (PaaS)
- 6.8 Automatisierung
- 6.8.1 Zwei Fallstudien zur Leistungsfähigkeit der Automatisierung
- 6.9 Physisch wird virtuell
- 6.9.1 Herkömmliche Virtualisierung
- 6.9.2 Vagrant
- 6.9.3 Linux-Container
- 6.9.4 Docker
- 6.10 Schnittstelle für das Deployment
- 6.10.1 Definition der Umgebung
- 6.11 Fazit
- Kapitel 7: Testen
- 7.1 Testtypen
- 7.2 Testumfang
- 7.2.1 Unit-Tests
- 7.2.2 Servicetests
- 7.2.3 End-to-End-Tests
- 7.2.4 Nachteile
- 7.2.5 Wie viele Tests?
- 7.3 Implementierung von Servicetests
- 7.3.1 Mock-Objekte kontra Platzhalter
- 7.3.2 Ein intelligenterer Platzhalterservice
- 7.4 Knifflige End-to-End-Tests
- 7.5 Nachteile von End-to-End-Tests
- 7.5.1 Unzuverlässige und fragile Tests
- 7.5.2 Wer programmiert die Tests?
- 7.5.3 Testdauer
- 7.5.4 Das große Auftürmen
- 7.5.5 Die Metaversion
- 7.6 Abläufe testen, nicht Funktionalitäten
- 7.7 Abhilfe durch Consumer-Driven Tests
- 7.7.1 Pact
- 7.7.2 Konversationen
- 7.8 End-to-End-Tests: Pro und Kontra
- 7.9 Testen nach der Veröffentlichung
- 7.9.1 Deployment und Veröffentlichung trennen
- 7.9.2 Canary-Veröffentlichung
- 7.9.3 MTTR kontra MTBR
- 7.10 Funktionsübergreifende Tests
- 7.10.1 Geschwindigkeitstests
- 7.11 Fazit
- Kapitel 8: Monitoring
- 8.1 Ein Service, ein Server
- 8.2 Ein Service, mehrere Server
- 8.3 Mehrere Services, mehrere Server
- 8.4 Protokolle, Protokolle und noch mehr Protokolle
- 8.5 Kennzahlen mehrerer Services
- 8.6 Servicekennzahlen
- 8.7 Monitoringung von Pseudo-Ereignissen
- 8.7.1 Implementierung des semantischen Monitorings
- 8.8 Korrelations-IDs
- 8.9 Die Aufrufkette
- 8.10 Standardisierung
- 8.11 Zielgruppen
- 8.12 Wie geht es weiter?
- 8.13 Fazit
- Kapitel 9: Sicherheit
- 9.1 Authentifizierung und Autorisierung
- 9.1.1 Gängige Single-Sign-On-Implementierungen
- 9.1.2 Single-Sign-On-Gateway
- 9.1.3 Fein unterteilte Authentifizierung
- 9.2 Authentifizierung und Autorisierung von Services
- 9.2.1 Im internen Netzwerk ist alles erlaubt
- 9.2.2 Authentifizierung über HTTP(S)
- 9.2.3 Verwendung von SAML oder OpenID Connect
- 9.2.4 Client-Zertifikate
- 9.2.5 HMAC über HTTP
- 9.2.6 API-Schlüssel
- 9.2.7 Das Stellvertreterproblem
- 9.3 Schutz ruhender Daten
- 9.3.1 Wohlbekannte Verfahren einsetzen
- 9.3.2 Die Bedeutung der Schlüssel
- 9.3.3 Was soll verschlüsselt werden?
- 9.3.4 Entschlüsselung bei Bedarf
- 9.3.5 Backups verschlüsseln
- 9.4 Gestaffelte Sicherheitsstrategie
- 9.4.1 Firewalls
- 9.4.2 Protokollierung
- 9.4.3 Intrusion-Detection-Systeme
- 9.4.4 Unterteilung des Netzwerks
- 9.4.5 Betriebssystem
- 9.5 Ein ausgearbeitetes Beispiel
- 9.6 Datensparsamkeit
- 9.7 Der Faktor Mensch
- 9.8 Eine Goldene Regel
- 9.9 Integrierte Sicherheit
- 9.10 Externe Prüfung
- 9.11 Fazit
- Kapitel 10: Conways Gesetz und Systemdesign
- 10.1 Beweise
- 10.1.1 Lose und eng gekoppelte Organisationen
- 10.1.2 Windows Vista
- 10.2 Netflix und Amazon
- 10.3 Was kann man damit anfangen?
- 10.4 Anpassung an Kommunikationswege
- 10.5 Verantwortlichkeit für Services
- 10.6 Gemeinschaftliche Verantwortlichkeit für Services
- 10.6.1 Schwierige Aufspaltung
- 10.6.2 Feature-Teams
- 10.6.3 Engpässe bei der Auslieferung
- 10.7 Interner Open-Source-Code
- 10.7.1 Aufgaben der Koordinatoren
- 10.7.2 Ausgereifte Services
- 10.7.3 Werkzeugsammlungen
- 10.8 Begrenzte Kontexte und Teamstrukturen
- 10.9 Verwaiste Services?
- 10.10 Fallstudie: RealEstate.com.au
- 10.11 Conways Gesetz auf den Kopf gestellt
- 10.12 Menschen
- 10.13 Fazit
- Kapitel 11: Microservices skalieren
- 11.1 Ausfälle gibt es immer
- 11.2 Wie viel ist zu viel?
- 11.3 Schrittweiser Abbau der Funktionalität
- 11.4 Architektonische Sicherheitsmaßnahmen
- 11.5 Die antifragile Organisation
- 11.5.1 Timeouts
- 11.5.2 Circuit Breaker
- 11.5.3 Das Bulkhead-Pattern
- 11.5.4 Isolierung
- 11.6 Idempotenz
- 11.7 Skalierung
- 11.7.1 Mehr Leistung
- 11.7.2 Arbeitslast aufteilen
- 11.7.3 Risikoverteilung
- 11.7.4 Lastverteilung
- 11.7.5 Worker-Systeme
- 11.7.6 Neuanfang
- 11.8 Datenbanken skalieren
- 11.8.1 Verfügbarkeit des Services kontra Lebensdauer der Daten
- 11.8.2 Skalierung bei Lesevorgängen
- 11.8.3 Skalierung bei Schreibvorgängen
- 11.8.4 Gemeinsam genutzte Datenbankinfrastruktur
- 11.8.5 CQRS
- 11.9 Caching
- 11.9.1 Clientseitiges Caching, Proxy und serverseitiges Caching
- 11.9.2 Caching und HTTP
- 11.9.3 Caching bei Schreibvorgängen
- 11.9.4 Caching zur Erhöhung der Belastbarkeit
- 11.9.5 Den Ursprung verbergen
- 11.9.6 Möglichst einfach
- 11.9.7 Cache Poisoning: Ein warnendes Beispiel
- 11.10 Automatische Skalierung
- 11.11 Das CAP-Theorem
- 11.11.1 Aufgabe der Konsistenz
- 11.11.2 Aufgabe der Verfügbarkeit
- 11.11.3 Aufgabe der Partitionstoleranz?
- 11.11.4 AP oder CP?
- 11.11.5 Keine Frage eines Entweder-Oders
- 11.11.6 Abbildung der Wirklichkeit
- 11.12 Serviceerkennung
- 11.12.1 DNS
- 11.13 Dynamische Registrierung von Services
- 11.13.1 Zookeeper
- 11.13.2 Consul
- 11.13.3 Eureka
- 11.13.4 Eigene Serviceregistrierung
- 11.13.5 Menschliches Interesse
- 11.14 Services dokumentieren
- 11.14.1 Swagger
- 11.14.2 HAL und der HAL-Browser
- 11.15 Ein sich selbst beschreibendes System
- 11.16 Fazit
- Kapitel 12: Auf den Punkt gebracht
- 12.1 Prinzipien
- 12.1.1 Geschäftsvorgänge modellieren
- 12.1.2 Automatisierung kultivieren
- 12.1.3 Implementierungsdetails verbergen
- 12.1.4 Dezentralisierung
- 12.1.5 Unabhängiges Deployment
- 12.1.6 Ausfälle eingrenzen
- 12.1.7 Umfassendes Monitoring
- 12.2 Wann sollte man auf Microservices verzichten?
- 12.3 Schlusswort
- Stichwortverzeichnis
System requirements
File format: PDF
Copy protection: Watermark-DRM (Digital Rights Management)
System requirements:
- Computer (Windows; MacOS X; Linux): Use the free software Adobe Reader, Adobe Digital Editions, or any other PDF viewer of your choice (see eBook Help).
- Tablet/Smartphone (Android; iOS): Install the free app Adobe Digital Editions or another reading app for eBooks, e.g., PocketBook (see eBook Help).
- E-reader: Bookeen, Kobo, Pocketbook, Sony, Tolino and many more (only limited: Kindle).
The file format PDF always displays a book page identically on any hardware. This makes PDF suitable for complex layouts such as those used in textbooks and reference books (images, tables, columns, footnotes). Unfortunately, on the small screens of e-readers or smartphones, PDFs are rather annoying, requiring too much scrolling.
This eBook uses Watermark-DRM, a „soft” copy protection. This means that there are no technical restrictions to prevent illegal distribution. However, there is a personalised watermark embedded in the eBook that can be used to identify the purchaser of the eBook in the event of misuse and to provide evidence for legal purposes.
For more information, see our eBook Help page.