Hallo nochmals!.. Vor dem Start des Kurses haben wir eine weitere nützliche Übersetzung vorbereitet.
Service Mesh ist eine konfigurierbare Infrastruktur-Ebene mit niedriger Latenz, die zur Verarbeitung eines hohen Volumens an Netzwerk-Messaging zwischen den Schnittstellen von Anwendungen (API) erforderlich ist. Service Mesh sorgt für eine schnelle, zuverlässige und sichere Kommunikation zwischen containerisierten und oft vorübergehenden Diensten in der Anwendungsinfrastruktur. Service Mesh bietet Funktionen wie Dienstentdeckung, Lastverteilung, Verschlüsselung, Transparenz, Nachverfolgbarkeit, Authentifizierung und Autorisierung sowie Unterstützung für das Schaltungsschutzmuster (circuit breaker).
Service Mesh wird typischerweise implementiert, indem jedem Dienstinstanz eine Proxy-Instanz bereitgestellt wird, die als Sidecar bezeichnet wird. Sidecar verarbeiten die Kommunikation zwischen Services, überwachen und beheben Sicherheitsprobleme — also alles, was von einzelnen Services abstrahiert werden kann. Auf diese Weise können Entwickler den Code der Anwendung in den Services schreiben, warten und unterstützen, während Systemadministratoren mit dem Service Mesh arbeiten und die Anwendung bereitstellen.
Istio von Google, IBM und Lyft ist derzeit die bekannteste Service Mesh-Architektur. Kubernetes, das ursprünglich von Google entwickelt wurde, ist mittlerweile das einzige Framework für die Orchestrierung von Containern, das von Istio unterstützt wird. Anbieter versuchen, kommerzielle unterstützte Versionen von Istio zu erstellen. Es ist interessant, was sie 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 an Projekten wie Buoyant, HashiCorp, Solo.io und anderen erkennbar ist. Es gibt jedoch auch alternative Architekturen: das technologische Werkzeug von Netflix ist ein Ansatz, bei dem die Funktionalität des Service Mesh durch Bibliotheken wie Ribbon, Hysterix, Eureka, Archaius sowie Plattformen wie Azure Service Fabric realisiert wird.
Service Mesh hat auch seine eigene Terminologie für Komponenten-Services und Funktionen:
- Container-Orchestrierungs-Framework. Mit der zunehmenden Anzahl von Containern in der Anwendungsinfrastruktur wird ein separates Tool zur Überwachung und Verwaltung von Containern erforderlich – das Container-Orchestrierungs-Framework. Kubernetes hat diesen Bereich fest übernommen, soweit sogar seine Hauptkonkurrenten Docker Swarm und Mesosphere DC/OS eine Integration mit Kubernetes als Alternative anbieten.
- Dienste und Instanzen (Kubernetes-Pods). Eine Instanz ist die einzige laufende Kopie eines Mikrodienstes. Manchmal entspricht eine Instanz einem Container. In Kubernetes besteht eine Instanz aus einer kleinen Gruppe unabhängiger Container, die als Pod bezeichnet wird. Clients greifen selten direkt auf eine Instanz oder einen Pod zu; vielmehr wenden sie sich an einen Dienst, der eine Gruppe identischer, skalierbarer und ausfallsicherer Instanzen oder Pods (Replikate) darstellt.
- Sidecar Proxy. Der Sidecar Proxy arbeitet mit einer einzelnen Instanz oder einem Pod. Das Konzept des Sidecar Proxy besteht darin, den eingehenden oder abgehenden Traffic zu leiten oder zu proxyen, der von dem Container kommt, mit dem er arbeitet. Der Sidecar interagiert mit anderen Sidecar Proxys und wird durch das Orchestrierungsframework verwaltet. Viele Implementierungen von Service Mesh nutzen den Sidecar Proxy, um den gesamten eingehenden und ausgehenden Traffic der Instanz oder des Pods abzufangen und zu steuern.
- Dienstentdeckung. Wenn ein Container-Exemplar mit einem anderen Dienst interagieren muss, benötigt es ein funktionierendes und verfügbares Exemplar dieses Dienstes. In der Regel erfolgt die Suche nach dem Exemplar über DNS. Das Container-Orchestrierungsframework speichert eine Liste von Exemplaren, die bereit sind, Anfragen zu erhalten, und stellt eine Schnittstelle für DNS-Anfragen zur Verfügung.
- Lastenausgleich. Die meisten Container-Orchestrierungsframeworks bieten eine Lastverteilung auf der Transportschicht (Layer 4). Service Mesh implementiert eine komplexere Lastverteilung auf der Anwendungsschicht (Layer 7), die reich an Algorithmen ist und effizienter im Management des Datenverkehrs. Die Lastverteilungseinstellungen können über API angepasst werden, was eine Orchestrierung von Blue-Green- oder Canary-Deployments ermöglicht.
- Verschlüsselung. Der Service Mesh kann Anfragen und Antworten verschlüsseln und entschlüsseln, wodurch die Last von den Diensten genommen wird. Zudem kann der Service Mesh die Leistung durch Priorisierung oder Wiederverwendung bestehender, dauerhafter Verbindungen steigern, was die Notwendigkeit teurer Berechnungen zur Herstellung neuer Verbindungen verringert. Die gängigste Implementierung der Verkehrsschlüsselung ist mutual TLS (mTLS), wobei die Public-Key-Infrastruktur (PKI) Zertifikate und Schlüssel generiert und verteilt, die im Sidecar-Proxy verwendet werden.
- Authentifizierung und Autorisierung. Der Service Mesh kann Anfragen, die von außen oder innerhalb der Anwendung gestellt werden, autorisieren und authentifizieren, indem er nur validierte Anfragen an die Instanzen sendet.
- Unterstützung des Musters für automatisches Abschalten. Der Service Mesh unterstützt , welches ungesunde Instanzen isoliert und sie bei Bedarf schrittweise wieder in den Pool gesunder Instanzen zurückführt.
Der Teil des Service Mesh, der den Netzwerkverkehr zwischen den Instanzen verwaltet, wird genannt Data Plane. Die Erstellung und Bereitstellung der Konfiguration, die das Verhalten steuert Data Plane, erfolgt über separate Control Plane. Control Plane verbindet in der Regel oder ist so konzipiert, dass sie über API, CLI oder GUI zur Verwaltung der Anwendung zugreift.
Der Control Plane im Service Mesh verteilt die Konfiguration zwischen Sidecar Proxy und Data Plane.
Die Architektur des Service Mesh wird häufig zur Lösung komplexer betrieblicher Aufgaben mit Containern und Microservices eingesetzt. Zu den Pionieren in diesem Bereich gehören Unternehmen wie Lyft, Netflix und Twitter, die stabil laufende Dienste für Millionen von Nutzern weltweit bereitstellen. (). Für weniger anspruchsvolle Anwendungsfälle sind wahrscheinlich einfachere Architekturen ausreichend.
Die Architektur des Service Mesh wird kaum jemals die Antwort auf alle Fragen zur Funktionsweise von Anwendungen und deren Bereitstellung 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 – das Einschlagen von Nägeln. , zum Beispiel umfasst mehrere verschiedene Modelle, die ein kontinuierliches Spektrum an Ansätzen zur Lösung von Problemen mit Mikroservices bieten.
Die Elemente, die in der Service-Mesh-Architektur zusammenkommen, wie NGINX, Container, Kubernetes und Mikroservices als architektonischer Ansatz, können auch in Implementierungen ohne Service Mesh äußerst effektiv eingesetzt werden. So wurde beispielsweise Istio als vollständige Service-Mesh-Architektur entwickelt, wobei die Modularität bedeutet, dass Entwickler nur die benötigten Komponenten der Technologien auswählen und anwenden können. In Anbetracht dessen ist es wichtig, ein klares Verständnis des Konzepts des Service Mesh zu entwickeln, auch wenn Sie sich nicht sicher sind, ob Sie es jemals vollständig in einer Anwendung umsetzen können.
Quelle: habr.com
