Microservices konzeption und Design
* 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 kle...
| Otros Autores: | , , |
|---|---|
| Formato: | Libro electrónico |
| Idioma: | Alemán |
| Publicado: |
[Frechen, Germany] :
mitp
2015.
|
| Edición: | 1. Auflage |
| Materias: | |
| Ver en Biblioteca Universitat Ramon Llull: | https://discovery.url.edu/permalink/34CSUC_URL/1im36ta/alma991009630070406719 |
Tabla de Contenidos:
- 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 Patentrezept1.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 Mitte2.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 Integrationsmethode4.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
