Was sind Microservices?

Was sind Microservices?

Microservices sind ein Architekturstil, bei dem eine Anwendung aus mehreren kleinen Diensten besteht. Jeder läuft in einem eigenen Prozess, verantwortet eine fachliche Aufgabe und kommuniziert über klar definierte APIs mit den anderen. Jeder Dienst lässt sich bereitstellen, skalieren und aktualisieren, ohne den Rest neu auszuliefern. Das Gegenstück ist der Monolith, bei dem alle Funktionen als eine Einheit ausgeliefert werden. Der Tausch: einfachere Einzeldienste, dafür ein insgesamt komplexeres System.

So funktioniert ein Microservices-System

• Dienste entlang fachlicher Aufgaben. Ein Shop könnte getrennte Dienste für Katalog, Warenkorb, Zahlung und Versand haben, jeweils mit eigener Codebasis und einem verantwortlichen Team.
• Kommunikation über das Netzwerk. Dienste rufen sich synchron über API-Endpunkte (meist REST oder gRPC) oder asynchron über einen Message Broker wie Kafka oder eine Queue auf.
• Eigene Daten je Dienst. Jeder Dienst hat seinen eigenen Datenspeicher, andere lesen ihn nur über dessen API. Das hält die Dienste unabhängig, bedeutet aber: keine einzelne Datenbanktransaktion über mehrere Dienste.
• Ein API-Gateway. Clients rufen einen Einstiegspunkt auf, der Anfragen an den richtigen Dienst weiterleitet und gemeinsame Aufgaben wie die Authentifizierung übernimmt.
• Automatisierung darunter. Unabhängiges Deployment braucht CI/CD, meist Container und einen Orchestrator wie Kubernetes, dazu zentrales Logging, Metriken und verteiltes Tracing.

Martin Fowler und James Lewis nennen neun typische Merkmale, darunter dezentrale Datenhaltung, Infrastrukturautomatisierung, Design für Ausfälle und evolutionäres Design. Sie weisen darauf hin, dass nicht jedes System alle neun aufweist.

Vorteile

• Unabhängiges Deployment. Ein Fix in einem Dienst wartet nicht auf das Release von allem anderen.
• Gezielte Skalierung. Skalieren Sie die Dienste unter Druck, nicht die ganze Anwendung.
• Fehlerisolation. Fällt ein Dienst aus, können die anderen weiterlaufen, sofern die Aufrufer den Fehler behandeln, etwa mit Timeouts und Circuit Breakern.
• Autonomie der Teams. Kleine Teams verantworten einen Dienst von Anfang bis Ende und können unterschiedliche Technologien wählen.

Die Kosten

Das Azure Architecture Center von Microsoft nennt die Nachteile klar: mehr bewegliche Teile, schwierigeres Testen über Dienstabhängigkeiten hinweg, Datenkonsistenz ohne ACID-Transaktionen über Dienste (stattdessen Eventual Consistency), Versionierung jeder API, zusätzliche Netzwerklatenz und der Bedarf an reifen DevOps-Fähigkeiten. Fowler und Lewis ergänzen, dass eine Aufteilung Komplexität in die Verbindungen zwischen den Diensten verlagern kann, wo sie schwerer zu sehen ist. Für ein kleines Team oder ein junges Produkt ist ein gut strukturierter Monolith oft der bessere Start.

Häufige Fehler

• Dienste nach technischer Schicht statt nach Fachlichkeit geschnitten. Die Folge sind Änderungen, die immer mehrere Dienste betreffen.
• Eine gemeinsame Datenbank. Geteilte Schemata koppeln die Dienste und nehmen den größten Teil des Nutzens.
• Geschwätzige Dienste. Lange Aufrufketten (A ruft B ruft C) summieren sich in der Latenz und lassen Fehler durchschlagen.
• Keine Timeouts, Retries oder Circuit Breaker. Eine langsame Abhängigkeit bremst dann jeden Aufrufer.
• Zu viele Dienste zu früh. Dutzende Dienste zu betreiben erfordert Werkzeuge, die kleine Teams meist nicht haben.
• Schwache Observability. Ohne korrelierte Logs und Traces ist die Suche nach dem fehlerhaften Dienst in einer Aufrufkette Raten.

Microservices, Lasttests und Monitoring

Jeder Dienst hat seine eigene Kapazitätsgrenze, und ein langsamer Dienst kann alles herunterziehen, was ihn aufruft. Testen Sie deshalb einzelne Dienste und die gesamte Aufrufkette. Ein Lasttest zeigt, wo der Durchsatz abflacht und welcher Dienst zuerst an seine Grenze stößt. LoadFocus führt JMeter- und k6-Tests aus 25 Cloud-Regionen aus, der Free-Plan enthält bis zu 10 virtuelle Nutzer. In Produktion prüft API-Monitoring jeden Dienst-Endpunkt planmäßig auf Status, Body und Antwortzeit (im Free-Plan alle 5 Minuten), und Observability-Werkzeuge führen die Signale zusammen. Siehe LoadFocus API-Monitoring. Eine Schritt-für-Schritt-Anleitung bietet der Leitfaden zum Lasttest von Microservices in der Cloud (auf Englisch). Wer zuerst die Schnittstellen entwirft, ist mit dem API-First-Ansatz gut bedient.

Häufige Fragen: Microservices

Was ist der Unterschied zwischen Microservices und einem Monolithen?

Ein Monolith liefert alle Funktionen als eine Einheit aus. Microservices teilen sie in separat bereitgestellte Dienste mit eigenen Daten auf. Sie ermöglichen unabhängige Skalierung und Releases, bringen aber Netzwerkaufrufe, verteilte Daten und mehr Betriebsaufwand mit.

Wann sollte ich Microservices einsetzen?

Wenn mehrere Teams unabhängig releasen müssen, Teile des Systems sehr unterschiedlich skalieren und Sie bereits solides CI/CD und Monitoring haben. Für ein kleines Team oder ein frühes Produkt starten Sie besser mit einem modularen Monolithen.

Wie kommunizieren Microservices?

Synchron über HTTP-APIs (REST oder gRPC) oder asynchron über Nachrichten und Events auf einem Broker oder einer Queue. Asynchrone Nachrichten verringern die Kopplung und passen zu Abläufen ohne sofortige Antwort.

Wie geht man mit Daten in Microservices um?

Jeder Dienst besitzt seine Daten und stellt sie über eine API bereit. Änderungen über mehrere Dienste hinweg nutzen Eventual Consistency, etwa über Events, statt einer einzigen ACID-Transaktion.

Wie testet man Microservices?

Kombinieren Sie Unit-Tests je Dienst, Contract-Tests für die Vereinbarung zwischen Aufrufer und Anbieter, Integrationstests für zentrale Abläufe und Lasttests für einzelne Dienste und die gesamte Kette.

Sind Microservices dasselbe wie eine API?

Nein. Eine API ist eine Schnittstelle. Ein Microservice ist ein einzeln bereitstellbarer Dienst, der eine anbietet, und ein Microservices-System besteht aus vielen davon.