Und wieder hallo!.. Vor dem Start des Kurses haben wir eine weitere nützliche Übersetzung vorbereitet.
Ein Service Mesh ist eine konfigurierbare Infrastruktur-Ebene mit niedriger Latenz, die für die Bearbeitung eines großen Volumens an Netzwerkinterprozesskommunikation zwischen den Anwendungsprogrammierschnittstellen (APIs) erforderlich ist. Das Service Mesh sorgt für schnelle, zuverlässige und sichere Kommunikation zwischen containerisierten und oft kurzlebigen Anwendungsdiensten. Es bietet Funktionen wie Dienstentdeckung, Lastverteilung, Verschlüsselung, Transparenz, Nachverfolgbarkeit, Authentifizierung und Autorisierung sowie Unterstützung des Musterscircuit breaker).
Ein Service Mesh wird üblicherweise implementiert, indem jeder Dienstinstanz eine Proxy-Instanz zugewiesen wird, die als Sidecar bezeichnet wird. Sidecars verarbeiten die Kommunikation zwischen den Diensten, überwachen und beheben Sicherheitsprobleme, also alles, was von den einzelnen Diensten abstrahiert werden kann. Dadurch können Entwickler den Anwendungscode in den Diensten schreiben, pflegen und warten, während Systemadministratoren mit dem Service Mesh arbeiten und die Anwendung betreiben können.
Istio von Google, IBM und Lyft ist derzeit die bekannteste Service Mesh-Architektur. Kubernetes, das ursprünglich bei Google entwickelt wurde, ist jetzt das einzige Containerorchestrierungs-Framework, das von Istio unterstützt wird. Hersteller versuchen, kommerziell unterstützte Versionen von Istio zu erstellen. Es ist interessant, was sie neu in das Open-Source-Projekt einbringen können.
Allerdings ist Istio nicht die einzige Option, da auch andere Implementierungen von Service Mesh entwickelt werden. Das Muster sidecar proxy ist die beliebteste Implementierung, wie man an Projekten wie Buoyant, HashiCorp, Solo.io und anderen erkennen kann. Es gibt auch alternative Architekturen: Das Technologietoolset von Netflix ist ein Ansatz, bei dem die Funktionalität des Service Mesh über Bibliotheken wie Ribbon, Hysterix, Eureka, Archaius sowie Plattformen wie Azure Service Fabric realisiert wird.
Ein Service Mesh hat auch seine eigene Terminologie für Komponenten-Dienste und Funktionen:
- Container-Orchestrierungs-Framework. Mit der Zunahme der Container in der Anwendungsinfrastruktur besteht die Notwendigkeit nach einem separaten Tool zur Überwachung und Verwaltung von Containern – dem Container-Orchestrierungsframework. Kubernetes hat diese Nische nahezu monopolartig besetzt, sodass selbst seine Hauptkonkurrenten Docker Swarm und Mesosphere DC/OS als Alternative die Integration mit Kubernetes anbieten.
- Dienste und Instanzen (Kubernetes-Pods). Eine Instanz ist eine einzelne laufende Kopie eines Mikrodienstes. Manchmal ist eine Instanz ein Container. In Kubernetes besteht eine Instanz aus einer kleinen Gruppe unabhängiger Container, die als Pod bezeichnet wird. Kunden greifen selten direkt auf eine Instanz oder einen Pod zu; häufiger wenden sie sich an einen Dienst, der aus einer Sammlung identischer, skalierbarer und ausfallsicherer Instanzen oder Pods (Replikate) besteht.
- Sidecar-Proxy. Der Sidecar-Proxy arbeitet mit einer Instanz oder einem Pod. Der Zweck des Sidecar-Proxys besteht darin, den eingehenden oder abgehenden Datenverkehr, der von dem Container, mit dem er arbeitet, stammt, weiterzuleiten oder zu proxen. Der Sidecar interagiert mit anderen Sidecar-Proxys und wird durch das Orchestrierungsframework verwaltet. Viele Implementierungen von Service Mesh verwenden Sidecar-Proxy, um den gesamten eingehenden und ausgehenden Datenverkehr einer Instanz oder eines Pods abzufangen und zu steuern.
- Service-Erkennung. Wenn eine Instanz mit einem anderen Dienst interagieren muss, muss sie eine funktionierende und verfügbare Instanz des anderen Dienstes finden (erkennen). In der Regel sucht die Instanz über DNS. Das Container-Orchestrierungsframework führt eine Liste von Instanzen, die bereit sind, Anfragen zu empfangen, und bietet eine Schnittstelle für DNS-Anfragen.
- Lastenausgleich. Die meisten Container-Orchestrierungsframeworks bieten Lastenausgleich auf der Ebene 4 (Transporte). Service Mesh implementiert einen komplexeren Lastenausgleich auf der Ebene 7 (Anwendung), der reich an Algorithmen ist und effizienter im Umgang mit Datenverkehr. Die Lastenausgleichsparameter können über APIs geändert werden, was es ermöglicht, Blue-Green- oder Canary-Deployments zu orchestrieren.
- Verschlüsselung. Das Service Mesh kann Anfragen und Antworten verschlüsseln und entschlüsseln, wodurch die Last von den Diensten genommen wird. Das Service Mesh kann ebenfalls die Leistung erhöhen, indem es bestehende dauerhafte Verbindungen priorisiert oder wiederverwendet, was die Notwendigkeit teurer Berechnungen zur Herstellung neuer Verbindungen verringert. Die gängigste Implementierung der Verkehr Verschlüsselung ist mutual TLS (mTLS), bei der die Infrastruktur öffentlicher Schlüssel (PKI) Zertifikate und Schlüssel generiert und verteilt, um sie im Sidecar Proxy zu verwenden.
- Authentifizierung und Autorisierung. Das Service Mesh kann Anfragen, die extern oder intern an die Anwendung gerichtet sind, autorisieren und authentifizieren, indem es den Instanzen nur validierte Anfragen sendet.
- Unterstützung des Musters für automatisches Ausschalten. Das Service Mesh unterstützt , das nicht gesunde Instanzen isoliert und sie bei Bedarf schrittweise wieder in den Pool gesunder Instanzen zurückführt.
Der Teil der Anwendung des Service Mesh, der den Netzwerkverkehr zwischen den Instanzen verwaltet, wird genannt Data Plane. Die Erstellung und Bereitstellung von Konfigurationen, die das Verhalten Data Plane, verwaltet, erfolgt über eine separate Control Plane. Control Plane , die in der Regel so konzipiert ist, dass sie sich mit APIs, CLIs oder GUIs zur Verwaltung der Anwendung verbindet.
Die Control Plane im Service Mesh verteilt die Konfiguration zwischen Sidecar Proxy und Data Plane.
Die Architektur des Service Mesh wird häufig eingesetzt, um komplexe Betriebsprobleme mit Containern und Mikrodiensten zu lösen. Pioniere auf diesem Gebiet sind Unternehmen wie Lyft, Netflix und Twitter, die Millionen von Nutzern weltweit stetig funktionsfähige Dienste anbieten. ( Hier finden Sie eine ausführliche Beschreibung einiger architektonischer Herausforderungen, mit denen Netflix konfrontiert warDie Architektur des Service Mesh wird wahrscheinlich niemals die Antwort auf alle Fragen zur Funktionsweise und Bereitstellung von Anwendungen sein. Architekten und Entwickler verfügen über ein riesiges Arsenal an Werkzeugen, und nur eines davon ist der Hammer, der unter vielen Aufgaben nur eine lösen soll – Nägel einschlagen.
Microservices Referenzarchitektur von NGINX , zum Beispiel, umfasst mehrere verschiedene Modelle, die ein kontinuierliches Spektrum an Ansätzen zur Lösung von Aufgaben mit Mikrodiensten bieten.
Elemente, die in der Service Mesh-Architektur zusammengeführt werden, wie NGINX, Container, Kubernetes und Mikrodienste als architektonischer Ansatz, können auch in Implementierungen ohne Service Mesh gleichermaßen produktiv verwendet werden. Zum Beispiel wurde Istio als vollständige Service Mesh-Architektur entwickelt, doch die Modularität ermöglicht es Entwicklern, nur die für sie notwendigen Technologiek Komponenten auszuwählen und anzuwenden. In Anbetracht dessen ist es wichtig, ein klares Verständnis des Konzepts von Service Mesh zu entwickeln, auch wenn Sie sich nicht sicher sind, ob Sie es jemals vollständig in einer Anwendung implementieren können.
Quelle: habr.com
