Das Microservices-Praxisbuch

Grundlagen, Konzepte und Rezepte

Eberhard Wolff

• Verlag: dpunkt.verlag
• Jahr: 2018
• eBook-ISBN: 9783960884620
• Thema: Informatik
• Thema: Softwareentwicklung

Microservices haben viele Vorteile: Effizient mehr Features umsetzen, Software schneller in Produktion bringen, Robustheit und einfache Skalierbarkeit zählen dazu. Aber die Implementierung einer Microservices-Architektur und die Auswahl der notwendigen Technologien sind schwierige Herausforderungen. Dieses Buch zeigt Microservices-Rezepte, die Architekten anpassen und zu einem Microservices-Menü kombinieren können. So kann die Implementierung der Microservices individuell auf die Anforderungen im Projekt angepasst werden. Eberhard Wolff führt zunächst in Microservices, Self-contained Systems, Mikro- und Makro-Architektur und die Migration hin zu Microservices ein. Der zweite Teil zeigt die Microservices-Rezepte: Basis-Technologien wie Docker oder PaaS, Frontend-Integration mit Links, JavaScript oder ESI (Edge Side Includes). Es schließen sich asynchrone Microservices mit Apache Kafka oder REST Atom an. Bei den synchronen Ansätzen bespricht das Buch REST mit dem Netflix-Stack, Consul und Kubernetes. Zu jedem Rezept gibt es Hinweise zu Variations- und Kombinationsmöglichkeiten. Der Ausblick greift den Betrieb von Microservices auf und zeigt außerdem, wie der Leser ganz konkret mit Microservices beginnen kann. Das Buch bietet das technische Rüstzeug, um eine Microservices-Architektur umzusetzen. Demo-Projekte und Anregungen für die Vertiefung im Selbststudium runden das Buch ab.

Teil II

Technologie-Stacks

Im zweiten Teil des Buchs geht es um Rezepte für Technologien, mit denen Microservices umgesetzt werden können.

Docker

Zunächst gibt Kapitel 5 eine Einführung in Docker. Docker bietet eine gute Grundlage für die Umsetzung von Microservices und ist die Basis für die Beispiele im Buch. Ein Studium des Kapitels ist daher notwendig, wenn man die Beispiele in den späteren Kapiteln nachvollziehen will.

Technische Mikro-Architektur

Kapitel 2 hat die Begriffe Mikro- und Makro-Architektur eingeführt. MikroArchitektur sind Entscheidungen, die für jeden Microservice anders getroffen werden können. Makro-Architektur sind die Entscheidungen, die für alle Microservices einheitlich sind. Kapitel 6 diskutiert technische Möglichkeiten für die Implementierung der Mikro-Architektur-Entscheidungen eines Microservices.

Frontend-Integration

Eine Möglichkeit zur Integration von Microservices ist die Frontend-Integration, die Kapitel 7 erläutert. Eine konkrete technische Umsetzung mit Links und clientseitiger Integration mit JavaScript zeigt Kapitel 8. Kapitel 9 zeigt Edge Side Includes (ESI), die eine UI-Integration auf dem Server bieten.

Asynchrone Microservices

Asynchrone Microservices stellt Kapitel 10 dar. Das Kapitel 11 erläutert Apache Kafka als Beispiel für eine Middleware, die zur Implementierung von asynchronen Microservices genutzt werden kann. Atom (Kapitel 12) ist ein Datenformat, das für die asynchrone Kommunikation über REST nützlich sein kann.

Synchrone Microservices

Synchrone Microservices erläutert Kapitel 13. Der Netflix-Stack (Kapitel 14) ist eine Möglichkeit, um synchrone Microservices umzusetzen. Der Stack umfasst Lösungen für Load Balancing, Service Discovery und Resilience. Kapitel 15 zeigt eine Alternative mit Consul für Service Discovery und Apache httpd für Load Balancing.

Microservices-Plattformen

Microservices-Plattformen (Kapitel 16) stellen neben einer Unterstützung für synchrone Kommunikation auch eine Ablaufumgebung für Deployment und Betrieb bereit. Kapitel 17 zeigt, wie synchrone Microservices mit Kubernetes umgesetzt werden können. Kubernetes dient als Ablaufumgebung für Docker-Container und hat Features u.a. für Load Balancing und Service Discovery.

Kapitel 18 beschreibt PaaS (Platform as a Service). Ein PaaS ermöglicht es, den Betrieb und das Deployment der Microservices zum größten Teil der Infrastruktur zu überlassen. Als Beispiel für ein PaaS wird Cloud Foundry erläutert.

5Docker-Einführung

Dieses Kapitel gibt eine Einführung in Docker. Das Kapitel vermittelt folgende Inhalte:

• Der Leser ist nach dem Studium des Kapitels in der Lage, die Beispiele in den folgenden Kapiteln in einer Docker-Umgebung zum Laufen zu bringen.
• Docker und Microservices sind nahezu synonym. Dieses Kapitel zeigt, warum Docker so gut zu Microservices passt.
• Docker vereinfacht die Installation von Software. Wichtig dafür ist das Dockerfile, das auf einfache Art und Weise die Installation der Software beschreibt.
• Docker Machine und Docker Compose unterstützen Docker auf Server-Systemen und komplexe Software-Umgebungen mit Docker.
• Das Kapitel legt die Basis für ein Verständnis von Technologien wie Kubernetes (Kapitel 17) und Cloud Foundry (Kapitel 18), die auf Docker basieren.

Die Grundlagen von Docker sind einfach zu erlernen. Es gibt allerdings auch Bücher, die ganz auf Docker fokussieren.¹

Lizenzen und Projekte

Docker steht unter der Apache-2.0-Lizenz. Es wird unter anderem von der Firma Docker, Inc (https://www.docker.com/) entwickelt. Einige Kernkomponenten wie beispielsweise Moby (https://github.com/moby/moby) stehen unter Open-Source-Lizenzen und ermöglichen es so auch anderen Entwicklern, ähnliche Systeme wie Docker zu implementieren. Docker basiert auf Linux-Containern, die Prozesse in Linux-Systemen sehr stark gegeneinander isolieren. Die Open Container Initiative (https://www.opencontainers.org/) sorgt durch Standardisierung für die Kompatibilität der verschiedenen Container-Systeme.

5.1Docker für Microservices: Gründe

Kapitel 1 hat Microservices als getrennt deploybare Einheiten definiert. Das getrennte Deployment ergibt nicht nur eine Entkopplung auf Ebene der Architektur, sondern auch bei der Technologiewahl, der Robustheit, der Sicherheit und der Skalierbarkeit.

5.1.1Prozesse reichen für Microservices nicht aus.

Wenn Microservices tatsächlich alle diese Eigenschaften aufweisen sollen, stellt sich die Frage, wie sie umgesetzt werden können. Microservices müssen unabhängig voneinander skaliert werden. Ein Microservice darf bei einem Absturz andere Microservices nicht mitreißen und so die Robustheit gefährdet. Also müssen Microservices mindestens getrennte Prozesse sein.

Die Skalierbarkeit kann durch mehrere Instanzen eines Prozesses gewährleistet werden. Wenn eine Anwendung gestartet wird, so erzeugt das Betriebssystem einen Prozess und weist ihm Ressourcen wie CPU oder Speicher zu. Für die Skalierbarkeit können in einem Prozess mehrere Threads aktiv sein. Jeder Thread hat einen eigenen Ausführungszustand. Ein Prozess kann jeden Request mit einem Thread abarbeiten.

Für die Skalierung sind Prozesse trotz der Unterstützung von Threads nicht ausreichend: Wenn die Prozesse alle auf einem Server laufen, dann steht nur eine begrenzte Menge an Hardware-Ressourcen bereit. Die Isolation in Prozesse ist also für die Skalierbarkeit nicht ausreichend.

Die Robustheit ist bei Prozessen bis zu einem gewissen Maße gewährleistet, weil der Absturz eines Prozesses die anderen Prozesse nicht beeinflusst. Ein Ausfall eines Servers bringt immer noch eine Vielzahl von Prozessen und damit Microservices zum Absturz. Es gibt aber noch andere Probleme. Alle Prozesse teilen sich ein Betriebssystem. Es muss die Bibliotheken und Werkzeuge für alle Microservices mitbringen. Jeder Microservice muss mit der Version des Betriebssystems kompatibel sein. Es ist schwierig, das Betriebssystem so zu konfigurieren, dass es für alle Microservices passt. Außerdem müssen die Prozesse sich so koordinieren, dass jeder Prozess einen eigenen Netzwerk-Port hat. Man verliert bei solchen Ansätzen sehr schnell den Überblick über die genutzten Ports.

5.1.2Virtuelle Maschinen sind zu schwergewichtig für Microservices

Statt eines Prozesses kann jeder Microservice in einer eigenen virtuellen Maschine laufen. Virtuelle Maschinen sind simulierte Rechner, die gemeinsam auf derselben Hardware laufen. Für das Betriebssystem und die Anwendung sehen virtuelle Maschinen genauso aus wie ein Hardware-Server. Durch die Virtualisierung hat der Microservice ein eigenes Betriebssystem. So kann die Konfiguration des Betriebssystems auf den Microservice abgestimmt sein und es besteht auch vollkommene Freiheit bei der Wahl des Ports.

Aber eine virtuelle Maschine hat einen erheblichen Overhead:

• Die virtuelle Maschine muss dem Betriebssystem die Illusion geben, direkt auf der Hardware zu laufen. Das führt zu einem Overhead. Daher ist die Performance schlechter als bei physischer Hardware.
• Jeder Microservice hat eine eigene Instanz des Betriebssystems. Das verbraucht viel Speicher im RAM.
• Schließlich hat die virtuelle Maschine virtuelle Festplatten mit einer vollständigen Betriebssysteminsta...

Inhaltsverzeichnis

• Cover
• Über den Autor
• Titel
• Impressum
• Inhaltsübersicht
• Inhaltsverzeichnis
• Einleitung
• Teil I Architekturgrundlagen
• Teil II Technologie-Stacks
• Teil III Betrieb
• Anhang
• Index
• Fußnoten