Das Service Mesh – Funktionsweise und Vorteile

Ein Service Mesh ist eine dedizierte Infrastrukturschicht innerhalb einer Softwareanwendung, die die Kommunikation zwischen Services handhabt. Ein Service Mesh kann Funktionen für Routing des Datenverkehrs, Sicherheit, Beobachtbarkeit und Resilienz verwalten und gleichzeitig diese Komplexitäten für einzelne Services mindern.

Moderne Anwendungen setzen auf Services, die miteinander kommunizieren. Erinnern Sie sich nur einmal an Ihren letzten Besuch in einem Online-Shop. Dabei haben Sie vielleicht die Funktion für die Produktsuche auf der jeweiligen Site verwendet. Diese Suchfunktion ist ein Service. Vielleicht wurden Ihnen auch Vorschläge für ähnliche Produkte unterbreitet, oder Sie haben ein Produkt zu Ihrem Warenkorb hinzugefügt. Dabei handelt es sich auch um Services. Der Service, der mit der Bestandsdatenbank in Kontakt ist, muss mit der Produktwebseite, und diese muss wiederum mit dem Warenkorb der Nutzenden kommunizieren. Der Einzelhändler hat möglicherweise auch einen Service, der den Nutzenden in der App Produkte empfiehlt. Dieser Service kommuniziert für diese Empfehlungen mit einer Datenbank aus Produkt-Tags. Er muss außerdem mit derselben Bestandsdatenbank kommunizieren, auf die die Produktwebseite zugegriffen hat.

Moderne Anwendungen werden oft auf diese Weise aufgeschlüsselt, und zwar als Netzwerk an Services, von denen jeder 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 etwa die Bestandsdatenbank unseres Einzelhändlers? Hier kommt das Service Mesh ins Spiel, eine Funktion, die die Kommunikation zwischen Services managt und so das Zusammenspiel der veränderlichen Teile optimiert.

Ein Service Mesh kann als ein Microservices-Architekturmuster angesehen werden. Microservices sind eine Art von Anwendungsarchitektur, bei der eine Sammlung unabhängiger Services über schlanke APIs (Application Programming Interfaces) miteinander kommuniziert. Eine Microservices-Architektur ist ein cloudnativer Ansatz, bei dem Software so entwickelt wird, dass Kernfunktionen innerhalb einer Anwendung unabhängig voneinander funktionieren. Im Gegensatz zur Anwendungsentwicklung in anderen Architekturen können individuelle Microservices von kleinen Teams gebaut werden, die Tools und Programmiersprachen frei wählen können. Microservices werden unabhängig entwickelt, kommunizieren miteinander und können einzeln versagen, ohne dass dies zu einem Komplettausfall der jeweiligen Anwendung führt.

Die Grundlage von Microservices ist die Kommunikation zwischen den einzelnen Services (Interservice-Kommunikation). Mit dem Wachstum der Microservices-Architektur wird auch ihre Verwaltung komplexer. Wenn eine App Dutzende oder Hunderte von Services beinhaltet, die miteinander interagieren, entwickeln sich Netzwerkausfälle, Überwachung und Nachverfolgung, Load Balancing des Datenverkehrs und Sicherung der Kommunikation zwischen unterschiedlichen Microservices zur Herausforderung. Diese Probleme in ihrer Gesamtheit mit benutzerdefiniertem Code zu beheben, wäre ineffizient. Ein Service Mesh bietet eine konsistente Lösung zur Bewältigung dieser Herausforderungen, ohne dass der Code einzelner Services geändert werden muss.

Ein Service Mesh verwaltet die Kommunikation zwischen Services unter Verwendung einer Data Plane und einer Control Plane. 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. Wenn Sie über einen Arbeits-PC auf diese Website zugreifen, haben Sie wahrscheinlich gerade einen Proxy verwendet. Und so funktioniert‘s:

1. Ihre Anfrage für diese Seite wurde vom Web-Proxy Ihres Unternehmens empfangen.
2. Sobald die Anfrage die Sicherheitsmaßnahme dieses Proxys bestanden hat, wurde 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. Anschließend wurde die Seite vom Proxy an Sie gesendet.

In einem Service Mesh wird jede Service-Instanz mit einem „Sidecar“ Proxy gekoppelt, der parallel zu den einzelnen Services ausgeführt wird und sämtlichen ein- und ausgehenden Netzwerkverkehr abfängt. Jeder Sidecar Proxy befindet sich neben einem Microservice und leitet Anfragen an andere und von anderen Proxies weiter. Der Proxy übernimmt Aufgaben wie Routing des Datenverkehrs, Load Balancing, Durchsetzung von Sicherheitsrichtlinien und Erfassung von Telemetriedaten. Anstatt direkt miteinander zu kommunizieren, senden Services Anfragen durch ihr Sidecar. Diese Sidecars wickeln die Interservice-Kommunikation ab. All dies ist Bestandteil der Data Plane.

Die Control Plane verwaltet die Konfiguration und die Verteilung von Richtlinien in der Data Plane. Sie verteilt außerdem Regeln für das Routing des Datenverkehrs, verwaltet Sicherheitszertifikate zwischen Services, konfiguriert Komponenten zur Durchsetzung von Richtlinien und erfasst Telemetriedaten.

Ohne Service Mesh muss jeder Microservice mit einer Logik für die Verwaltung der Interservice-Kommunikation programmiert werden. Dies erschwert die Diagnose von Kommunikationsfehlern, da die Logik für die Interservice-Kommunikation in jedem einzelnen Service verborgen ist.

Mehr über Microservices erfahren

Istio ist eine auf Open Source basierende Service Mesh-Plattform, die steuert, wie Microservices Daten miteinander teilen. Sie steuert den Datenverkehrsfluss, setzt Richtlinien durch und überwacht die Kommunikation in einer Microservices-Umgebung. Istio umfasst APIs, mit denen sich die Lösung in beliebige Protokollierungsplattformen sowie Telemetrie- oder Richtliniensysteme integrieren lässt. Istio kann in verschiedensten Umgebungen ausgeführt werden, ob On-Premise, in der Cloud, containerisiert oder virtualisiert.

Die Architektur von Istio besteht aus einer Data Plane und einer Control Plane. Istio verwendet Envoy-Proxies. Dabei handelt es sich um hochleistungsfähige Proxies, die Datenverkehr für jeden Service innerhalb des Service Mesh vermitteln. In der Data Plane können Entwicklerinnen und Entwickler einem Service Istio-Support hinzufügen, indem Sie einen Sidecar Proxy innerhalb der Umgebung bereitstellen.

Das Service Mesh von Istio beinhaltet einen neuen Ambient-Modus, der Sidecar Proxies im Service Mesh überflüssig macht. Diese werden durch Proxies auf Knotenebene und Zwischen-Gateways, sogenannte Waypoints, ersetzt. Waypoint Proxies werden außerhalb von Anwendungspods ausgeführt und unabhängig von Anwendungen verwaltet.

Mehr über Red Hat Developer Hub erfahren

Jeder neu zu einer App 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 Microservices-Architektur kann es fast unmöglich sein, Probleme ohne Service Mesh zu diagnostizieren.

Die Verwendung eines Service Mesh bietet mehrere Vorteile, darunter:

• Mehr Sicherheit: Ein Service Mesh verwendet mTLS (Mutual Transport Layer Security), um sicherzustellen, dass die Kommunikation zwischen Services verschlüsselt und sicher ist und vertrauliche Nutzerdaten geschützt sind. Das Resultat ist eine zusätzliche Sicherheitsschicht, ohne dass zusätzliche Verschlüsselung manuell zu jedem Service hinzugefügt werden muss. Ein Service Mesh kann Role-based Access Control (RBAC) für die Sicherung von APIs verbessern und auch Funktionen für Zertifikatsmanagement und Schlüsselrotation automatisieren.
• Durchsetzung von Richtlinien: Service Meshes beinhalten eine zentrale Konfiguration für Service-Richtlinien wie etwa Quotas, Durchsatzbeschränkungen sowie Authentifizierung und Autorisierung. Dies ermöglicht die Kontrolle über Service-Interaktionen durch Zugriffsrichtlinien. Die Richtliniendurchsetzung auf Proxy-Ebene trägt zu serviceübergreifender Konsistenz bei.
• Datenverkehrsmanagement: Ein Service Mesh kann Ihre Apps bei der Verwaltung von Datenverkehr zu individuellen Services unterstützen, basierend auf Auslastung, Versionen und nutzerspezifischen Regeln. Wenn Sie beispielweise derzeit eine neue Version Ihres Bestandsservices einführen, können Sie Canary Deployment verwenden, um nur 5 % des Datenverkehrs zu dem neuen Service zu leiten. (Ein Canary ist ein kleineres Testdeployment.) Wenn es funktioniert, können Sie den Datenverkehr erhöhen.
• Zustandsprüfungen und Beobachtbarkeit: Die Art und Weise, in der Microservices in Echtzeit interagieren, ist möglicherweise schwer zu visualisieren. Mit einem Service Mesh können Sie jedoch integrierte Beobachtbarkeitstools wie Distributed Tracing und die Erfassung von Metriken implementieren. Sidecars in einem Service Mesh erfassen Metriken (Anzahl an Anfragen, Latenz, Fehlerraten) und senden sie an die Control Plane oder an Monitoring-Tools.
• Fehlertoleranz und erhöhte Resilienz: Wenn Microservices ausfallen, kann ein Service Mesh helfen, indem es Neuversuche und Fallbacks automatisiert. Falls ein Service ausfällt oder nicht mehr reagiert, unternimmt das Service Mesh auf Basis vordefinierter Regeln einen Neuversuch und kann Datenverkehr zu alternativen Services umleiten. Das bedeutet, die App kann Ausfälle problemlos handhaben und selbst bei Nichtverfügbarkeit eines Services ein zufriedenstellendes Nutzererlebnis gewährleisten. Das Service Mesh sammelt auch Daten darüber, wie viel Zeit bis zu einem erfolgreichen Neuversuch vergangen ist. Diese Daten können in zukünftige Regeln für optimale Wartezeiten einfließen, um eine Überlastung des Systems durch unnötige Neuversuche zu vermeiden.

Mit einem Service Mesh sind Entwicklungs- und Operations-Teams besser ausgerüstet für die Migration von monolithischen Anwendungen auf cloudnative Apps – also Sammlungen kleiner, unabhängiger und lose gekoppelter Microservice-Anwendungen. 

Die Implementierung eines Service Mesh kann Unternehmen vor Herausforderungen stellen, darunter:

• Komplexität und Integration mit vorhandenen Systemen: Die Einrichtung, Verwaltung und Integration mit vorhandenen Systemen eines Service Mesh kann schwierig sein. Unternehmen, die in einer großen, verteilten Umgebung übergreifend mit Multi Cloud- und On-Premise-Systemen arbeiten oder bislang noch kein Service Mesh in ihrer Umgebung verwendet haben, stoßen möglicherweise auf Probleme.
• Ressourcenbedarf und Betriebsaufwand: Service Meshes können den Betriebsaufwand für das Management von Anwendungen erhöhen, da jede Service-Instanz jetzt über einen Sidecar Proxy verfügt, der die CPU- und Speichernutzung erhöht. Management und Problembehebung können sich insbesondere in groß angelegten Deployments als komplex erweisen und die Aufrechterhaltung der Performance und Skalierung erschweren.
• Kompetenzlücken: Ihre Teams benötigen Training, um Einblick in die Leistungsmerkmale, die Konfiguration und die Best Practices von Service Mesh zu erhalten. Das Debuggen von Fehlern kann schwierig sein, vor allem bei Problemen im Zusammenhang mit komplexen Routing-Regeln oder mTLS-Fehlkonfigurationen. Viele Unternehmen stellen bei ihren existierenden Teams mangelndes Fachwissen in Bezug auf Service Mesh-Technologie fest, was den Einstieg in und die effektive Nutzung von Services Meshes erschweren kann.

Ein API-Gateway ist ein API-Managementtool, das zwischen einem Client und einer Sammlung von Backend-Services sitzt. Ein Client ist in diesem Fall eine Anwendung auf einem Nutzergerät, und die Backend-Services befinden sich auf einem Unternehmensserver. Mit einem API-Gateway können Sie die Client-Oberfläche von der Backend-Implementierung entkoppeln. Wenn ein Client dann eine Anfrage absetzt, schlüsselt das API-Gateway diese in mehrere Teilanfragen auf, leitet sie an die jeweiligen Ziele weiter, erstellt eine Antwort und überwacht den gesamten Prozess.

Ein Service Mesh sichert die interne Service-Kommunikation und lässt gleichzeitig externen Datenverkehr durch das API-Gateway zu. Ein gemeinsam mit einem API-Gateway genutztes Service Mesh kann sicherstellen, dass Richtlinien einheitlich über interne Services hinweg durchgesetzt werden. 

Mehr über Red Hat 3scale API Management erfahren

Red Hat bietet integrierte Produkte für API-Management, Service Mesh und Infrastrukturplattformen, mit denen Sie eine komplette Servicemanagement-Architektur erstellen können. Red Hat® OpenShift® Service Mesh bietet Ihnen die Möglichkeit, microservicebasierte Anwendungen auf einheitliche Weise zu verbinden, zu verwalten und zu überwachen. Neben den entsprechenden Kontrollfunktionen erhalten Sie Einblicke in das Verhalten der vernetzten Microservices in Ihrem Service Mesh.

OpenShift Service Mesh baut auf dem Open Source-Projekt Istio auf und bietet durch die Einbeziehung weiterer Open Source-Projekte wie Kiali (Istio-Konsole) und Jaeger (Distributed Tracing) zusätzliche Funktionen, die die Zusammenarbeit mit führenden Mitgliedern der Istio-Community unterstützen. Mit OpenShift Service Mesh können Entwicklerinnen und Entwickler ihre Produktivität steigern, indem sie Kommunikationsrichtlinien ohne eine Änderung des Anwendungscodes oder die Verwendung von sprachspezifischen Libraries integrieren.

Red Hat OpenShift Service Mesh ist vorinstalliert, getestet und für Red Hat OpenShift optimiert. Es bietet Kompatibilität mit OpenShift-spezifischen Features wie Operatoren und CI/CD-Pipelines (Continuous Integration/Continuous Delivery). Hinzu kommen der Red Hat Unternehmens-Support sowie regelmäßige Updates und Patches zur Wahrung der Sicherheit und Stabilität. Der Betrieb von OpenShift Service Mesh über zahlreiche Red Hat OpenShift-Cluster hinweg schafft Konsistenz zwischen Hybrid Cloud- oder Multi Cloud-Umgebungen.