Anmelden / Registrieren Konto

Microservices

Das Service Mesh – Funktionsweise und Vorteile

Mit einem Service Mesh lässt sich kontrollieren, wie unterschiedliche Teile einer Anwendung Daten miteinander teilen. Im Gegensatz zu anderen Systemen der Kommunikationsverwaltung ist ein Service Mesh eine dedizierte, direkt in die App integrierte Infrastrukturschicht. Mit dieser lässt sich dokumentieren, wie gut (oder schlecht) die verschiedenen Komponenten einer App interagieren. Auf diese Weise wird die Kommunikation optimiert, und Ausfälle können minimiert werden, auch wenn die App immer größer wird.

Jeder Teil einer Anwendung, ein „Service“, basiert wiederum auf weiteren Services, die dem User die gewünschte Funktion bereitstellen. Wenn ein User z. B. über die Shopping-App eines Einzelhändlers ein Produkt kaufen möchte, möchte er wissen, ob dieses vorrätig ist. Also muss der Service, der mit der Bestandsdatenbank dieser Firma kommuniziert, mit der Produkt-Webseite und diese wiederum mit dem Online-Warenkorb des Users kommunizieren. Um den geschäftlichen Mehrwert zu steigern, entwickelt dieser Einzelhändler irgendwann möglicherweise einen Service, der dem User in der App Produkte empfiehlt. Dieser neue Service kommuniziert für diese Empfehlungen mit einer Datenbank aus Produkt-Tags, aber auch mit derselben Bestandsdatenbank, auf die die Produkt-Webseite zugegriffen hat. Ergo haben wir es mit einer Vielzahl an wiederverwendbaren beweglichen Teilen zu tun.

Moderne Anwendungen werden oft auf diese Weise aufgeschlüsselt, und zwar als Netzwerk an Services, von denen jeder Service eine spezifische Geschäftsfunktion ausführt. Zur Ausführung seiner Funktion muss ein Service möglicherweise Daten von anderen Services anfordern. Was aber passiert, wenn manche dieser Services mit Anfragen überlastet sind, wie z. B. die Bestandsdatenbank unseres Einzelhändlers? Hier kommt das Service Mesh ins Spiel, eine Funktion, die Anfragen von einem Service zum nächsten leitet und das Zusammenspiel aller veränderlichen Teile optimiert.


Ist das nicht die Aufgabe von Microservices?

Mit einer Microservice-Architektur können Entwickler die Services einer App ändern, ohne sie komplett neu bereitstellen zu müssen. Im Gegensatz zur App-Entwicklung in anderen Architekturen werden hier einzelne Microservices von kleinen Teams gebaut, die Tools und Programmiersprachen frei wählen können. Microservices werden grundsätzlich unabhängig voneinander entwickelt, kommunizieren miteinander und können einzeln ausfallen, ohne dass dies zu einem Komplettausfall der ganzen App führt.

Microservice-Architektur

Die Grundlage von Microservices ist die Kommunikation zwischen den einzelnen Services (Interservice-Kommunikation). Eine Kommunikationslogik kann auch ohne Service Mesh in jeden Service programmiert werden, allerdings wird ein Service Mesh mit zunehmender Komplexität der Kommunikation immer sinnvoller. Bei cloudnativen Apps, die in eine Microservice-Architektur integriert sind, kann ein Service Mesh eine große Zahl an separaten Services zu einer funktionsfähigen App zusammenfassen.


Was ist die Funktion von Sidecars in einem Service Mesh?

Ein Service Mesh fügt keine neuen Funktionen zur Runtime-Umgebung einer App hinzu. Für Apps in beliebigen Architekturen wurden zur Übertragung von Anfragen von Punkt A zu Punkt B stets Regeln benötigt. Ein Service Mesh hingegen extrahiert die Logik für die Interservice-Kommunikation aus den einzelnen Services und überträgt sie in eine Infrastrukturschicht.

Hierzu wird das Service Mesh als Array aus Netzwerk-Proxies in eine App integriert. Proxies sind ein bekanntes Konzept aus der Unternehmens-IT. Wenn Sie über einen Arbeits-PC auf diese Website zugreifen, haben Sie wahrscheinlich gerade einen Proxy verwendet:

  1. Ihre Anfrage für diese Seite wurde zunächst vom Web-Proxy Ihres Unternehmens empfangen...
  2. Sobald die Anfrage die Sicherheitsmaßnahme dieses Proxys bestanden hat, wird sie an den Server gesendet, der diese Seite hostet…
  3. Danach wurde diese Seite an den Proxy zurückgeleitet und erneut mit der Sicherheitsmaßnahme geprüft…
  4. Zum Schluss wurde die Seite dann vom Proxy an Sie gesendet.
Netzwerkproxy-Diagramm

In einem Service Mesh werden Anfragen zwischen Microservices über Proxies in einer eigenen Infrastrukturschicht übertragen. Aus diesem Grund werden einzelne Proxies, die ein Service Mesh ausmachen, manchmal „Sidecars“ genannt, da sie parallel zu jedem Service und nicht darin ausgeführt werden. Zusammen bilden diese von jedem Service entkoppelten Sidecar-Proxies ein Mesh-Netzwerk.

Mesh-Netzwerk mit Sidecars

Ein Sidecar-Proxy befindet sich neben einem Microservice und leitet Anfragen an andere Proxies weiter. Zusammen bilden diese Sidecars ein Mesh-Netzwerk.

Ohne Service Mesh müssen alle Microservices mit einer Logik für die Interservice-Kommunikation programmiert werden, was den Entwickler-Fokus auf geschäftliche Ziele beeinträchtigt. Es bedeutet auch, dass Kommunikationsfehler schwerer zu diagnostizieren sind, weil die Logik für die Interservice-Kommunikation in jedem einzelnen Service verborgen ist.


Wie kann ein Service Mesh die Kommunikation verbessern?

Jeder neu hinzugefügte Service oder jede neue Instanz eines vorhandenen Service, der in einem Container ausgeführt wird, macht die Kommunikationsumgebung einer App komplizierter und stellt ein weiteres Ausfallrisiko dar. In einer komplexen Microservice-Architektur kann es fast unmöglich werden, Problemursachen ohne Service Mesh zu diagnostizieren.

Denn in einem Service Mesh werden alle Aspekte der Interservice-Kommunikation sowie Performance-Kennzahlen erfasst. Im Lauf der Zeit können vom Service Mesh sichtbar gemachte Daten auf die Regeln der Interservice-Kommunikation angewandt und so die Effizienz und Zuverlässigkeit von Serviceanfragen verbessert werden.

Beispielsweise kann ein Service Mesh beim Ausfall eines bestimmten Service Daten darüber sammeln, wie lange es bis zu einem erfolgreichen Neuversuch gedauert hat. Basierend auf den gesammelten Daten zu den Ausfallzeiten können dann Regeln geschrieben werden, die die optimale Wartezeit bis zu einem erneuten Serviceaufruf festlegen und sicherstellen, dass das System nicht durch unnötige Neuversuche überlastet wird.


Die Vorteile für Microservices

Bei der Entwicklung von Microservices antizipieren Sie wahrscheinlich bestimmte zukünftige Anforderungen, z. B. ein rasches Skalieren oder Hinzufügen von Funktionen, die Ihre geschäftlichen Erfordernisse erfüllen. Es ist gut möglich, dass eine Microservice-Architektur ein Jahr nach der Entwicklung völlig anders aussieht. Zu Beginn können die in Microservices integrierten Bibliotheken die Interservice-Kommunikation vielleicht noch ohne größere Betriebsunterbrechungen handhaben. Wenn Sie allerdings das Potenzial der Microservices durch einen größeren Umfang und noch mehr Funktionen ausreizen, kann dies bald anders aussehen. Im Laufe der Zeit können Probleme entstehen, weil Services mit Anfragen überlastet werden und Entwickler immer mehr Zeit mit der Codierung der Abfragelogik für jeden Service verbringen.

Ein Service Mesh bietet folgende Vorteile:

  • Entwickler müssen sich nicht auf die Verbindung von Services konzentrieren, sondern können sich dem geschäftlichen Mehrwert widmen.
  • Die Abfragelogik bildet eine sichtbare Infrastruktur parallel zu den Services, wodurch Probleme einfacher zu erkennen und zu diagnostizieren sind.
  • Apps sind ausfallsicherer, da das Service Mesh Anfragen an nicht funktionsfähige Services rechtzeitig umleitet.
  • Performance-Kennzahlen zeigen Möglichkeiten zur Optimierung der Kommunikation in der Runtime-Umgebung auf.

Ein Service Mesh hat noch viel mehr zu bieten