Hallo nochmal!.. Am Vorabend des Kursbeginns Wir haben eine weitere nützliche Übersetzung vorbereitet.
Ein Service Mesh ist eine konfigurierbare Infrastrukturschicht mit geringer Latenz, die für die Verarbeitung großer Mengen netzwerkbasierter Interprozesskommunikation zwischen Anwendungsprogrammierschnittstellen (APIs) erforderlich ist. Service Mesh ermöglicht eine schnelle, zuverlässige und sichere Kommunikation zwischen containerisierten und oft kurzlebigen Anwendungsinfrastrukturdiensten. Service Mesh bietet Funktionen wie Diensterkennung, Lastausgleich, Verschlüsselung, Transparenz, Rückverfolgbarkeit, Authentifizierung und Autorisierung sowie Unterstützung für automatische Abschaltmuster (Schutzschalter).
Ein Service-Mesh wird normalerweise implementiert, indem jeder Service-Instanz eine Proxy-Instanz namens „ Beiwagen. Beiwagen kümmern sich um die Kommunikation zwischen Diensten, überwachen und lösen Sicherheitsprobleme, also alles, was von einzelnen Diensten abstrahiert werden kann. Auf diese Weise können Entwickler Anwendungscode in Diensten schreiben, verwalten und bereitstellen, und Systemadministratoren können mit dem Service Mesh arbeiten und die Anwendung ausführen.
Istio von Google, IBM und Lyft ist derzeit die bekannteste Service-Mesh-Architektur. Und Kubernetes, das ursprünglich bei Google entwickelt wurde, ist mittlerweile das einzige von Istio unterstützte Container-Orchestrierungs-Framework. Anbieter versuchen, kommerziell unterstützte Versionen von Istio zu erstellen. Es wird interessant sein zu sehen, welche neuen Dinge sie in das Open-Source-Projekt einbringen können.
Istio ist jedoch nicht die einzige Option, da andere Service Mesh-Implementierungen entwickelt werden. Muster sidecar proxy ist die beliebteste Implementierung, wie die Projekte Buoyant, HashiCorp, Solo.io und andere zeigen. Es gibt auch alternative Architekturen: Das Netflix-Technologie-Toolkit ist einer der Ansätze, bei denen die Service Mesh-Funktionalität über die Bibliotheken Ribbon, Hysterix, Eureka, Archaius sowie Plattformen wie Azure Service Fabric implementiert wird.
Service Mesh hat auch eine eigene Terminologie für Servicekomponenten und -funktionen:
- Container-Orchestrierungs-Framework. Da der Anwendungsinfrastruktur immer mehr Container hinzugefügt werden, besteht Bedarf an einem separaten Tool zur Überwachung und Verwaltung von Containern – einem Container-Orchestrierungs-Framework. Kubernetes hat diese Nische so stark besetzt, dass sogar 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 Microservices. Manchmal ist eine Instanz ein Container. In Kubernetes besteht eine Instanz aus einer kleinen Gruppe unabhängiger Container, die als Pod bezeichnet werden. Clients greifen selten direkt auf eine Instanz oder einen Pod zu; häufiger greifen sie auf einen Dienst zu, bei dem es sich um eine Reihe identischer, skalierbarer und fehlertoleranter Instanzen oder Pods (Replikate) handelt.
- Sidecar-Proxy. Sidecar Proxy funktioniert mit einer einzelnen Instanz oder einem einzelnen Pod. Der Zweck von Sidecar Proxy besteht darin, den Datenverkehr, der von dem Container kommt, mit dem er arbeitet, weiterzuleiten oder zu übertragen und den Datenverkehr zurückzuleiten. Sidecar interagiert mit anderen Sidecar-Proxys und wird von einem Orchestrierungs-Framework verwaltet. Viele Service Mesh-Implementierungen verwenden Sidecar Proxy, um den gesamten Datenverkehr in und aus einer Instanz oder einem Pod abzufangen und zu verwalten.
- Diensterkennung. Wenn eine Instanz mit einem anderen Dienst kommunizieren muss, muss sie eine fehlerfreie und verfügbare Instanz des anderen Dienstes finden (entdecken). Normalerweise führt die Instanz DNS-Suchen durch. Das Container-Orchestrierungs-Framework verwaltet eine Liste von Instanzen, die bereit sind, Anfragen zu empfangen, und stellt eine Schnittstelle für DNS-Abfragen bereit.
- Lastverteilung. Die meisten Container-Orchestrierungs-Frameworks bieten Lastausgleich auf Ebene 4 (Transport). Service Mesh implementiert einen komplexeren Lastausgleich auf Schicht 7 (Anwendungsebene), ist reich an Algorithmen und effektiver bei der Verwaltung des Datenverkehrs. Die Lastausgleichseinstellungen können mithilfe der API geändert werden, sodass Sie Blue-Green- oder Canary-Bereitstellungen orchestrieren können.
- Шифрование. Service Mesh kann Anfragen und Antworten verschlüsseln und entschlüsseln und so die Dienste entlasten. Service Mesh kann auch die Leistung verbessern, indem vorhandene dauerhafte Verbindungen priorisiert oder wiederverwendet werden, wodurch der Bedarf an teuren Berechnungen zum Erstellen neuer Verbindungen verringert wird. Die gebräuchlichste Implementierung der Verkehrsverschlüsselung ist gegenseitiges TLS (mTLS), wo eine Public-Key-Infrastruktur (PKI) Zertifikate und Schlüssel zur Verwendung durch Sidecar Proxy generiert und verteilt.
- Authentifizierung und Autorisierung. Das Service Mesh kann Anfragen von außerhalb oder innerhalb der Anwendung autorisieren und authentifizieren und nur validierte Anfragen an Instanzen senden.
- Unterstützung für automatische Abschaltmuster. Service Mesh unterstützt , wodurch fehlerhafte Instanzen isoliert und bei Bedarf schrittweise in den Pool fehlerfreier Instanzen zurückgeführt werden.
Der Teil einer Service Mesh-Anwendung, der den Netzwerkverkehr zwischen Instanzen verwaltet, wird aufgerufen Datenebene. Erstellen und implementieren Sie eine Konfiguration, die das Verhalten steuert Datenebene, wird mit einem separaten durchgeführt Steuerebene. Steuerebene umfasst typischerweise eine Verbindung zu einer API, CLI oder GUI oder ist für die Verbindung mit dieser konzipiert, um die Anwendung zu steuern.
Die Control Plane im Service Mesh verteilt die Konfiguration zwischen dem Sidecar Proxy und der Data Plane.
Die Service-Mesh-Architektur wird häufig zur Lösung komplexer Betriebsprobleme mithilfe von Containern und Microservices eingesetzt. Pioniere auf diesem Gebiet sind Unternehmen wie Lyft, Netflix und Twitter, die Millionen von Nutzern auf der ganzen Welt stabile Dienste bieten. (). Für weniger anspruchsvolle Anwendungen werden wahrscheinlich einfachere Architekturen ausreichen.
Es ist unwahrscheinlich, dass die Service-Mesh-Architektur jemals die Antwort auf alle Probleme beim Betrieb und der Bereitstellung von Anwendungen sein wird. Architekten und Entwickler verfügen über ein riesiges Arsenal an Werkzeugen, und nur eines davon ist ein Hammer, der neben vielen Aufgaben nur eine lösen muss – das Hämmern von Nägeln. umfasst beispielsweise mehrere unterschiedliche Modelle, die ein Kontinuum von Ansätzen zur Problemlösung mithilfe von Microservices bieten.
Die Elemente, die in einer Service Mesh-Architektur zusammenkommen, wie NGINX, Container, Kubernetes und Microservices als Architekturansatz, können in Nicht-Service Mesh-Implementierungen gleichermaßen produktiv sein. Istio beispielsweise wurde als vollständige Service-Mesh-Architektur konzipiert, aber seine Modularität bedeutet, dass Entwickler nur die Technologiekomponenten auswählen und implementieren können, die sie benötigen. Vor diesem Hintergrund ist es wichtig, ein klares Verständnis des Service Mesh-Konzepts zu entwickeln, auch wenn Sie nicht sicher sind, ob Sie es jemals vollständig in Ihrer Anwendung implementieren können.
Source: habr.com