Microservices-Architektur ist ein Software-Design-Ansatz, bei dem eine Anwendung als Sammlung relativ kleiner, unabhängig bereitstellbarer Dienste erstellt wird. Jeder Dienst besitzt typischerweise eine spezifische Geschäftsfunktionalität und kommuniziert über gut definierte Schnittstellen wie APIs oder Nachrichtensysteme mit anderen Diensten.
Microservices können Teams dabei helfen, Teile einer großen Anwendung unabhängig voneinander zu entwickeln und bereitzustellen. Sie bringen jedoch auch betriebliche Komplexität mit sich. Netzwerk, Observability, Datenkonsistenz, Sicherheit, Tests und Dienstkoordination erfordern alle ein sorgfältiges Design.
Was ist eine Microservices-Architektur?
Bei einer Microservices-Architektur wird eine Anwendung in Dienste unterteilt, die nach Geschäftsfunktionen organisiert sind. Beispielsweise könnte ein Online-Shop separate Dienste für Produkte, Bestellungen, Zahlungen, Inventar und Kundenkonten haben.
Jeder Dienst kann potenziell unabhängig entwickelt, getestet, bereitgestellt und skaliert werden. Die Dienste kommunizieren über APIs, Ereignisse, Warteschlangen oder andere definierte Mechanismen.
Wie Microservices funktionieren
- Ein Client sendet eine Anfrage an einen Anwendungseinstiegspunkt.
- Die Anfrage wird an den entsprechenden Dienst weitergeleitet.
- Der Dienst führt seine Geschäftslogik aus und kommuniziert möglicherweise mit anderen Diensten.
- Dienste tauschen Daten über APIs oder Messaging aus.
- Das angeforderte Ergebnis wird an den Client zurückgegeben.
- Jeder Dienst kann als Teil seines eigenen Lebenszyklus überwacht und bereitgestellt werden.
Microservices vs. monolithische Architektur
| Bereich | Microservices | Monolith |
|---|---|---|
| Anwendungsstruktur | Mehrere unabhängig bereitstellbare Dienste | Primär eine bereitstellbare Anwendung |
| Bereitstellung | Dienste können unabhängig voneinander bereitgestellt werden | Änderungen betreffen in der Regel die Bereitstellung der Hauptanwendung |
| Skalierung | Einzelne Dienste können je nach Bedarf skaliert werden | Skaliert die Anwendung oft als größere Einheit |
| Betriebliche Komplexität | Höher aufgrund verteilter Komponenten | Oft einfacher für kleinere Systeme |
| Fehlermodi | Netzwerk- und Dienstausfälle müssen gehandhabt werden | Weniger Ausfallszenarien verteilter Dienste |
Keine der Architekturen ist automatisch für jede Anwendung besser. Ein gut gestalteter Monolith kann einfacher zu betreiben sein, während Microservices nützlich werden können, wenn unabhängige Bereitstellung, Skalierung oder Anforderungen an die Teamverantwortung die zusätzliche Komplexität rechtfertigen.
Hauptmerkmale von Microservices
Unabhängige Bereitstellung
Dienste sind so konzipiert, dass Teams nach Möglichkeit Änderungen veröffentlichen können, ohne die gesamte Anwendung neu zu erstellen und bereitzustellen.
Geschäftliche Funktionsgrenzen
Ein Dienst sollte eine klare Verantwortung haben. Starke Grenzen können unnötige Kopplungen zwischen Teams und Komponenten reduzieren.
API-basierte Kommunikation
Dienste kommunizieren meist über HTTP-APIs, gRPC, asynchrone Nachrichten oder Event-Streams. Die Schnittstelle sollte explizit und bei Bedarf versioniert sein.
Unabhängige Skalierung
Wenn ein Dienst wesentlich mehr Datenverkehr als andere erhält, kann er möglicherweise unabhängig skaliert werden. Dies kann die Ressourceneffizienz verbessern, wenn sich die Workloads stark unterscheiden.
Dezentraler Datenbesitz
Microservices übertragen Diensten häufig die Verantwortung für ihre eigenen Daten. Dies kann die Autonomie verbessern, macht aber auch übergreifende Transaktionen und Berichte komplexer.
Vorteile der Microservices-Architektur
- Unabhängige Releases: Teams können einzelne Dienste bereitstellen, ohne immer die gesamte Anwendung freizugeben.
- Gezielte Skalierung: Dienste mit hoher Nachfrage können separat skaliert werden.
- Team-Autonomie: Teams können spezifische Geschäftsfunktionen und deren betrieblichen Lebenszyklus verantworten.
- Technologische Flexibilität: Verschiedene Dienste können Technologien nutzen, die ihren Anforderungen entsprechen, innerhalb sinnvoller organisatorischer Grenzen.
- Möglichkeiten zur Fehlerisolierung: Richtig gestaltete Dienste können die Auswirkungen einiger Ausfälle begrenzen.
- Schrittweise Modernisierung: Organisationen können Teile eines größeren Systems im Laufe der Zeit ersetzen oder herauslösen.
Herausforderungen von Microservices
Verteilte Systeme sind schwieriger zu verstehen als eine einzelne Anwendung. Eine Anfrage kann mehrere Dienste durchlaufen, und jeder Netzwerkaufruf verursacht Latenz und potenzielle Ausfälle.
Auch die Datenkonsistenz kann schwieriger werden. Ein Geschäftsvorgang, der früher eine einzige Datenbanktransaktion nutzte, erstreckt sich nun möglicherweise über mehrere Dienste mit separaten Datenspeichern.
Auch die operativen Anforderungen steigen. Teams benötigen zentralisiertes Logging, Metriken, Tracing, Bereitstellungsautomatisierung, Service Discovery, Sicherheitskontrollen und zuverlässige Prozesse zur Vorfallreaktion.
Microservices und Datenbanken
Ein gängiges Prinzip ist, dass jeder Dienst die für seine Geschäftsfähigkeit erforderlichen Daten besitzen sollte, anstatt anderen Diensten zu erlauben, seine Datenbank direkt zu modifizieren. Dies schafft klarere Verantwortungsbereiche.
Getrennte Datenverantwortung bedeutet jedoch, dass Anwendungen APIs, Ereignisse oder asynchrone Workflows benötigen können, um Informationen auszutauschen. Entwickler müssen auch eventuelle Konsistenz (Eventual Consistency) einplanen, wenn sofortige dienstübergreifende Transaktionen nicht praktikabel sind.
Kommunikationsmuster von Microservices
Synchrone APIs
Bei der synchronen Kommunikation sendet ein Dienst eine Anfrage und wartet auf eine Antwort. HTTP und gRPC sind gängige Optionen. Dieser Ansatz ist unkompliziert, kann jedoch Laufzeitabhängigkeiten zwischen Diensten erzeugen.
Asynchrones Messaging
Bei der asynchronen Kommunikation veröffentlicht ein Dienst eine Nachricht oder ein Ereignis, und ein anderer Dienst verarbeitet es später. Warteschlangen und Event-Streaming-Plattformen können die direkte Kopplung verringern, bringen jedoch zusätzliche betriebliche Überlegungen mit sich.
Ereignisgesteuerte Architektur
Dienste können Ereignisse veröffentlichen, wenn wichtige geschäftliche Änderungen auftreten. Andere Dienste abonnieren relevante Ereignisse und aktualisieren ihren eigenen Zustand. Ereignisgesteuerte Systeme erfordern eine sorgfältige Handhabung von doppelten Nachrichten, Reihenfolge, Wiederholungen und Ausfällen.
Sicherheit von Microservices
Sicherheit muss an den Dienstgrenzen angewendet werden, anstatt sich nur auf einen externen Netzwerkperimeter zu verlassen.
- Verwenden Sie eine starke Dienst- und Benutzerauthentifizierung.
- Wenden Sie Autorisierung an den entsprechenden Dienstgrenzen an.
- Verschlüsseln Sie sensiblen Datenverkehr bei der Übertragung.
- Schützen Sie Dienst-Credentials und Secrets.
- Validieren Sie API-Eingaben.
- Begrenzen Sie die Dienstberechtigungen nach dem Prinzip der geringsten Privilegien.
- Überwachen Sie Authentifizierungsfehler und ungewöhnlichen Dienstverkehr.
Microservices, Container und Kubernetes
Container werden häufig zum Verpacken von Microservices verwendet, da sie eine konsistente Bereitstellungseinheit darstellen. Kubernetes und andere Container-Orchestrierungsplattformen können Planung, Skalierung, Service Discovery und Lebenszyklusmanagement automatisieren.
Microservices erfordern jedoch kein Kubernetes. Kleinere Umgebungen können einfachere Bereitstellungsplattformen nutzen, und die Einführung eines komplexen Orchestrierungssystems, bevor es benötigt wird, kann den operativen Aufwand erhöhen.
Observability in Microservices
Observability ist besonders wichtig, da eine Benutzeranfrage mehrere Dienste durchlaufen kann. Teams kombinieren typischerweise Logs, Metriken und verteilte Traces, um das Systemverhalten zu verstehen.
Korrelations-IDs und konsistentes strukturiertes Logging können Ingenieuren helfen, Anfragen über Dienstgrenzen hinweg zu verfolgen. Gesundheitsprüfungen, Service-Level-Indikatoren und Warnungen können ebenfalls die operative Reaktionsfähigkeit verbessern.
Wie man eine Microservices-Architektur entwirft
- Identifizieren Sie die Geschäftsfähigkeiten, die die Anwendung bereitstellen muss.
- Definieren Sie Dienstgrenzen um sinnvolle Verantwortlichkeiten herum.
- Entwerfen Sie explizite APIs und Ereignisse zwischen Diensten.
- Etablieren Sie eine klare Verantwortlichkeit für jeden Dienst und dessen Daten.
- Automatisieren Sie Tests und Bereitstellungen.
- Integrieren Sie Observability in jeden Dienst.
- Wenden Sie Identitäts-, Autorisierungs- und Least-Privilege-Kontrollen an.
- Beginnen Sie mit einer begrenzten Anzahl von Diensten und entwickeln Sie die Architektur basierend auf echten Anforderungen weiter.
Expertentipps
- Teilen Sie eine Anwendung nicht einfach deshalb in Dienste auf, weil Mikroservices beliebt sind.
- Beginnen Sie mit klaren Geschäftsgrenzen anstelle von technischen Schichten.
- Halten Sie Service-APIs klein und zweckorientiert.
- Entwerfen Sie Systeme im Hinblick auf Netzwerkausfälle und Timeouts.
- Automatisieren Sie Builds, Tests, Sicherheitsüberprüfungen und die Bereitstellung.
- Verwenden Sie verteiltes Tracing, bevor das System schwer zu diagnostizieren wird.
- Übertragen Sie Teams die klare Verantwortung für Dienste und den operativen Betrieb.
Häufige Microservices-Fehler
- Erstellung zu vieler winziger Dienste ohne klaren geschäftlichen Grund.
- Gemeinsame Nutzung einer Datenbank für alle Dienste, während das System als Mikroservices bezeichnet wird.
- Ignorieren von Latenzzeiten im Netzwerk und teilweisen Ausfällen.
- Platzieren von Geschäftslogik in einem API-Gateway.
- Verwendung synchroner Aufrufe für jede Interaktion.
- Bereitstellung von Mikroservices ohne angemessene Observability.
- Einführung von Kubernetes, bevor das Team dessen Funktionen benötigt.
Häufig gestellte Fragen
Was ist eine Microservices-Architektur in einfachen Worten?
Es ist ein Ansatz, der eine Anwendung in unabhängig bereitstellbare Dienste aufteilt, wobei jeder Dienst für eine bestimmte geschäftliche Funktion verantwortlich ist.
Was ist der Unterschied zwischen Microservices und einem Monolithen?
A monolith is generally deployed as a larger application unit, while microservices divide the system into services that can be developed and deployed more independently.
Benötigen Microservices Container?
No. Containers are common for microservices, but the architecture can be implemented using other deployment technologies.
Erfordern Microservices Kubernetes?
No. Kubernetes can help operate large containerized systems, but smaller microservices environments can use simpler platforms.
Benötigt jeder Microservice eine eigene Datenbank?
Not necessarily, but clear data ownership is important. Many microservices designs give each service control over its own data to reduce coupling.
Sind Microservices schneller als Monolithen?
Not automatically. Network communication can add latency. Performance depends on architecture, workload, implementation, infrastructure, and scaling strategy.
Sind Microservices sicherer?
Microservices can provide useful security boundaries, but they also create more service interfaces and credentials to protect. Security depends on implementation and operational controls.
Wann sollte ein Unternehmen Microservices nutzen?
Microservices can be considered when independent deployment, scaling, team ownership, or system boundaries justify the additional complexity of distributed architecture.
Fazit
Microservices-Architektur provides a way to build complex applications from independently deployable services organized around business capabilities. It can support independent releases, targeted scaling, and clearer ownership.
At the same time, microservices introduce distributed-system challenges involving networking, data consistency, observability, security, testing, and operations. Teams should therefore adopt the architecture because it solves a real organizational or technical problem, not simply because it is a modern pattern.
Want to explore the next stage of modern application architecture? Continue with our guide to serverless architecture and learn how applications can run without teams managing traditional servers directly.
