Architekturmuster Microservices

Autor: Simon Flühmann

Microservices ist ein Architektur-Ansatz für das Design von hochskalierbaren und robusten Applikationen, um den steigenden Anforderungen punkto Agilität, Verfügbarkeit und Wartbarkeit an heutige Softwaresysteme zu begegnen. Grosse IT-Unternehmen, wie LinkedIn oder Netflix, haben diesen Design-Approach geprägt. Im Gegensatz zu klassisch monolithisch aufgebauten Applikationen werden Microservice-Umgebungen aus mehreren kleinen Modulen – den Microservices – aufgebaut. Jeder Microservice kümmert sich eigenständig um eine dedizierte fachliche Aufgabe (Single Responsibility Principle). Jeder Microservice arbeitet komplett autonom, kann autonom entwickelt und in Produktion gebracht werden.

Eigenschaften einer Microservices-Architektur

• Autonomie: Microservices funktionieren für sich unabhängig. Dies bezieht sich sowohl auf die Laufzeit, wie auch auf die Entwicklung und das Deployment. Jeder Microservice kann eigenständig weiterentwickelt und ausgerollt werden. Auch technologisch sind die Module unabhängig voneinander – jeder Microservice implementiert einen eigenen Technologie-Stack. Das gilt auch für die Datenspeicherung. Resultat ist ein System mit polyglotter Persistenz in dem sich die Module keine Datenspeicher teilen.
• Entkopplung: Microservices sind untereinander stark entkoppelt. Sie kommunizieren nur über klar definierte und sprachunabhängige Schnittstellen. Die Entkopplung findet auf allen Ebenen statt (Datenhaltung, Security, Technologie, Architektur, Deployment, etc.). Module sind durch diese Entkopplung leicht austausch- und ersetzbar.
• Automatisierung: Microservices ermöglichen einen hohen Grad an Automatisierung für Deployments, Testing, Provisionierung und Skalierung. In Zusammenhang mit Continuous Delivery können dank einer Microservice-Architektur Releases unabhängig und schnell produktiv gesetzt werden. Dank minimaler Time-to-Market ist es möglich, schnell auf Änderungen und Trends zu reagieren.
• Skalierbarkeit: Microservices sind dafür gebaut ein System schnell und unkompliziert zu skalieren. Durch die Entkopplung können die Module unabhängig voneinander deployed werden. Neue Instanzen sind bei Bedarf dynamisch hochzuziehen und dann wieder abzubauen.
• Resilienz: Bei Teil-Ausfällen und Fehlern kann das System weiterhin funktionieren. Aufgrund der Entkopplung und Isolation der Module wirken Fehler und Latenzen nur lokal und haben nicht zwangsläufig einen Zusammenbruch der gesamten Applikation zur Folge. Die Komponenten haben die Fähigkeit sich selber zu regenerieren. Durch Entkopplung, kombiniert mit Skalierbarkeit und Replikation, können Hochverfügbarkeitsszenarien in einer Microservices-Architektur effektiv umgesetzt werden.
• Security: Die Kapselung erleichtert die Absicherung der einzelnen Module. Isolierte Microservices können gesondert mit Firewalls und Gateways abgesichert werden.
• Business Value: Effizienzsteigerung in der Entwicklung, Ersparnisse im Betrieb, Stabilität führt zu gutem Kundenerlebnis und weniger Ausfällen. Das System wächst und schrumpft dynamisch mit der Nachfrage der Kunden, neue Features sind in kürzester Zeit am Markt, verbesserte Testbarkeit vermindert das Risiko bei Releases.
• Organisationsaspekte: Voraussetzung für eine erfolgreiche Umsetzung einer Microservices-Architektur ist auch die passende organisatorische Struktur. Eine etablierte DevOps Kultur mit produktorientierten, agilen Teams, bildet eine wichtige Grundvoraussetzung für die erfolgreiche Entwicklung von Microservice-Applikationen. Weiterführende Informationen und Unterstützung zum Thema DevOps-Transformation erhalten Sie von unseren DevOps-Experten.

Die folgende Abbildung zeigt den schematischen Aufbau einer Microservice-Architektur. Die einzelnen Microservices bilden gemeinsam eine Applikation. Jeder Microservices kapselt eine eigene Business-Logik inklusive dazugehöriger Datenbank. Untereinander kommunizieren die Module über APIs und/oder über einen Message-Broker. Die Applikation exponiert Schnittstellen über ein Portal für Endkunden oder weitere Consumer.

Herausforderung der Datenhaltung bei Microservices

Ein kritischer Punkt bei der Umsetzung von Microservices ist die Datenhaltung. Der Grundgedanke ist eine konsequente Kapselung der Daten mit der Geschäftslogik, die auf den Daten operiert. Jeder Microservice muss seine eigenen Daten verwalten, die er zum autonomen Funktionieren benötigt. Konkret sollte jedes Modul einen eigenen, komplett unabhängigen Datenspeicher betreiben. Je nach Granularität und Komplexität der Architektur sowie dem Umfang des Systems ist das konsequente Verfolgen dieses Patterns in der Praxis eine Herausforderung.

Um dem zu begegnen gibt es deshalb verschiedene Variationen von Ansätzen, auf die in dieser dreiteiligen Blogserie eingegangen wird.

CAP Theorem

Bei der Wahl des geeigneten Modells für die Umsetzung der Datenhaltung in einer Microservices-Architektur sollte das CAP-Theorem zu Rate gezogen werden. CAP steht für:

• Consistency: Übergreifende Konsistenz der Daten im gesamten Software-System nach Abschluss einer Transaktion.
• Availability: Alle Anfragen an das System werden in jedem Fall beantwortet.
• Partition Tolerance: Fortbestehendes Funktionieren des Systems beim Ausfall von Daten.

Das CAP Theorem besagt, dass sich die drei Faktoren Konsistenz, Erreichbarkeit und Partitionstoleranz in einem verteilten System nicht gleichzeitig vollständig erfüllen lassen. Der Fokus kann also immer nur auf zwei der drei Faktoren gelegt werden. Die Schwierigkeit hier klug zu priorisieren begleitet einen ständig.

Der Faktor der Ausfall-Toleranz (P) sollte in jedem Fall erfüllt sein, da Latenzen aufgrund von Kommunikationsproblemen auf einem Netzwerk häufig auftreten. Eine gute Lösung ist also eine Kombination aus Partition Tolerance und einem weiteren Faktor. Beim Entwurf des Systems sollte sehr genau evaluiert werden, ob ein Microservice eher Hochverfügbarkeit (AP) oder Datenkonsistenz (CP) erfüllen sollte.