Anzeige
Anzeige
Artikel
Artikel merken

Die Minions der Softwareentwicklung: Wie Microservices funktionieren und was sie leisten

Microservices erfreuen sich zunehmender Beliebtheit. Welche Technologien zum Einsatz kommen und worauf Softwarearchitekten und -entwickler achten sollten.

6 Min. Lesezeit
Anzeige
Anzeige

Wer schon einmal eine selbst entwickelte Software über längere Zeit betreut, gewartet und weiterentwickelt hat, kennt das Problem: Bugfixes, neue oder sich verändernde Anforderungen und stetiger technologischer Wandel sorgen dafür, dass Software kontinuierlich wächst und sich verändert. Ohne entsprechende Maßnahmen führt diese „Software-Evolution“ häufig dazu, dass Software größer und komplexer, und somit auch schwieriger zu warten wird.

Anzeige
Anzeige

Um dieser „Softwarealterung“ vorzubeugen, hat sich in den vergangenen Jahren mit dem Microservice-Muster ein neues Architekturparadigma etabliert. Dieses versucht, die Komplexität großer, wachsender Softwaresysteme besser beherrschbar zu machen und somit eine einfache Wartbarkeit sicherzustellen.

Wie funktionieren Microservices?

Eine Microservice-Architektur teilt ein Softwaresystem in eine Vielzahl einzelner, kleiner und unabhängiger Dienste auf. Diese laufen als einzelne Prozesse (somit in der Regel auch über ein Netzwerk verteilt) und kommunizieren über einfache Netzwerkschnittstellen miteinander.

Anzeige
Anzeige

Gegenüber einer herkömmlichen „monolithisch“ aufgebauten Software bietet diese Architektur einige Vorteile – beispielsweise können einzelne Services unterschiedliche Technologien nutzen. Während sich für einen Service womöglich Java als Laufzeitumgebung und MySQL als Datenbankmanagementsystem eignen, sind für einen anderen Service womöglich Node.js und eine Mongo-Datenbank bessere Kandidaten. Die Kapselung in einzelne Services ermöglicht es Entwicklungsteams somit, das jeweils beste Werkzeug für den jeweiligen Zweck zu wählen.

Anzeige
Anzeige

Die Aufteilung in mehrere Einzelkomponenten kann zudem die Auslieferung neuer Versionen vereinfachen: Statt das komplette System am Stück zu deployen (gerade bei komplexen Softwaresystemen ein womöglich riskantes Vorhaben), können einzelne Services nun unabhängig voneinander ausgeliefert werden (oder sogar durch Neu-Implementierungen ersetzt werden).

Im Unterschied zu herkömmlichen serviceorientierten Architekturen (SOAs) liegt der Fokus bei Microservice-Architekturen auf Einfachheit. Der Funktionsumfang eines einzelnen Services sollte möglichst überschaubar sein. Außerdem werden einfachere Kommunikationsprotokolle wichtiger. Statt des schwergewichtigen SOAP-Protokolls geht der Trend zu einfacheren Kommunikationsmustern wie RESTful HTTP, oder – falls Asynchronität oder eine Publish/Subscribe-Architektur gewünscht ist – auch AMQP.

Anzeige
Anzeige

Ein Beispiel für eine Microservice-Architektur im E-Commerce: Sie besteht aus vier verschiedenen Microservices, jeweils mit eigener Datenhaltung, drei externen Applikationen, und einem Gateway, welches den Zugriff auf die verschiedenen Schnittstellen der Services ermöglicht und kontrolliert.

Ein Beispiel für eine Microservice-Architektur im E-Commerce: Sie besteht aus vier verschiedenen Microservices, jeweils mit eigener Datenhaltung, drei externen Applikationen, und einem Gateway, welches den Zugriff auf die verschiedenen Schnittstellen der Services ermöglicht und kontrolliert. Die obige Abbildung zeigt eine Beispiel-Architektur für ein E-Commerce-Szenario, bestehend aus vier Microservices, die verschiedene Aufgaben übernehmen.

Üblicherweise ist in einer Microservice-Architektur jeder Service selbst für seine eigene Datenhaltung zuständig. Statt „der“ zentralen Datenbank gibt es in einer Microservice-Architektur somit viele verschiedene Datenquellen. Dies mag auf den ersten Blick nicht gerade intuitiv sein, da sich augenscheinlich die Komplexität des Systems erhöht. Würden jedoch mehrere Services eine gemeinsame Datenbank nutzen, wäre dies eine versteckte Abhängigkeit der Services untereinander. Vorzugsweise sollten jedoch alle Abhängigkeiten der Services untereinander explizit über APIs ablaufen und jeder davon für seine eigene Datenhaltung verantwortlich sein. Nur auf diese Weise ist jeder Service tatsächlich unabhängig von den anderen und kann die jeweils optimale Art der Datenspeicherung nutzen.

Anzeige
Anzeige

Um eine externe API anbieten zu können (die dann beispielsweise von Mobil-Applikationen, externen Partnern oder auch eigenen Anwendungen genutzt werden können), erfolgt der externe Zugriff auf die APIs einer Microservice-Architektur üblicherweise über ein Gateway. Dieses stellt eine einheitliche Schnittstelle für alle Services zur Verfügung und ermöglicht die Übernahme von Querschnittsaufgaben wie beispielsweise Authentifizierung für externe Nutzer, Protokollierung und Rate-Limiting.

Komplexität managen

Der Vorteil dieses Ansatzes: Jeder einzelne Service hat einen überschaubaren Funktionsumfang und keine besondere Komplexität. Dies kommt der Test- und Wartbarkeit der einzelnen Komponenten zugute. Als Softwarearchitekt oder -entwickler darf man sich jedoch nun nicht dem Trugschluss hingeben, dass sich auf diese Weise die Komplexität des Gesamtsystems reduzieren lässt. Insgesamt erhöht sich die Gesamt-Komplexität des Systems innerhalb einer Microservice-Architektur eventuell sogar, da häufig viele verschiedene Technologien zum Einsatz kommen und die Auslieferung der Software zwar pro Service einfacher, in Summe jedoch komplexer wird. Durch die Kommunikation über Netzwerke kommen zudem weitere Fehlerquellen hinzu, die bei der Gestaltung des Systems entsprechend zu berücksichtigen sind.

Diesem Komplexitätsanstieg lässt sich durch den konsequenten Einsatz von Automatisierung entgegengewirken. Geeignete Werkzeuge können den kompletten Lebenszyklus eines Microservice vom Kompilieren, Paketieren (beispielsweise in Container-Images), Testen bis hin zur Auslieferung so weit automatisieren, dass eine kontinuierliche Auslieferung von Software möglich ist. Infrastruktur sollte, soweit möglich, in Form von Quelltext abgebildet und über Konfigurationsmanagementsysteme im Soll-Zustand gehalten werden – auf diese Weise funktioniert das Ausrollen von Infrastruktur-Änderungen vollkommen automatisch.

Anzeige
Anzeige

Häufige Herausforderungen bei Microservices

Schnittstellen

Das Kernstück eines jeden Microservices ist seine externe API, über die andere Services oder externe Nutzer ihn ansprechen können. Als De-facto-Standard hat sich hier das Programmier-Paradigma RESTful HTTP herauskristallisiert.

Um die Entwicklung schlanker REST-Webservices zu unterstützen, haben sich in zahlreichen Sprachen so genannte Micro-Frameworks entwickelt. Diese erlauben es, mit nur wenigen Zeilen Code vollwertige REST-Services zu implementieren, und kommen ohne den Konfigurationsaufwand „großer“ Full-Stack-Frameworks wie Symfony (PHP) oder Spring (Java) aus. Nennenswerte Micro-Frameworks sind beispielsweise die Slim- und Silex-Frameworks (PHP), Express (Node.JS) oder Spark (Java).

Neben REST über HTTP eignen sich auch asynchrone Kommunikationsprotokolle wie das Advanced Message Queuing Procotol (kurz genannt AMQP) sehr gut, um Services untereinander zu integrieren. Die Nutzung von AMQP ermöglicht beispielsweise die Implementierung einer Publish/Subscribe-Architektur. Zentrale Komponente in einer solchen Architektur ist ein so genannter Message Broker (eine beliebte Implementierung ist beispielsweise RabbitMQ, in welcher ein Service Nachrichten bei einem Message-Broker veröffentlichen kann; andere Services lassen sich dann am Broker für eine automatische Zustellung dieser Nachrichten registrieren.

Anzeige
Anzeige

Auf diese Weise werden der veröffentlichende und empfangende Service voneinander entkoppelt – dies geht so weit, dass der Sender gar nicht wissen muss, an wen er die Nachrichten später zustellen muss.

Deployment

Die Verteilung einzelner Services auf einzelne Server ist in Microservice-Architekturen komplexer, da nun nicht nur eine Applikation verteilt werden muss, sondern viele. Außerdem bauen diese womöglich auf verschiedenen Technologien auf. Als Antwort auf diese Herausforderung haben sich Container-Lösungen wie Docker oder rkt etabliert. Damit lassen sich Anwendungen mitsamt ihren Abhängigkeiten (wie etwa Laufzeitumgebungen und Bibliotheken) in Containern verpacken, die dann einfach ausgeliefert werden können.

Die Verteilung solcher Container über mehrere Server wird zudem von Cluster-Managern wie MesosKubernetes oder Swarm unterstützt. Allen Lösungen ist gemein, dass sie einen sehr hohen Grad der Automatisierung ermöglichen. Hierzu gehört beispielsweise, dass der Cluster-Manager die tatsächliche Verteilung von Containern auf die physischen Server übernimmt und Container automatisch dort platziert, wo noch entsprechende Kapazitäten frei sind.

Anzeige
Anzeige

Viele Lösungen übernehmen auch eine automatische Skalierung, um unter Last weitere Instanzen eines Services zu starten. Über einen etwas erweiterten Continuous-Delivery-Workflow lässt sich somit – ausgelöst durch eine Quelltextänderung in der Versionskontrolle – der gesamte Prozess vom Bauen eines Container-Abbilds, dessen Integrationstest sowie der Auslieferung der neuen Version einer Software über hunderte von Servern vollständig automatisieren.

Service Discovery

Ein Microservice ist nicht sonderlich nützlich, wenn er nicht für andere Services ansprechbar ist. Hierzu müssen Service-Konsumenten jedoch wissen, wo und auf welche Weise sie den Service erreichen. Dieses Problem nennt sich „Service Discovery“, also das Auffinden von Diensten in einer komplexen Architektur. Es ist insbesondere in hochdynamischen Architekturen wichtig, in denen beispielsweise ein Cluster-Manager wie Kubernetes abhängig von der aktuellen Last und nach eigenem Ermessen neue Instanzen von Services startet und beendet.

Service Discovery in einer (micro)serviceorientierten Architektur: In der zentralen Service Registry registrieren sich alle laufenden Dienste. Sie gibt darauf die Adressen der laufenden Instanzen an andere Dienste zurück, die einen bestimmten Dienst nutzen wollen.

Anzeige
Anzeige

Service Discovery in einer (micro)serviceorientierten Architektur: In der zentralen Service Registry registrieren sich alle laufenden Dienste. Sie gibt darauf die Adressen der laufenden Instanzen an andere Dienste zurück, die einen bestimmten Dienst nutzen wollen.

Die Abbildung zeigt eine abstrahierte Form einer (micro-)serviceorientierten Architektur mit Service Discovery. Zentrale Komponente ist die Service Registry, in der sich laufende Dienste registrieren (1). Möchten andere Dienste nun einen bestimmten Dienst nutzen, so können sie bei der Registry nach gerade laufenden Instanzen dieses Dienstes anfragen (2). Die Service Registry liefert dann eine oder mehrere Adressen (beispielsweise HTTP-URLs) zurück (3), unter denen der gewünschte Dienst erreichbar ist (4).

Als Lösungen haben sich hier vor allem Zookeeper und Consul etabliert. Insbesondere Consul erfreut sich aufgrund seiner Einfachheit und guter Integrationsmöglichkeiten zunehmender Beliebtheit und arbeitet gut mit Container- und Clustermanagern zusammen. So lassen sich beispielsweise neu gestartete Docker-Container automatisch als Service in Consul registrieren, um dort für andere Services zur Verfügung zu stehen.

Ausblick

Entwickler-Teams sollten Microservices nicht unreflektiert anwenden, da dies auch Risiken mit sich bringt. Durch die Aufteilung einer monolithischen Applikation in mehrere Microservices verlagert sich die Komplexität des Gesamtsystems von der Anwendungssoftware in die Orchestrierung der einzelnen Services. Um diese beherrschbar zu machen, ist der konsequente Einsatz von Automatisierung und Continuous Delivery nötig. Die Verteilung eines Systems über ein Netzwerk führt zudem neue mögliche Fehlerquellen ein, die es bei der Programmierung zu berücksichtigen gilt.

Werden diese Fallstricke berücksichtigt, ist die Microservice-Architektur ein guter Ansatz, um der steigenden Komplexität wachsender Softwaresysteme Herr zu werden. Der Ansatz ermöglicht es, eine Software schnell an sich verändernde Anforderungen anzupassen und zeitnah neue Technologien einzusetzen. Zudem sind so einzelne Teile der Applikation einfach skalierbar.

Darüber hinaus funktionieren Microservice-Architekturen sehr gut in Organisationen, die nach dem DevOps-Prinzip arbeiten, da einzelne Produktteams nun einen einzelnen Service über dessen kompletten Lebenszyklus betreuen und somit unabhängig und agil arbeiten können.

Mehr zu diesem Thema
Fast fertig!

Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.

Du willst noch weitere Infos zum Newsletter? Jetzt mehr erfahren

Anzeige
Anzeige
Schreib den ersten Kommentar!
Bitte beachte unsere Community-Richtlinien

Wir freuen uns über kontroverse Diskussionen, die gerne auch mal hitzig geführt werden dürfen. Beleidigende, grob anstößige, rassistische und strafrechtlich relevante Äußerungen und Beiträge tolerieren wir nicht. Bitte achte darauf, dass du keine Texte veröffentlichst, für die du keine ausdrückliche Erlaubnis des Urhebers hast. Ebenfalls nicht erlaubt ist der Missbrauch der Webangebote unter t3n.de als Werbeplattform. Die Nennung von Produktnamen, Herstellern, Dienstleistern und Websites ist nur dann zulässig, wenn damit nicht vorrangig der Zweck der Werbung verfolgt wird. Wir behalten uns vor, Beiträge, die diese Regeln verletzen, zu löschen und Accounts zeitweilig oder auf Dauer zu sperren.

Trotz all dieser notwendigen Regeln: Diskutiere kontrovers, sage anderen deine Meinung, trage mit weiterführenden Informationen zum Wissensaustausch bei, aber bleibe dabei fair und respektiere die Meinung anderer. Wir wünschen Dir viel Spaß mit den Webangeboten von t3n und freuen uns auf spannende Beiträge.

Dein t3n-Team

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.

Bitte schalte deinen Adblocker für t3n.de aus!
Hallo und herzlich willkommen bei t3n!

Bitte schalte deinen Adblocker für t3n.de aus, um diesen Artikel zu lesen.

Wir sind ein unabhängiger Publisher mit einem Team von mehr als 75 fantastischen Menschen, aber ohne riesigen Konzern im Rücken. Banner und ähnliche Werbemittel sind für unsere Finanzierung sehr wichtig.

Schon jetzt und im Namen der gesamten t3n-Crew: vielen Dank für deine Unterstützung! 🙌

Deine t3n-Crew

Anleitung zur Deaktivierung
Artikel merken

Bitte melde dich an, um diesen Artikel in deiner persönlichen Merkliste auf t3n zu speichern.

Jetzt registrieren und merken

Du hast schon einen t3n-Account? Hier anmelden

oder
Auf Mastodon teilen

Gib die URL deiner Mastodon-Instanz ein, um den Artikel zu teilen.

Anzeige
Anzeige