Red Hat SummitÜberblick
Mit einem Service Mesh, wie z. B. dem Open Source-Projekt Istio, 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 Inventory-Datenbank 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 Inventory-Datenbank, auf die die Produkt-Website zugegriffen hat. Wir haben es also 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 Inventory-Datenbank unseres Einzelhändlers? Hier kommt das Service Mesh ins Spiel: Es leitet Anfragen von einem Service zum nächsten und optimiert so das Zusammenspiel aller veränderlichen Teile.
Agile Integration: Ein Blueprint für die Unternehmensarchitektur
Erfahren Sie mehr über die Tools, mit denen Sie die Agilität Ihres Unternehmens verbessern können, wie das Service Mesh und mehr.
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.
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.
Wie funktioniert ein 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:
- Ihre Anfrage für diese Seite wurde zunächst vom Web-Proxy Ihres Unternehmens empfangen...
- Sobald die Anfrage die Sicherheitsmaßnahme dieses Proxys bestanden hat, wird sie an den Server gesendet, der diese Seite hostet…
- Danach wurde diese Seite an den Proxy zurückgeleitet und erneut mit der Sicherheitsmaßnahme geprüft…
- Zum Schluss wurde die Seite dann vom Proxy an Sie gesendet.
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.
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 optimieren?
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.
Zukunftsszenarien überdenken
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.
- Verteiltes Tracing der Anfragen durch Jaeger bietet eine sichtbare Infrastrukturschicht 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.
Beginnen Sie, für die Zukunft zu planen, und testen Sie ein Service Mesh mit Red Hat® OpenShift® Service Mesh. Erleben Sie eine einheitliche Art, mit der sie microservice-basierte Anwendungen verbinden, verwalten und beobachten können. Zusätzlich erhalten Sie Insights zur Nutzung und Kontrolle über die Netzwerk-Microservices in Ihrem Service Mesh. OpenShift Service Mesh ist für Red Hat OpenShift kostenlos erhältlich.
Was ist ein Automatisierungs-Mesh?
Das Automatisierungs-Mesh der Red Hat Ansible Automation Platform bietet ein einfaches und zuverlässiges Service-Mesh-Framework für die Skalierung der Automatisierung. Mit einer flexiblen, multidirektionalen Kommunikationsschicht verbessert das Automatisierungs-Mesh die Fähigkeit eines Unternehmens, auf globaler Ebene zu operieren. Dank der geringeren Anfälligkeit für Latenz und Verbindungsunterbrechungen sowie der nativen Peering-Funktionen können Sie im Vergleich zu allen anderen Automatisierungsplattformen auf dem Markt eine größere Reichweite und mehr Zuverlässigkeit erzielen. Mithilfe von Sicherheitsfunktionen wie TLS-Authentifizierung und -Verschlüsselung sowie zusätzlichen Zugriffskontrollen können Sie sich darauf verlassen, dass die Red Hat Ansible Automation Platform die Möglichkeiten für Ihre gesamte Unternehmens-IT erweitert.
