Was ist Microservices-Architektur?

Eine Microservices-Architektur ist eine Methode zur Erstellung von Anwendungen als Sammlung kleiner, eigenständiger Komponenten, die über ein Netzwerk mittels APIs interagieren. NIST SP 800-204 schreibt dem Ansatz eine kleinere Codebasis, unabhängige Teams und eine Skalierung pro Komponente zu.

Es ist, als hätte man eine Gruppe von Mitarbeitern, die alle koordiniert mit einer gemeinsamen Agenda arbeiten, wobei jeder aus einem bestimmten Fachgebiet heraus agiert. Dies unterscheidet sich von der früheren monolithischen Struktur, die wie ein einzelner Macher ist, der alles erledigt, und wenn die Anwendung an Komplexität gewinnt, wird sie umständlich zu kontrollieren.

Die Microservices-Architektur unterscheidet sich von der traditionellen monolithischen Architektur in folgenden Punkten:

• Dezentralisierung: Microservices nehmen Funktionalität und verteilen sie auf einzelne Dienste, während ein der Monolith alle Funktionalität innerhalb einer einzigen Codebasis kombiniert.
• Lose Kopplung: Microservices kommunizieren über APIs mit hoher Kohäsion und geringer Kopplung, während bei Monolithen Komponenten in der Regel gekoppelt und kohäsiv sind.
• Unabhängige Bereitstellung: Microservices ermöglichen den Austausch oder die Bereitstellung eines einzelnen Dienstes ohne Ausfallzeiten des gesamten Systems, während Änderungen innerhalb einer monolithischen Architektur eine Bereitstellungskooperation erfordern.
• Skalierbarkeit: Microservices können unabhängig voneinander an die Benutzeranforderungen angepasst werden, während Ansätze wie monolithische Skalierung über die gesamte Anwendung hinweg erfordern.
• Fehlerisolierung: Bei Microservices hat der Ausfall eines Dienstes keine Auswirkungen auf die übrigen Dienste, während bei monolithischen Diensten der Ausfall einer Komponente zum Ausfall der gesamten Anwendung führen kann.

Die Einführung einer Microservices-Architektur tauscht betriebliche Komplexität gegen unabhängige Skalierung und Fehlerisolierung ein.

Vorteile:

• Skalierbarkeit: Entwicklung bestimmter Dienste in einem bestimmten Umfang entsprechend der Nachfrage, sodass die Ressourcenauslastung effizient ist.
• Erhöhte Agilität: Unabhängige Entwicklung und Bereitstellung beziehen sich auf einen schnelleren Zyklusstart und eine schnellere Reaktion auf Änderungen.
• Technologieflexibilität: Die Fähigkeit jedes Dienstes, geeignete Sprachen und Tools zu verwenden, ist ein Faktor, der sich auf Innovation und Serviceoptimierung auswirken kann.
• Fehlerisolierung: Um die Auswirkungen von Dienstausfällen zu reduzieren und die Systemstabilität zu verbessern.
• Wartbarkeit: Jeder kleine, spezifische Dienst ist einfacher zu verstehen, zu entwickeln und zu verwalten als ein einziger, alles umfassender Dienst.

Herausforderungen:

• Erhöhte Komplexität: Die Verwaltung verteilter Systeme erfordert aufgrund der inhärenten Komplexität einen komplexeren Ansatz als zentralisierte Systeme.
• Datenmanagement: Im Datenmanagement sind separate Datenspeicher für jeden Dienst oft mit einer eventuellen Datenkonsistenz über diese Dienste hinweg verbunden, anstatt mit sofortiger Konsistenz.
• Testen: Es ist wichtig, alle einfachen und komplexen Tests durchzuführen, um die Kompatibilität aller Dienste und die Stabilität des gesamten Systems nach seiner Bereitstellung sicherzustellen.
• Kommunikation: Die Kommunikation zwischen Diensten ist entscheidend für einen effizienten Betrieb, bringt jedoch Latenz und mögliche Fehlerbereiche mit sich.
• Sicherheit: Die Sicherung sensibler Daten über mehrere Dienste hinweg muss gut geplant und ausgeführt werden, um Sicherheitslücken zu vermeiden.

Microservices interagieren hauptsächlich über APIs (Application Programming Interfaces), die beschreiben, wie Daten ausgetauscht werden und in welchem Format. Zu solchen Kommunikationsmustern gehören:

• Synchrone Anforderungsantwort: Ein Dienst leitet eine Anforderung an einen anderen Dienst weiter und erwartet, dass dieser antwortet. Dies ist einfach, kann aber bei schlechter Verwaltung zu enger Kopplung und Leistungsproblemen führen. Üblicherweise REST über HTTP oder gRPC für geringere Latenz; externe Clients greifen über ein API-Gateway zu. Eine REST-API ist der Zugang zu einem Dienst, nicht der Dienst selbst.
• Asynchrones Messaging: Dienste tauschen Nachrichten über einen Message-Broker aus, um die Entkopplung zu gewährleisten und mehr Skalierbarkeit zu erreichen. Dieses Muster ist am effektivsten, wenn eine große Menge an Daten oder Ereignissen verarbeitet werden muss. Der Broker ist üblicherweise Apache Kafka oder RabbitMQ, nicht der Mikroservice selbst.
• Ereignisgesteuerte Architektur: Dienste veröffentlichen Ereignisse, denen andere Dienste dann lauschen können, um zu fördern lose Kopplung und Reaktionsfähigkeit. Dieses Muster passt gut zu Situationen, in denen Aktualisierungen oder Änderungen über mehrere Dienste hinweg erforderlich sind.

Zu den Best Practices gehören:

• Domänengesteuertes Design (DDD): Das System zerlegen in begrenzte Kontexte die Geschäftsfunktionen abdecken, die die Lesbarkeit und Wartbarkeit des Systems verbessern werden.
• API-First-Design: Richten Sie klare und gut dokumentierte Schnittstellen ein, über die Dienste im System zusammenarbeiten müssen, um Konsistenz und einfache Integration zu gewährleisten.
• Containerisierung: Teilen Sie Dienste in Pakete auf und legen Sie sie in Bereitstellungscontainer, um eine bessere Kontrolle und einfache Skalierung von Lösungen. Das bedeutet sie in Docker-Containern bereitstellen die Kubernetes terminiert: 82 % der Container-Nutzer betreiben Kubernetes in der Produktion (CNCF, 2026).
• Kontinuierliche Integration und kontinuierliche Bereitstellung (CI/CD): Standardisieren Sie Build, Test und Bereitstellung mit regelmäßigen, vorhersehbaren und wiederholbaren Releases.
• Monitoring und Beobachtbarkeit: Protokollieren und überwachen Sie den Servicestatus und die Leistung, um sicherzustellen, dass sie gut erfasst und dokumentiert sind, sodass die Grundursache im Falle eines Problems leicht identifiziert werden kann.

Beispiele aus der Praxis für erfolgreiche Microservices sind:

• Netflix: Implementierte eine auf Microservices basierende Architektur, um die globale Expansion zu unterstützen und hohe Verkehrsaufkommen für ihren Streaming-Dienst zu bewältigen.
• Amazon: Die E-Commerce-Website entschied sich für ein eine Microservices-Architektur, nachdem sie von ihrem früheren monolithischen Design migriert war, mit dem Ziel, die Anpassungsfähigkeit und Vielseitigkeit zu verbessern.
• Uber: Microservices verwalten Fahrtenanfragen, Zahlungen und Fahrer separat und erleichtern so das Wachstum.

Beide Netflix und Amazon begannen als Monolithen und teilten sie später auf: Bauen Sie die Module innerhalb einer Anwendung, und lagern Sie dann das Modul aus, dessen Skalierung Schwierigkeiten bereitet.