Microservices (mitp Professional)

Konzeption und Design

Sam Newman

Diese Publikation zitieren

Sam Newman, Microservices (mitp Professional) (2015), mitp-Verlag, Frechen, ISBN: 9783958450820

1946
Accesses
52
Quotes

Beschreibung / Abstract

* Feingranulare Systeme mit Microservices aufbauen
* Design, Entwicklung, Deployment, Testen und Monitoring
* Sicherheitsaspekte, Authentifizierung und Autorisierung


Verteilte Systeme haben sich in den letzten Jahren stark verändert: Große monolithische Architekturen werden zunehmend in viele kleine, eigenständige Microservices aufgespalten. Aber die Entwicklung solcher Systeme bringt Herausforderungen ganz eigener Art mit sich. Dieses Buch richtet sich an Softwareentwickler, die sich über die zielführenden Aspekte von Microservice-Systemen wie Design, Entwicklung, Testen, Deployment und Monitoring informieren möchten.

Sam Newman veranschaulicht und konkretisiert seine ganzheitliche Betrachtung der grundlegenden Konzepte von Microservice-Architekturen anhand zahlreicher praktischer Beispiele und Ratschläge. Er geht auf die Themen ein, mit denen sich Systemarchitekten und Administratoren bei der Einrichtung, Verwaltung und Entwicklung dieser Architekturen in jedem Fall auseinandersetzen müssen.


Aus dem Inhalt:
* Vorteile von Microservices
* Gestaltung von Services
* Ausrichtung der Systemarchitektur an der Organisationsstruktur
* Möglichkeiten zur Integration von Services
* Schrittweise Aufspaltung einer monolithischen Codebasis
* Deployment einzelner Microservices mittels Continuous Integration
* Testen und Monitoring verteilter Systeme
* Sicherheitsaspekte
* Authentifizierung und Autorisierung zwischen Benutzer und Service bzw. zwischen Services untereinander
* Skalierung von Microservice-Architekturen

»Microservice-Architekturen besitzen viele interessante Eigenschaften, allerdings sind bei der Umstellung so einige Fallstricke zu beachten. Dieses Buch wird Ihnen helfen herauszufinden, ob Microservices für Ihre Zwecke geeignet sind und zeigt Ihnen, wie Sie die Fallstricke umgehen können.«

Martin Fowler, Chief Scientist, ThoughtWorks

Beschreibung

Sam Newman ist als Technologist bei ThoughtWorks tätig, wo er einerseits als Berater arbeitet und andererseits auch als Systemarchitekt für die unternehmenseigenen Systeme verantwortlich ist. Im Rahmen seiner Beratertätigkeit arbeitete er mit zahlreichen weltweit tätigen Unternehmen aus den unterschiedlichsten Geschäftsbereichen sowohl im Bereich der Entwicklung als auch des Betriebs von Microservice-Architekturen zusammen.

Inhaltsverzeichnis

  • Cover
  • Titel
  • Impressum
  • Inhaltsverzeichnis
  • Einleitung
  • Über den Autor
  • Kapitel 1: Microservices
  • 1.1 Was sind Microservices?
  • 1.2 Die wichtigsten Vorteile
  • 1.3 Was ist mit serviceorientierten Architekturen?
  • 1.4 Weitere Verfahren zur Aufspaltung
  • 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.5 Mindestvorgaben
  • 2.6 Lenkung durch Code
  • 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.3 Begrenzter Kontext
  • 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.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.7 REST
  • 4.8 Implementierung asynchroner ereignisgesteuerter Kollaboration
  • 4.9 Services als Zustandsautomaten
  • 4.10 Reactive Extensions
  • 4.11 DRY und die Gefahren der Wiederverwendung von Code im Microservices-Umfeld
  • 4.12 Zugriff über Referenzen
  • 4.13 Versionierung
  • 4.14 Benutzerschnittstellen
  • 4.15 Integration der Software von Drittherstellern
  • 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.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.12 Abgrenzung von Transaktionen
  • 5.13 Berichte
  • 5.14 Datenbanken zur Berichterstellung
  • 5.15 Datenabruf über Serviceaufrufe
  • 5.16 Datenpumpen
  • 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.2 Continuous Integration und Microservices
  • 6.3 Build Pipelines und Continuous Delivery
  • 6.4 Plattformspezifische Artefakte
  • 6.5 Betriebssystemspezifische Artefakte
  • 6.6 Selbsterstellte Images
  • 6.7 Umgebungen
  • 6.8 Automatisierung
  • 6.9 Physisch wird virtuell
  • 6.10 Schnittstelle für das Deployment
  • 6.11 Fazit
  • Kapitel 7: Testen
  • 7.1 Testtypen
  • 7.2 Testumfang
  • 7.3 Implementierung von Servicetests
  • 7.4 Knifflige End-to-End-Tests
  • 7.5 Nachteile von End-to-End-Tests
  • 7.6 Abläufe testen, nicht Funktionalitäten
  • 7.7 Abhilfe durch Consumer-Driven Tests
  • 7.8 End-to-End-Tests: Pro und Kontra
  • 7.9 Testen nach der Veröffentlichung
  • 7.10 Funktionsübergreifende Tests
  • 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.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.2 Authentifizierung und Autorisierung von Services
  • 9.3 Schutz ruhender Daten
  • 9.4 Gestaffelte Sicherheitsstrategie
  • 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.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.7 Interner Open-Source-Code
  • 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.6 Idempotenz
  • 11.7 Skalierung
  • 11.8 Datenbanken skalieren
  • 11.9 Caching
  • 11.10 Automatische Skalierung
  • 11.11 Das CAP-Theorem
  • 11.12 Serviceerkennung
  • 11.13 Dynamische Registrierung von Services
  • 11.14 Services dokumentieren
  • 11.15 Ein sich selbst beschreibendes System
  • 11.16 Fazit
  • Kapitel 12: Auf den Punkt gebracht
  • 12.1 Prinzipien
  • 12.2 Wann sollte man auf Microservices verzichten?
  • 12.3 Schlusswort
  • Stichwortverzeichnis

Ähnliche Titel

    Mehr von diesem Autor