Was ist ein Service-Mesh? Einfachere Containernetzwerke

Eine der Veränderungen in der IT unter dem Banner der digitalen Transformation ist die Aufteilung großer, monolithischer Anwendungen in Mikrodienste - kleine, diskrete Funktionseinheiten -, die in Containern ausgeführt werden - Softwarepakete, die den gesamten Code des Dienstes und die möglichen Abhängigkeiten enthalten isoliert und einfach von einem Server auf einen anderen verschoben werden.

Container-Architekturen wie diese lassen sich leicht skalieren und in der Cloud ausführen, und einzelne Microservices können schnell eingeführt und iteriert werden. Die Kommunikation zwischen diesen Mikrodiensten wird jedoch immer komplexer, da Anwendungen größer werden und mehrere Instanzen desselben Dienstes gleichzeitig ausgeführt werden. Ein Service-Mesh ist eine aufstrebende Architekturform, die darauf abzielt, diese Microservices dynamisch zu verbinden, um den Verwaltungs- und Programmieraufwand zu reduzieren.

Was ist ein Service-Mesh?

Im weitesten Sinne ist ein Service-Mesh, wie Red Hat es beschreibt, „eine Möglichkeit, zu steuern, wie verschiedene Teile einer Anwendung Daten miteinander teilen.“ Diese Beschreibung könnte jedoch viele verschiedene Dinge umfassen. Tatsächlich klingt es sehr nach der Middleware, mit der die meisten Entwickler aus Client-Server-Anwendungen vertraut sind.

Was ein Service-Mesh einzigartig macht, ist, dass es so konzipiert ist, dass es die Einzigartigkeit verteilter Microservice-Umgebungen berücksichtigt. In einer umfangreichen Anwendung, die aus Microservices erstellt wurde, können mehrere Instanzen eines bestimmten Dienstes auf verschiedenen lokalen oder Cloud-Servern ausgeführt werden. All diese beweglichen Teile erschweren es einzelnen Mikrodiensten offensichtlich, die anderen Dienste zu finden, mit denen sie kommunizieren müssen. Ein Service-Mesh sorgt automatisch dafür, dass Services von Moment zu Moment erkannt und verbunden werden, sodass sowohl menschliche Entwickler als auch einzelne Microservices dies nicht müssen.

Stellen Sie sich ein Service-Mesh als Äquivalent zu Software Defined Networking (SDN) für Level 7 des OSI-Netzwerkmodells vor. So wie SDN eine Abstraktionsschicht erstellt, damit Netzwerkadministratoren sich nicht mit physischen Netzwerkverbindungen befassen müssen, entkoppelt ein Service-Mesh die zugrunde liegende Infrastruktur der Anwendung von der abstrakten Architektur, mit der Sie interagieren.

Die Idee eines Service-Mesh entstand organisch, als Entwickler begannen, sich mit den Problemen wirklich enormer verteilter Architekturen auseinanderzusetzen. Linkerd, das erste Projekt in diesem Bereich, wurde als Ableger eines internen Projekts bei Twitter geboren. Istio, ein weiteres beliebtes Dienstleistungsnetz mit großer Unternehmensunterstützung, entstand in Lyft. (Wir werden uns beide Projekte gleich genauer ansehen.)

Service Mesh Load Balancing

Eines der Hauptmerkmale eines Service-Netzes ist der Lastausgleich . Normalerweise stellen wir uns den Lastenausgleich als Netzwerkfunktion vor. Sie möchten verhindern, dass ein Server oder eine Netzwerkverbindung mit Datenverkehr überlastet wird, und leiten Ihre Pakete entsprechend weiter. Service-Meshs machen auf Anwendungsebene etwas Ähnliches, wie Twain Taylor beschreibt, und ein Verständnis, das Ihnen einen guten Eindruck davon gibt, was wir meinen, wenn wir sagen, dass ein Service-Mesh wie ein softwaredefiniertes Netzwerk für die Anwendungsschicht ist.

Im Wesentlichen besteht eine der Aufgaben des Service-Mesh darin, zu verfolgen, welche Instanzen verschiedener Mikrodienste, die über die Infrastruktur verteilt sind, „am gesündesten“ sind. Es kann sie abfragen, um zu sehen, wie es ihnen geht, oder verfolgen, welche Instanzen langsam auf Serviceanfragen reagieren, und nachfolgende Anfragen an andere Instanzen senden. Das Service-Mesh kann ähnliche Aufgaben für Netzwerkrouten ausführen und feststellen, wenn Nachrichten zu lange brauchen, um an ihr Ziel zu gelangen, und andere Routen verwenden, um dies zu kompensieren. Diese Verlangsamung kann auf Probleme mit der zugrunde liegenden Hardware zurückzuführen sein oder einfach darauf, dass die Dienste mit Anforderungen überlastet sind oder an ihrer Verarbeitungskapazität arbeiten. Wichtig ist, dass das Service-Mesh stattdessen eine andere Instanz desselben Service finden und zu diesem weiterleiten kann, um die Kapazität der gesamten Anwendung so effizient wie möglich zu nutzen.

Service Mesh gegen Kubernetes

Wenn Sie mit containergestützten Architekturen vertraut sind, fragen Sie sich möglicherweise, wo Kubernetes, die beliebte Open-Source-Container-Orchestrierungsplattform, in dieses Bild passt. Ist es nicht der springende Punkt von Kubernetes, dass es verwaltet, wie Ihre Container miteinander kommunizieren? Wie das Kublr-Team in seinem Unternehmensblog ausführt, können Sie sich die "Service" -Ressource von Kubernetes als eine sehr grundlegende Art von Service-Mesh vorstellen, da sie die Serviceerkennung und den Round-Robin-Ausgleich von Anforderungen ermöglicht. Voll funktionsfähige Service-Meshes bieten jedoch viel mehr Funktionen, wie das Verwalten von Sicherheitsrichtlinien und Verschlüsselung, das Unterbrechen von Anforderungen zum Anhalten von Anforderungen an langsam reagierende Instanzen, den oben beschriebenen Lastausgleich und vieles mehr.

Beachten Sie, dass für die meisten Service-Meshes tatsächlich ein Orchestrierungssystem wie Kubernetes erforderlich ist. Service-Meshes bieten erweiterte Funktionen und keinen Ersatz.

Service Mesh vs. API-Gateways

Jeder Mikrodienst stellt eine Anwendungsprogrammierschnittstelle (API) bereit, über die andere Dienste mit ihm kommunizieren. Dies wirft die Frage nach den Unterschieden zwischen einem Service-Mesh und anderen traditionelleren Formen der API-Verwaltung wie API-Gateways auf . Wie IBM erklärt, steht ein API-Gateway zwischen einer Gruppe von Microservices und der „Außenwelt“ und leitet Service-Anforderungen nach Bedarf weiter, sodass der Anforderer nicht wissen muss, dass es sich um eine Microservices-basierte Anwendung handelt. Ein Service-Mesh hingegen vermittelt Anfragen „innerhalb“ der Microservices-App, wobei sich die verschiedenen Komponenten ihrer Umgebung voll bewusst sind.

Eine andere Möglichkeit, darüber nachzudenken, wie Justin Warren in Forbes schreibt , besteht darin, dass ein Service-Mesh für den Ost-West-Verkehr innerhalb eines Clusters und ein API-Gateway für den Nord-Süd-Verkehr innerhalb und außerhalb des Clusters vorgesehen ist. Die ganze Idee eines Service-Netzes ist jedoch noch früh und im Fluss. Viele Service-Meshes - einschließlich Linkerd und Istio - bieten jetzt auch Nord-Süd-Funktionen.

Service-Mesh-Architektur

Die Idee eines Service-Meshs ist erst in den letzten Jahren entstanden, und es gibt verschiedene Ansätze zur Lösung des Problems „Service-Mesh“, dh zur Verwaltung der Kommunikation für Microservices. Andrew Jenkins von Aspen Mesh identifiziert drei mögliche Möglichkeiten, wo sich die vom Service-Mesh erstellte Kommunikationsschicht befinden könnte:

  • In einer Bibliothek , die jeder Ihrer Microservices importiert
  • In einem Knotenagenten , der Dienste für alle Container auf einem bestimmten Knoten bereitstellt
  • In einem Beiwagencontainer , der neben Ihrem Anwendungscontainer läuft

Das Sidecar-basierte Muster ist eines der beliebtesten Service-Mesh-Muster auf dem Markt - so sehr, dass es in gewisser Weise zum Synonym für Service-Meshes im Allgemeinen geworden ist. Obwohl dies streng genommen nicht der Fall ist, hat der Beiwagen-Ansatz so viel Anklang gefunden, dass wir uns diese Architektur genauer ansehen werden.

Beiwagen in einem Servicegitter

Was bedeutet es zu sagen, dass ein Beiwagencontainer neben Ihrem Anwendungscontainer „läuft“? Red Hat hat eine ziemlich gute Erklärung. Jedem Microservices-Container in einem Service-Mesh dieses Typs ist ein weiterer Proxy-Container zugeordnet. Die gesamte für die Service-to-Service-Kommunikation erforderliche Logik wird aus dem Microservice abstrahiert und in den Beiwagen gestellt.

Dies mag kompliziert erscheinen - schließlich verdoppeln Sie effektiv die Anzahl der Container in Ihrer Anwendung! Sie verwenden jedoch auch ein Entwurfsmuster, das für die Vereinfachung verteilter Apps von entscheidender Bedeutung ist. Indem Sie den gesamten Netzwerk- und Kommunikationscode in einem separaten Container ablegen, haben Sie ihn in die Infrastruktur integriert und die Entwickler von der Implementierung als Teil der Anwendung befreit.

Im Wesentlichen haben Sie noch einen Mikroservice übrig, der sich auf seine Geschäftslogik konzentrieren kann. Der Microservice muss nicht wissen, wie er mit allen anderen Diensten in der wilden und verrückten Umgebung, in der sie betrieben werden, kommunizieren kann. Es muss nur wissen, wie man mit dem Beiwagen kommuniziert, der sich um den Rest kümmert.

Service-Meshes: Linkerd, Envio, Istio, Konsul

Welche Service-Meshes stehen zur Verfügung? Nun, es gibt nicht gerade handelsübliche Produkte. Die meisten Service-Meshs sind Open-Source-Projekte, deren Implementierung einige Feinheiten erfordert. Die großen Namen sind:

  • Linkerd (ausgesprochen „Linker-dee“) - Linkerd wurde 2016 veröffentlicht und ist damit das älteste dieser Angebote. Er wurde aus einer bei Twitter entwickelten Bibliothek ausgegliedert. Ein weiterer Schlagmann in diesem Bereich, Conduit, wurde in das Linkerd-Projekt aufgenommen und bildet die Grundlage für Linkerd 2.0.
  • Gesandter - Der bei Lyft erstellte Gesandte belegt den Teil der Datenebene eines Dienstnetzes. Um ein Full-Service-Netz bereitzustellen, muss es mit einer „Steuerebene“ wie ...
  • Istio - Istio wurde in Zusammenarbeit von Lyft, IBM und Google entwickelt und ist ein Kontrollplan für Service-Proxys wie Envoy. Während Istio und Envoy ein Standardpaar sind, kann jedes mit anderen Plattformen gepaart werden.
  • HashiCorp Consul - Mit Consul 1.2 wurde eine Funktion namens Connect eingeführt, die dem verteilten System von HashiCorp eine Serviceverschlüsselung und identitätsbasierte Autorisierung für die Serviceerkennung und -konfiguration hinzufügte und es zu einem vollständigen Service-Mesh machte.

Welches Service-Mesh passt zu Ihnen? Ein Vergleich würde den Rahmen dieses Artikels sprengen, aber es ist erwähnenswert, dass alle oben genannten Produkte in großen und anspruchsvollen Umgebungen bewiesen wurden. Linkerd und Istio verfügen über die umfangreichsten Funktionen, aber alle entwickeln sich rasant weiter. Vielleicht möchten Sie sich George Mirandas Aufschlüsselung der Funktionen von Linkerd, Envoy und Istio ansehen, aber denken Sie daran, dass sein Artikel geschrieben wurde, bevor Conduit und Linkerd sich zusammengeschlossen haben.

Denken Sie auch daran, dass dieser Raum neu ist und jederzeit neue Konkurrenten entstehen können. Beispielsweise bot Amazon im November 2018 eine öffentliche Vorschau eines AWS-Service-Meshs an. In Anbetracht der Anzahl der Shops, die die öffentliche Cloud von Amazon verwenden, sollte AWS App Mesh einen großen Einfluss haben.