Startseite
Themen
microservices
Microservices oder Microservice-Architektur ist ein cloudnativer architektonischer Ansatz, bei dem eine einzelne Anwendung aus vielen lose gekoppelten und unabhängig voneinander einsetzbaren kleineren Komponenten oder Diensten besteht.
Microservices:
- Verfügen über einen eigenen Technologie-Stack, einschließlich Datenbank und Datenverwaltungsmodell.
- Kommunizieren über eine Kombination aus Representational State Transfer (REST) APIs, Event Streaming und Message Brokern miteinander.
- Sind nach Geschäftsfunktion organisiert, wobei die Trennlinie zwischen den Diensten oft als begrenzter Kontext bezeichnet wird.
Während sich ein Großteil der Diskussion über Microservices um architektonische Definitionen und Merkmale drehte, lässt sich ihr Wert besser durch recht einfache geschäftliche und organisatorische Vorteile verstehen:
- Der Code kann einfacher aktualisiert werden – neue Funktionen oder Anwendungsmöglichkeiten können hinzugefügt werden, ohne die gesamte Anwendung zu verändern.
- Teams können verschiedene Stacks und verschiedene Programmiersprachen für verschiedene Komponenten verwenden.
- Komponenten können unabhängig voneinander skaliert werden, wodurch der Ausschuss und die Kosten reduziert werden, die mit der Skalierung ganzer Anwendungen verbunden sind, weil eine einzelne Funktion möglicherweise zu stark belastet wird.
Was Microservices nicht sind
Microservices können auch im Gegensatz zu zwei vorhergehenden Anwendungsarchitekturen verstanden werden: der monolithischen Architektur und der serviceorientierten Architektur (SOA).
Der Unterschied zwischen Microservices und einer monolithischen Architektur besteht darin, dass Erstere eine einzelne Anwendung aus vielen kleineren, lose gekoppelten Diensten zusammensetzen, im Gegensatz zum monolithischen Ansatz einer großen, eng gekoppelten Anwendung.
Die Unterschiede zwischen Microservices und SOA sind nicht ganz so eindeutig. Zwar lassen sich technische Gegensätze zwischen Microservices und SOA ausmachen, insbesondere im Hinblick auf die Rolle des Enterprise Service Bus, aber es ist einfacher, den Unterschied als einen der Reichweite zu betrachten. SOA war ein unternehmensweites Bestreben, die Art und Weise zu standardisieren, wie alle Webdienste in einem Unternehmen miteinander kommunizieren und sich integrieren, während die Microservices-Architektur anwendungsspezifisch ist.
Lesen Sie, wie Unternehmen mit Desktop-as-a-Service (DaaS) das gleiche Maß an Leistung und Sicherheit erreichen können wie bei der lokalen Bereitstellung der Anwendungen.
Microservices sind bei Führungskräften und Projektleitern wahrscheinlich mindestens genauso beliebt wie bei Entwicklern. Dies ist eine der eher ungewöhnlichen Eigenschaften von Microservices, da der Begeisterung für Softwarearchitekturen in der Regel Softwareentwicklungsteams vorbehalten sind. Der Grund dafür ist, dass Microservices dem Bedürfnis vieler Führungskräfte entsprechen, ihre Teams und Entwicklungsprozesse zu strukturieren und zu verwalten.
Anders ausgedrückt sind Microservices ein Architekturmodell, das ein gewünschtes Betriebsmodell besser unterstützt. In einer IBM-Umfrage aus dem Jahr 2021 unter mehr als 1.200 Entwicklern und IT-Führungskräften stimmten 87 % der Microservice-Nutzer zu, dass die Einführung von Microservices die Kosten und den Aufwand wert ist.
Hier sind nur einige der Vorteile von Microservices für Unternehmen:
Unabhängige bereitstellbar
Das vielleicht wichtigste Merkmal von Microservices ist, dass es aufgrund der Tatsache, dass die Services kleiner und unabhängig voneinander einsetzbar sind, nicht mehr eines geschäftlichen Riesenaufwandes bedarf, um eine Codezeile zu ändern oder eine neue Funktion in der Anwendung hinzuzufügen.
Microservices versprechen Unternehmen ein wirksames Mittel gegen die Frustrationen, die mit kleinen Änderungen verbunden sind, die viel Zeit in Anspruch nehmen. Man muss kein promovierter Informatiker sein, um den Wert eines Ansatzes zu erkennen oder zu verstehen, der Geschwindigkeit und Agilität besser fördert.
Aber Schnelligkeit ist nicht der einzige Vorteil dieser Art der Service-Gestaltung. Ein gängiges Organisationsmodell, das sich immer mehr durchsetzt, besteht darin, funktionsübergreifende Teams um ein Geschäftsproblem, einen Service oder ein Produkt herum zusammenzubringen. Das Microservices-Modell passt perfekt zu diesem Trend, da es Unternehmen ermöglicht, kleine, funktionsübergreifende Teams um einen Services oder eine Sammlung von Services herum zu bilden und diese agil arbeiten zu lassen.
Die lose Kopplung von Microservices sorgt außerdem für eine gewisse Fehlerisolierung und eine bessere Ausfallsicherheit in Anwendungen. Und die geringe Größe der Dienste, kombiniert mit ihren klaren Grenzen und Kommunikationsmustern, erleichtert es neuen Teammitgliedern, die Codebasis zu verstehen und schnell dazu beizutragen – ein klarer Vorteil in Bezug auf Geschwindigkeit und Arbeitsmoral.
Das richtige Tool für den Job
In traditionellen n-Tier-Architekturmustern teilt sich eine Anwendung in der Regel einen gemeinsamen Stack, wobei eine große, relationale Datenbank die gesamte Anwendung unterstützt. Dieser Ansatz hat mehrere offensichtliche Nachteile – der größte davon ist, dass alle Komponenten einer Anwendung einen gemeinsamen Stack, ein gemeinsames Datenmodell und eine gemeinsame Datenbank verwenden müssen, selbst wenn es für bestimmte Elemente ein klar besseres Tool für die Aufgabe gibt. Das führt zu schlechter Architektur und ist frustrierend für Entwickler, die ständig wissen, dass es eine bessere, effizientere Möglichkeit gibt, diese Komponenten zu bauen.
Im Gegensatz dazu werden in einem Microservice-Modell die Komponenten unabhängig voneinander bereitgestellt und kommunizieren über eine Kombination aus REST, Event Streaming und Message Brokern. So kann der Stack jedes einzelnen Dienstes für diesen Dienst optimiert werden. Die Technologie ändert sich ständig, und eine Anwendung, die aus mehreren kleineren Services besteht, lässt sich viel einfacher und kostengünstiger weiterentwickeln, wenn eine wünschenswertere Technologie verfügbar wird.
Präzise skalieren
Mit Microservices können einzelne Services individuell bereitgestellt werden – aber sie können auch individuell skaliert werden. Der daraus resultierende Vorteil liegt auf der Hand: Richtig eingesetzt, benötigen Microservices weniger Infrastruktur als monolithische Anwendungen, da sie eine präzise Skalierung nur der Komponenten ermöglichen, die sie benötigen, anstatt der gesamten Anwendung im Fall von monolithischen Anwendungen.
Auch Mikrodienste haben ihre Herausforderungen:
Die erheblichen Vorteile von Microservices gehen mit erheblichen Herausforderungen einher. Die Umstellung von Monolithen auf Microservices bedeutet eine viel höhere Komplexität des Managements – viel mehr Dienste, die von viel mehr Teams erstellt und an viel mehr Orten bereitgestellt werden. Probleme in einem Dienst können Probleme in anderen Diensten verursachen oder durch diese verursacht werden. Die Protokolldaten (die zur Überwachung und Problemlösung verwendet werden) sind umfangreicher und können je nach Service inkonsistent sein. Neue Versionen können zu Problemen mit der Abwärtskompatibilität führen. Anwendungen erfordern mehr Netzwerkverbindungen, was wiederum mehr Möglichkeiten für Latenz- und Verbindungsprobleme bedeutet. Ein DevOps-Ansatz kann viele dieser Probleme lösen, aber dessen Einführung bringt auch eigene Herausforderungen mit sich.
Dennoch halten diese Herausforderungen Nichtanwender nicht davon ab, Microservices zu übernehmen – oder Anwender davon, ihr Engagement für Microservices zu vertiefen. Die oben genannten IBM-Umfragedaten zeigen, dass 56 % der derzeitigen Nichtanwender wahrscheinlich oder sehr wahrscheinlich innerhalb der nächsten zwei Jahre Microservices einführen werden und 78 % der derzeitigen Microservice-Nutzer wahrscheinlich mehr Zeit, Geld und Aufwand in Microservices investieren werden.
Die Microservices-Architektur wird oft als für DevOps und kontinuierliche Integration oder kontinuierliche Bereitstellung optimiert beschrieben, und im Zusammenhang mit kleinen Diensten, die häufig bereitgestellt werden können, ist es leicht zu verstehen, warum.
Man kann die Beziehung zwischen Microservices und DevOps aber auch anders betrachten: Microservice-Architekturen benötigen DevOps, um erfolgreich zu sein. Monolithische Anwendungen haben zwar eine Reihe von Nachteilen, die bereits in diesem Artikel besprochen wurden, aber sie haben den Vorteil, dass sie kein komplexes verteiltes System mit mehreren beweglichen Teilen und unabhängigen Technologie-Stacks sind. Angesichts der enormen Zunahme an Komplexität, beweglichen Teilen und Abhängigkeiten, die mit Microservices einhergehen, wäre es jedoch unklug, sich Mikrodiensten ohne erhebliche Investitionen in Bereitstellung, Überwachung und Lebenszyklusautomatisierung zu nähern.
Rosalind Radcliffe bietet im Video einen tieferen Einblick in DevOps:
Obwohl in einer Microservices-Architektur fast jedes moderne Tool oder jede Sprache verwendet werden kann, gibt es eine Handvoll Kern-Tools, die für Microservices unverzichtbar und geradezu definierend geworden sind:
Eines der wichtigsten Merkmale eines Microservices ist, dass er im Allgemeinen ziemlich klein ist. Es gibt keine willkürliche Menge an Code, die bestimmt, ob etwas ein Microservice ist oder nicht, aber „Micro“ steckt schon im Namen.
Als Docker 2013 das moderne Container-Zeitalter einläutete, führte es auch das Rechenmodell ein, das am engsten mit Microservices in Verbindung gebracht werden würde. Da einzelne Container nicht den Mehraufwand eines eigenen Betriebssystems haben, sind sie kleiner und leichter als herkömmliche Virtual Machines und können schneller hoch- und heruntergefahren werden, sodass sie perfekt zu den kleineren und leichteren Services passen, die in Microservice-Architekturen zu finden sind.
Mit der zunehmenden Verbreitung von Services und Containern wurde die schnelle Koordination und Verwaltung großer Containergruppen zu einer der entscheidenden Herausforderungen. Kubernetes, eine Open-Source-Plattform für die Orchestrierung von Containern, hat sich zu einer der beliebtesten Orchestrierungslösungen entwickelt, weil sie diese Aufgabe so gut erfüllt.
Microservices kommunizieren oft über API, insbesondere bei der erstmaligen Festlegung ihres Status. Zwar können Kunden und Dienste direkt miteinander kommunizieren, doch sind API Gateways oft eine nützliche Vermittlungsebene, insbesondere wenn die Anzahl der Dienste in einer Anwendung im Laufe der Zeit zunimmt. Ein API Gateway fungiert als Reverse-Proxy für Kunden, indem es Anfragen weiterleitet, Anfragen auf mehrere Dienste verteilt und zusätzliche Sicherheit und Authentifizierung bietet.
Es gibt mehrere Technologien, die zur Implementierung von API Gateways verwendet werden können, einschließlich API Management-Plattformen. Wenn die Microservices-Architektur jedoch mithilfe von Containern und Kubernetes implementiert wird, wird das Gateway in der Regel mit Ingress oder neuerdings mit Istio implementiert.
Obwohl es sich bewährt hat, zustandslose Services zu entwerfen, gibt es dennoch einen Zustand und die Services müssen sich dessen bewusst sein. Und während ein API-Aufruf oft eine effektive Möglichkeit ist, den Status eines bestimmten Services zunächst zu ermitteln, ist er nicht besonders effektiv, um auf dem neuesten Stand zu bleiben. Eine permanente Abfrage, ob die Services bereits verfügbar sind, ist einfach nicht praktikabel.
Stattdessen ist es notwendig, API-Aufrufe zur Statusfeststellung mit Nachrichtenübermittlung oder EVENT Streaming zu koppeln, damit Dienste Statusänderungen übertragen können und andere interessierte Akteure diese Änderungen verfolgen und sich entsprechend anpassen können. Diese Aufgabe ist wahrscheinlich am besten für einen universellen Message Broker geeignet, aber es gibt Fälle, in denen eine Plattform für Event Streaming, wie z. B. Apache Kafka, gut geeignet sein könnte. Und durch die Kombination von Microservices mit einer ereignisgesteuerten Architektur können Entwickler verteilte, hoch skalierbare, fehlertolerante und erweiterbare Systeme erstellen, die sehr große Mengen an Ereignissen oder Informationen in Echtzeit verarbeiten können.
Serverlose Architekturen führen einige der Kernmuster von Cloud- und Microservices zu ihrem logischen Abschluss. Im Fall von serverlos ist die Ausführungseinheit nicht nur ein kleiner Service, sondern eine Funktion, die oft nur aus ein paar Zeilen Code besteht. Die Grenze zwischen einer serverlosen Funktion und einem Microservice ist fließend, aber im Allgemeinen werden Funktionen als noch kleiner als ein Microservice angesehen.
Serverlose Architekturen und Function-as-a-Service-Plattformen haben mit Microservices gemeinsam, dass sie beide daran interessiert sind, kleinere Bereitstellungseinheiten zu erstellen und genau nach Bedarf zu skalieren.
Microservices sind nicht unbedingt ausschließlich für Cloud Computing relevant, aber es gibt einige wichtige Gründe, warum sie so häufig zusammen auftreten – Gründe, die über die Tatsache hinausgehen, dass Microservices ein beliebter Architekturstil für neue Anwendungen sind und die Cloud ein beliebter Hosting-Standort für neue Anwendungen ist.
Zu den Hauptvorteilen der Microservices-Architektur gehören die Nutzungs- und Kostenvorteile, die mit der individuellen Bereitstellung und Skalierung von Komponenten verbunden sind. Diese Vorteile wären zwar auch bei einer lokalen Infrastruktur in gewissem Umfang gegeben, aber echte Kostenoptimierungen lassen sich durch die Kombination kleiner, unabhängig voneinander skalierbarer Komponenten mit einer bedarfsgerechten, nutzungsbasierten Infrastruktur erzielen.
Zweitens, und das ist vielleicht noch wichtiger, besteht ein weiterer Hauptvorteil von Microservices darin, dass jede einzelne Komponente den Stack übernehmen kann, der für ihre spezifische Aufgabe am besten geeignet ist. Die Verbreitung von Stacks kann zu einer erheblichen Komplexität und zu einem hohen Aufwand führen, wenn Sie sie selbst verwalten. Wenn Sie jedoch den unterstützenden Stack als Cloud-Service nutzen, können Sie die Verwaltungsherausforderungen drastisch minimieren. Anders ausgedrückt: Es ist zwar nicht unmöglich, eine eigene Microservice-Infrastruktur aufzubauen, aber nicht ratsam, insbesondere wenn man gerade erst anfängt.
Innerhalb von Microservices-Architekturen gibt es viele häufige und nützliche Design-, Kommunikations- und Integrationsmuster, die dabei helfen, einige der häufigsten Herausforderungen und Chancen zu bewältigen, darunter die folgenden:
Backend for Frontend (BFF)-Muster
Dieses Muster fügt eine Ebene zwischen der Benutzererfahrung und den Ressourcen ein, auf die die Erfahrung zugreift. Zum Beispiel hat eine App, die auf einem Desktop verwendet wird, andere Bildschirmgrößen, Anzeigen und Leistungsgrenzen als ein Mobilgerät. Mit dem BFF-Muster können Entwickler einen Backend-Typ pro Benutzeroberfläche erstellen und unterstützen, wobei die besten Optionen für dieses Interface verwendet werden, anstatt zu versuchen, ein generisches Backend zu unterstützen, das mit jedem Interface funktioniert, sich aber negativ auf die Frontend-Leistung auswirken kann.
Entitäts- und Aggregatmuster
Eine Entität ist ein Objekt, das sich durch seine Identität auszeichnet. Auf einer E-Commerce-Website kann ein Produktobjekt beispielsweise nach Produktname, Typ und Preis unterschieden werden. Ein Aggregat ist eine Sammlung verwandter Entitäten, die als eine Einheit behandelt werden sollten. Für die E-Commerce-Website wäre eine Bestellung also eine Sammlung (Aggregat) von Produkten (Entitäten), die von einem Käufer bestellt wurden. Diese Muster werden verwendet, um Daten auf sinnvolle Weise zu klassifizieren.
Muster der Service-Erkennung
Diese helfen Anwendungen und Services, einander zu finden. In einer Microservice-Architektur ändern sich Service-Instanzen aufgrund von Skalierung, Upgrades, Service-Ausfällen und sogar Service-Beendigungen dynamisch. Diese Muster bieten Entdeckungsmechanismen, um mit dieser Kurzlebigkeit umzugehen. Die Lastverteilung kann Service-Discovery-Muster verwenden, indem sie Zustandsprüfungen und Service-Ausfälle als Auslöser für die Neuverteilung des Datenverkehrs nutzt.
Adapter-Microservices-Muster
Stellen Sie sich Adaptermuster so vor, wie Sie sich Steckdosenadapter vorstellen, die Sie verwenden, wenn Sie in ein anderes Land reisen. Der Zweck von Adaptermustern besteht darin, Beziehungen zwischen Klassen oder Objekten zu übersetzen, die ansonsten nicht kompatibel sind. Eine Anwendung, die auf Drittanbieter-APIs basiert, muss möglicherweise ein Adaptermuster verwenden, um sicherzustellen, dass die Anwendung und die APIs miteinander kommunizieren können.
Strangler-Anwendungsmuster
Diese Muster helfen bei der Umgestaltung einer monolithischen Anwendung in Microservices. Der farbenfrohe Name (dt. Würgepflanze) bezieht sich darauf, wie eine Rebe (Microservices) langsam und mit der Zeit einen Baum (eine monolithische Anwendung) überwuchert und erstickt.
Es gibt zwar viele Muster, um Microservices sinnvoll zu nutzen, aber es gibt ebenso viele Muster, die jedes Entwicklungsteam schnell in Schwierigkeiten bringen können. Einige davon – umformuliert als „Don'ts“ für Microservices – sind die Folgenden:
Erstellen Sie keine Microservices
Genauer gesagt: Beginnen Sie nicht mit Microservices. Microservices sind eine Möglichkeit, Komplexität zu bewältigen, wenn Anwendungen zu groß und unhandlich geworden sind, um einfach aktualisiert und gewartet zu werden. Erst wenn Sie spüren, wie das Ausmaß und die Komplexität des Monolithen allmählich zunehmen, sollten Sie darüber nachdenken, wie Sie diese Anwendung in kleinere Services umwandeln können. Solange dies nicht der Fall ist, muss ihre monolithische Anwendung nicht refaktoriert werden.
Verzichten Sie bei Microservices nicht auf DevOps oder Cloud-Services
Der Aufbau von Microservices bedeutet den Aufbau verteilter Systeme, und verteilte Systeme sind schwierig – und sie sind besonders schwierig, wenn Sie Entscheidungen treffen, die es noch schwieriger machen. Der Versuch, Microservices ohne eine ordnungsgemäße Bereitstellung und Überwachungsautomatisierung oder verwaltete Cloud-Services zur Unterstützung Ihrer inzwischen weitläufigen, heterogenen Infrastruktur zu betreiben, ist ein Garant für viele vermeidbare Probleme. Ersparen Sie sich die Mühe, damit Sie sich um den Zustand kümmern können.
Erstellen Sie nicht zu viele Microservices, indem Sie sie zu klein machen
Wenn Sie bei Microservices zu weit mit dem „Micro“ gehen, könnten Sie leicht einen Mehraufwand und eine Komplexität erhalten, die die Gesamtvorteile einer Microservice-Architektur überschatten. Es ist besser, sich auf größere Dienste zu konzentrieren und diese erst dann aufzuteilen, wenn sie Eigenschaften entwickeln, für die Microservices eine Lösung bieten – nämlich wenn es schwierig und zeitaufwendig wird, Änderungen bereitzustellen, ein gemeinsames Datenmodell zu komplex wird oder wenn verschiedene Teile des Dienstes unterschiedliche Anforderungen an die Last/Skalierung haben.
Verwandeln Sie Microservices nicht in SOA
Microservices und SOA werden oft miteinander verwechselt, da beide auf der grundlegendsten Ebene daran interessiert sind, wiederverwendbare Einzelkomponenten zu erstellen, die von anderen Anwendungen genutzt werden können. Der Unterschied zwischen Microservices und SOA besteht darin, dass Microservice-Projekte in der Regel die Umgestaltung einer Anwendung beinhalten, damit sie einfacher zu verwalten ist, während es bei SOA darum geht, die Art und Weise zu ändern, wie IT-Services unternehmensweit funktionieren. Ein Microservice-Projekt, das in ein SOA-Projekt umgewandelt wird, wird wahrscheinlich unter seinem eigenen Gewicht zusammenbrechen.
Versuchen Sie nicht, Netflix zu sein
Netflix zählte zu den Pionieren der Microservice-Architektur, als das Unternehmen eine Anwendung entwickelte und verwaltete, die ein Drittel des gesamten Internetverkehrs ausmachte – eine Art „perfekter Sturm“, der es erforderlich machte, dass das Unternehmen viele benutzerdefinierte Codes und Dienste entwickelte, die für eine durchschnittliche Anwendung nicht notwendig sind. Es ist viel besser, mit einem Tempo zu beginnen, das Sie bewältigen können, Komplexität zu vermeiden und so viele Standardtools wie möglich zu verwenden.
Wenn Sie mehr über die Verwendung von Microservices erfahren möchten oder Ihre Kenntnisse über Microservices erweitern möchten, probieren Sie eines dieser Tutorials aus:
- Einführung in Microservices
- Kurzübung: Erstellen Sie hoch skalierbare Microservices für Webanwendungen mit Node.js
- Erste Schritte mit Java Microservices mit Spring Boot und Cloudant
- Erstellen, Ausführen und Bereitstellen von Spring Microservices in fünf Minuten
- Microservices, SOA und APIs: Freunde oder Feinde?
Stellen Sie hochverfügbare, vollständig verwaltete Kubernetes-Cluster für Ihre containerisierten Anwendungen mit nur einem Klick bereit.
Implementieren und verwalten Sie containerisierte Anwendungen konsistent in On-Premises-, Edge-Computing- und Public-Cloud-Umgebungen von jedem gewünschten Anbieter.
Führen Sie Container-Images, Stapeljobs oder Quellcode als serverlose Workloads aus – ohne Größenanpassung, Bereitstellung, Vernetzung oder Skalierung.
DevOps beschleunigt die Bereitstellung höherwertiger Software, weil es die Arbeit von Softwareentwicklungs- und IT-Betriebsteams kombiniert und automatisiert.
Container sind ausführbare Softwareeinheiten, die Anwendungscode zusammen mit seinen Bibliotheksabhängigkeiten als Paket enthalten und überall ausgeführt werden können, sei es auf dem Desktop, auf herkömmlicher IT oder in der Cloud.
Kubernetes ist eine Open-Source-Plattform zur Containerorchestrierung, die die Bereitstellung, Verwaltung und Skalierung von containerisierten Anwendungen automatisiert.
Erkunden Sie die Auswirkungen früherer Software-Designmuster auf die Erstellung von Microservices.
Lernen Sie die Tücken und Herausforderungen kennen, die mit der Nutzung von Microservices verbunden sind.