Verwaltung zwischen Mikrodiensten Service-Mesh – Booster für Microservices

Wer Microservices implementieren will, braucht eine schnelle und zuverlässige Netzwerk-Infrastruktur. Ein Service-Mesh ist eine Architekturform, die darauf abzielt, Microservices dynamisch zu verbinden, um den Verwaltungs- und Programmieraufwand zu reduzieren.

Ein Trend der digitalen Transformation ist die Zerlegung großer, monolithischer Anwendungen in kleine, diskrete Funktionseinheiten, die Microservices genannt und in Containern ausgeführt werden. Container-Architekturen lassen sich leicht skalieren und in der Cloud ausführen. Zudem ermöglichen einzelne Microservices einen schnellen Rollout als auch iterative Prozesse.

Die Kommunikation zwischen Microservices wird jedoch zunehmend komplexer, wenn sich die Anwendungen zusehends vergrößern und mehrere Instanzen desselben Dienstes gleichzeitig ausgeführt werden sollen. Ein Service-Mesh sorgt für Sicherheit, Ausfallsicherheit und Transparenz, so dass Entwickler sich nicht mehr um den Datenaustausch kümmern müssen.

Große verteilte Architekturen

Zunächst einmal zielt das Service-Mesh als Architekturform darauf ab, Microservices dynamisch zu verbinden, um den Verwaltungs- und Programmieraufwand deutlich zu reduzieren. Man könnte auch sagen, ein Service-Mesh ist eine Art Steuerung, wie verschiedene Teile einer Anwendung Daten miteinander teilen. Im Grunde ähnelt Service-Mesh einer Middleware, die die meisten Entwickler von Client-Server-Anwendungen her kennen. Entscheidend ist dabei, dass es auf die Besonderheiten von verteilten Microservice-Umgebungen zugeschnitten wurde.

In größer angelegten Anwendungen, die aus Microservices bestehen, kann es mehrere Instanzen eines bestimmten Services geben, die auf verschiedenen lokalen Servern oder Cloud-Servern laufen. All diese Teilbereiche machen es für einzelne Microservices natürlich schwierig, die jeweiligen Services zu finden, mit denen sie kommunizieren müssen. Ein Service-Mesh steuert daher automatisiert das Auffinden und Verbinden von Services auf einer Moment-zu-Moment-Basis, so dass sowohl Entwickler als auch einzelne Microservices dies nicht übernehmen müssen.

Die Grundidee eines Service-Mesh ist daraus erwachsen, dass Entwickler begannen, sich mit den Problemen wirklich großer verteilter Architekturen auseinanderzusetzen. Linkerd, das erste Projekt in diesem Bereich, entstand als Ableger eines internen Projekts bei Twitter. Istio, ein weiteres beliebtes Service-Mesh, entstand bei Lyft.

Lastausgleich mit Service-Mesh

Eine der wichtigsten Funktionen, die ein Service-Mesh bietet, ist beispielsweise der Lastausgleich. Dabei geht es darum, die über die Infrastruktur verteilten Instanzen der verschiedenen Microservices zu beobachten. Reagieren manche Instanzen nur langsam auf Service-Anfragen, dann können nachfolgende Anfragen an andere Instanzen gesendet werden. Das Service-Mesh kann ähnliche Aufgaben auch für Netzwerkrouten übernehmen, indem es feststellt, ob Nachrichten zu lange brauchen, um ihr Ziel zu erreichen, und in der Folge andere Routen zuweisen, um dies zu kompensieren.

Verzögerungen dieser Art können auf Probleme mit der zugrundeliegenden Hardware zurückzuführen sein oder einfach darauf, dass die Dienste insgesamt mit Anfragen überlastet sind oder an ihrer Verarbeitungskapazität stehen. Das Wichtigste ist jedoch dabei, dass das Service-Mesh eine andere Instanz desselben Dienstes und damit eine Route findet, wodurch die Gesamtkapazität der Anwendung möglichst effizient genutzt werden kann.

Abgrenzung zu Kubernetes

Die „Service“-Ressource von Kubernetes sollte man sich als eine einfache Variante von Service-Mesh vorstellen, da sie die Erkennung von Diensten und den Round-Robin-Ausgleich von Anfragen ermöglicht. Das voll ausgestattete Service-Mesh umfasst jedoch deutlich mehr Funktionen wie beispielsweise die Verwaltung von Sicherheitsrichtlinien und Verschlüsselung sowie Circuit Breaking, um Anfragen an langsam reagierende Instanzen zu unterbrechen und vieles mehr. Wobei die meisten Service-Meshes ein Orchestrierungssystem wie Kubernetes voraussetzen. Das heißt, Service Meshes bieten eine erweiterte Funktionalität, nicht einen Ersatz.

Abgrenzung zu API-Gateways

Jeder Microservice verfügt über eine API-Schnittstelle, wodurch andere Services mit ihm kommunizieren. Ein API-Gateway steht zwischen einer Gruppe von Microservices und der Außenwelt und leitet Serviceanfragen nach Bedarf weiter, so dass der Anfragende nicht wissen muss, dass er es mit einer Microservices-basierten Anwendung zu tun hat. Ein Service-Mesh hingegen vermittelt Anfragen innerhalb der Microservices-Anwendung, wobei sich die verschiedenen Komponenten ihrer Umgebung „voll bewusst“ sind.

Architektur eines Service-Mesh

Es gibt drei Möglichkeiten für die Unterbringung einer durch das Service-Mesh geschaffenen Kommunikationsschicht:

• In einer Bibliothek, die Microservices importiert.

• In einem Knoten-Agenten, der allen Containern auf einem bestimmten Knoten Dienste zur Verfügung stellt.

• In einem Sidecar-Container, der neben dem Anwendungscontainer läuft.

Der Sidecar-basierte Ansatz ist einer der beliebtesten Service-Mesh-Ansätze überhaupt. In gewisser Weise wurde er quasi zum Synonym für einen Service-Mesh überhaupt. Wenn ein Sidecar-Container neben einem Anwendungscontainer läuft, bedeutet das, dass die gesamte Logik, die für die Kommunikation zwischen den Diensten erforderlich ist, aus dem Microservice abstrahiert und in den Sidecar verlagert wird. Das heißt, jeder Microservices-Container hat in einem solchen Service-Mesh einen anderen Proxy-Container, der ihm entspricht.

Einerseits verdoppelt sich dadurch die Anzahl der Container in der jeweiligen Anwendung, andererseits vereinfacht es das Muster für verteilte Anwendungen. Indem der gesamte Netzwerk- und Kommunikationscode in einen separaten Container gepackt wird, ist er Teil der Infrastruktur und befreit die Entwickler von der Implementierung als Teil der Anwendung. Im Grunde verbleibt ein Microservice, der sich ganz auf seine Geschäftslogik konzentrieren kann. Der Microservice muss nicht wissen, wie er mit allen anderen Services in der Umgebung, in der er arbeitet, kommunizieren soll. Er muss nur wissen, wie er mit dem Sidecar kommuniziert, der sich um den Rest kümmert.

(ID:48460151)