Inhaltsverzeichnis

Impressum

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

Microservices

Konzeption und Design

Sam Newman

Übersetzung aus dem Amerikanischen von Knut Lorenzen

Impressum

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.

ISBN 978-3-95845-083-7

1. Auflage 2015

www.mitp.de

E-Mail: mitp-verlag@sigloch.de

Telefon: +49 7953 / 7189 - 079

Telefax: +49 7953 / 7189 - 082

© 2015 mitp Verlags GmbH & Co. KG

Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen.

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürften.

Authorized German translation of the English edition of Building Microservices ISBN 9781491950357 © 2015 Sam Newman. This translation is published and sold by permission of O’Reilly Media, Inc., which owns or controls all rights to publish and sell the same.

Lektorat: Sabine Schulz

Sprachkorrektorat: Maren Feilen

Coverbild: © Irochka, fotolia.de

electronic publication: III-satz, Husby, www.drei-satz.de

Dieses Ebook verwendet das ePub-Format und ist optimiert für die Nutzung mit dem iBooks-reader auf dem iPad von Apple. Bei der Verwendung anderer Reader kann es zu Darstellungsproblemen kommen.

Der Verlag räumt Ihnen mit dem Kauf des ebooks das Recht ein, die Inhalte im Rahmen des geltenden Urheberrechts zu nutzen. Dieses Werk, einschließlich aller seiner Teile, ist urheberrechtlich geschützt. Jede Verwertung außerhalb der engen Grenzen des Urheherrechtsgesetzes ist ohne Zustimmung des Verlages unzulässig und strafbar. Dies gilt insbesondere für Vervielfältigungen, Übersetzungen, Mikroverfilmungen und Einspeicherung und Verarbeitung in elektronischen Systemen.

Der Verlag schützt seine ebooks vor Missbrauch des Urheberrechts durch ein digitales Rechtemanagement. Bei Kauf im Webshop des Verlages werden die ebooks mit einem nicht sichtbaren digitalen Wasserzeichen individuell pro Nutzer signiert.

Bei Kauf in anderen ebook-Webshops erfolgt die Signatur durch die Shopbetreiber. Angaben zu diesem DRM finden Sie auf den Seiten der jeweiligen Anbieter.

Einleitung

Microservices sind ein Ansatz für verteilte Systeme, die die Nutzung feingranularer Services mit eigenen Entwicklungszyklen fördern, die sich gegenseitig zuarbeiten. Da Microservices vornehmlich im geschäftlichen Umfeld Anwendung finden, werden die bei herkömmlichen abgestuften Architekturen auftretenden Schwierigkeiten umgangen. Microservices nutzen außerdem die während des letzten Jahrzehnts entwickelten Technologien und Verfahren und vermeiden dadurch die Fallstricke, die mit vielen serviceorientierten Architekturen einhergehen.

Dieses Buch enthält eine Reihe konkreter Beispiele dafür, wie Microservices weltweit eingesetzt werden, etwa in Unternehmen wie Netflix, Amazon, Gilt und der REA-Gruppe, die allesamt festgestellt haben, dass ihnen die erhöhte Unabhängigkeit dieser Architektur große Vorteile bringt.

Wer sollte dieses Buch lesen?

Der Anwendungsbereich dieses Buches umfasst ein breites Spektrum, ebenso wie auch die Auswirkungen einer feingranularen Microservice-Architektur vielgestaltig sind. Es soll Leser ansprechen, die an verschiedenen Aspekten des Designs, der Entwicklung, des Deployments, des Testens und der Wartung dieser Systeme interessiert sind. Diejenigen Leser, die bereits damit begonnen haben, sich mit feiner unterteilten Architekturen zu beschäftigen – sei es nun einer vollkommen neuen Anwendung oder der Aufteilung eines bereits vorhandenen, eher monolithischen Systems –, werden viele praktische Ratschläge finden. Und auch denjenigen Lesern, die im Grunde nur wissen möchten, was der ganze Rummel eigentlich soll, wird geholfen, damit sie entscheiden können, ob Microservices für ihre Zwecke geeignet sind.

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!

Lesen Sie weiter in der vollständigen Ausgabe!