Was ist ein Service Mesh?

Einführung in Service Mesh

Service Mesh ist eine konfigurierbare Infrastruktur, die zur Verwaltung der Kommunikation zwischen Diensten in Microservice-Systemen verwendet wird. Es zielt darauf ab, den Verkehr zwischen Microservices, auch bekannt als East-West-Verkehr, zu verarbeiten.

In Cloud-nativen Anwendungen kann eine Anwendung aus Hunderten von Diensten bestehen. Jeder Dienst könnte mehrere Instanzen haben, und jede dieser Instanzen könnte sich ständig ändern. In einer solch komplexen Laufzeitumgebung ist es eine große Herausforderung, den Benutzern einen zuverlässigen Zugang zu bieten und die Dienste stabil am Laufen zu halten. Daher wurde eine Lösung namens Service Mesh entwickelt.

Service Mesh ist wie das TCP/IP zwischen Microservices, das dienstübergreifende Funktionen wie Netzwerkaufrufe, Rate Limiting, Überwachung usw. handhabt. Wir wenden Service Mesh hauptsächlich auf der Kubernetes-Plattform an. Außerdem ist das klassischste Muster das sogenannte Sidecar, das einige allgemeine Funktionen in den Sidecar-Container abstrahiert und ihn zusammen mit dem Dienstcontainer in denselben Pod einbindet. Das folgende Bild zeigt, warum es Service Mesh genannt wird.

Sidecar ist nicht das einzige Muster, das Service Mesh anwendet; neben diesem gibt es noch das DaemonSet-Muster und das Ambient Mesh-Muster:

• Der Unterschied zwischen dem DaemonSet-Muster und dem Sidecar-Muster besteht darin, dass das DaemonSet-Muster nur zulässt, dass jeder Knoten im Kubernetes-Cluster einen Pod ausführt, und dieser Pod als Sidecar-Proxy fungiert. Im Vergleich zum Sidecar-Muster verbraucht das DaemonSet-Muster viel weniger Maschinenressourcen, hat jedoch Nachteile wie schlechte Isolation, schwer vorhersehbare Ressourcenaufrufe usw. Weitere Unterschiede finden Sie in diesem Artikel: Sidecars und DaemonSets: Der Kampf der Containerisierungsmuster.

• Ambient Mesh ist ein neuer Datenebenenmodus, der von Istio am 7. September 2022 eingeführt wurde. Um das Kopplungsproblem der Mesh-Infrastruktur und -Bereitstellung zu lösen, trennt Ambient Mesh den Datenebenen-Proxy vom Anwendungs-Pod, sodass er separat bereitgestellt werden kann.

Ambient Mesh teilt die Datenebene in eine sichere Overlay-Schicht und eine L7-Verarbeitungsschicht auf: Die sichere Overlay-Schicht handhabt Funktionen wie TCP-Routing, Überwachungsmetriken, Zugriffsprotokollierung, mTLS-Tunneling; zusätzlich zu allen Funktionen der sicheren Overlay-Schicht hat die L7-Verarbeitungsschicht noch viele weitere Funktionen wie Verkehrskontrolle über HTTP-Routing, Beobachtbarkeit und erreicht reichhaltige L7-Autorisierungsrichtlinien.

Darüber hinaus verwendet Ambient Mesh einen gemeinsamen Agenten namens ztunnel (Zero-Trust-Tunnel), der auf jedem Knoten innerhalb des Kubernetes-Clusters läuft und die Workloads innerhalb des Mesh sicher verbindet und authentifiziert. Wenn Sie mehr über den Ambient Mesh-Modus erfahren möchten, können Sie diesen Artikel lesen: Einführung in Ambient Mesh

Warum brauchen wir Service Mesh?

Bevor Service Mesh populär wurde, wurde die Dienstverwaltung vieler Microservice-Architekturen durch die Zusammenarbeit des Microservice-Frameworks mit der Kontrollplattform erreicht. Diese Methode hat jedoch folgende Probleme:

1. Enge Kopplung zwischen Framework und Dienst, wodurch die Wartungsschwierigkeiten und die Komplexität insgesamt sehr hoch werden. Außerdem müssen Entwickler öffentliche Bibliotheken verstehen, was sie daran hindert, sich auf die Implementierung von Diensten zu konzentrieren.
2. Es muss ein mehrsprachiges Framework gewartet werden, was die Wartungskosten erhöht.
3. Microservices haben hohe Upgrade-Kosten, und während des Upgrades muss der Dienst meist neu gestartet werden.
4. Es gibt Frameworks mit vielen verschiedenen Online-Versionen, was die Berücksichtigung komplexer Kompatibilität erfordert.

Um diese Probleme zu lösen, schlug der ehemalige Twitter-Ingenieur Willian Morgan, einer der Gründer von Linkerd, das Konzept des "Service Mesh" vor. Service Mesh verwendet ein Sidecar-Muster, um die Infrastruktur von der Dienstlogik zu entkoppeln, ohne die Anwendung zu beeinträchtigen, was eine sprachunabhängige Aktualisierung und O&M ermöglicht.

Service Mesh verlagert Funktionen wie Verkehrskontrolle, Beobachtbarkeit und sichere Kommunikation in die Basiskomponenten; somit müssen sich Entwickler nicht um die konkrete Implementierung der Kommunikationsschicht und der Dienstverwaltung kümmern. Entwickler können die ganze schmutzige Arbeit im Zusammenhang mit der Kommunikation dem Service Mesh überlassen und sich auf die Dienstentwicklung konzentrieren. Basierend auf diesen Merkmalen kann Service Mesh uns helfen, die zuvor erwähnten Probleme zu lösen.

Wie funktioniert Service Mesh?

Service Mesh fügt der Laufzeitumgebung der Anwendung keine neuen Funktionen hinzu, daher benötigen alle Anwendungen innerhalb eines Frameworks weiterhin entsprechende Regeln, um festzulegen, wie Anfragen von A nach B gesendet werden. Der Unterschied besteht darin, dass Service Mesh die dienstübergreifende Kommunikation der Logikverwaltung extrahiert und sie dann in eine Infrastrukturschicht abstrahiert.

Derzeit verwenden die meisten Service Meshes die Architektur der Datenebene + Kontrollebene, die wie folgt aussieht:

Die Kontrollebene

Die Kontrollebene verwaltet und konfiguriert die Datenebene und führt Strategien während des Dienstbetriebs aus. Alle Instanzen innerhalb der Kontrollebene eines einzelnen Service Mesh teilen sich dieselben Konfigurationsressourcen.

Die Kontrollebene konzentriert sich mehr auf die Bereitstellung und Strategien wie Sicherheit, Beobachtbarkeit und Verkehrskontrolle. Sie sammelt auch Telemetriedaten der Datenebene, damit DevOps sie verwenden können.

Die Datenebene

Die Datenebene fungiert normalerweise als Proxy und besteht aus vielen Sidecar-Proxies. Sidecar läuft parallel zu den Dienstinstanzen und kontrolliert den Datenverkehr der Dienstanwendung, indem er den Dienstdatenfluss abfängt.

Wie bereits erwähnt, wird das Service Mesh durch die Implementierung eines Sidecar-Musters in Kubernetes und dessen Verpackung als Container erreicht. Sidecar schlägt vor, einen zusätzlichen Container zu verwenden, um den Hauptcontainer zu erweitern und zu verstärken, und dieser zusätzliche Container wird als Sidecar-Container bezeichnet, der im selben Pod wie der Dienstcontainer platziert wird. Andererseits ist das Service Mesh ein vermaschtes Netzwerk, das aus diesen Sidecar-Proxies besteht.

Anwendungen von Service Mesh

In der Microservice-Architektur verschlüsseln Ingenieure normalerweise öffentlich zugängliche Dienste oder beschränken den Zugriff, um den Dienst zu schützen, aber sie ignorieren die Kommunikationssicherheit innerhalb von Clustern. Bis heute fehlt vielen Microservice-Anwendungen die Verschlüsselung der dienstübergreifenden Kommunikation, und der interne Verkehr des Clusters wird sogar im Rohdatenformat übertragen. Dadurch ist der interne Verkehr sehr anfällig für Lauschangriffe und MITM (Man-in-the-Middle-Angriffe).

Um Angriffe auf den internen Verkehr des Clusters zu vermeiden, verwenden wir mTLS, um die Verkehrsdaten zu verschlüsseln. mTLS kann die Kommunikationssicherheit zwischen Microservices innerhalb des Service Mesh sicherstellen. Es verwendet Verschlüsselungstechnologie, um jeden Microservice zu authentifizieren und den dienstübergreifenden Verkehr gegenseitig zu verschlüsseln.

Obwohl wir die Kommunikationssicherheitsstrategie direkt innerhalb des Microservice definieren und Identitäts-Authentifizierung und Verschlüsselung implementieren könnten, ist es immer noch sehr ineffizient, dieselbe Funktion in jedem einzelnen Microservice individuell zu implementieren. Das Hinzufügen einer neuen Funktion erfordert die Änderung des Dienstcodes und die Invasion der Dienstlogik. Darüber hinaus erfordern auch bei erfolgreicher Implementierung der neuen Funktion spätere Iterationen, Upgrades und Tests, dass Entwickler mehr Zeit für die Wartung aufwenden. Daher können sich Entwickler nicht auf die Entwicklung der Dienstfunktion konzentrieren.

Stattdessen können wir, wenn wir Service Mesh verwenden, mTLS-Kommunikation bereitstellen, ohne dass der ursprüngliche Dienst davon Kenntnis haben muss. Daher verlagern wir im Service Mesh alle kommunikationsbezogenen Funktionen in Sidecar-Proxies.

Wenn zwei Microservices kommunizieren müssen, baut der Sidecar-Proxy zunächst eine mTLS-Verbindung auf und sendet verschlüsselten Verkehr über diese mTLS-Verbindung. Sidecar wechselt Zertifikate und authentifiziert sich gegenseitig durch die Zertifizierungsstelle. Vor der Verbindung prüft der Sidecar die von der Kontrollebene gesendete Authentifizierungsstrategie, um festzustellen, ob die Kommunikation zwischen den Microservices erlaubt ist. Wenn die Kommunikation erlaubt ist, verwendet der Sidecar den generierten Kommunikationsschlüssel, um sichere Verbindungen aufzubauen und die Kommunikationsdaten zwischen den Microservices zu verschlüsseln. Während des gesamten Prozesses werden die Dienstanwendungen nicht beeinträchtigt, wodurch die Belastung der Entwickler verringert wird.

Anhand dieses Szenarios kann jeder verstehen, warum Service Mesh aktuelle Funktionen erweitern kann, ohne den aktuellen Dienst zu beeinträchtigen. Natürlich kann Service Mesh, abgesehen von der Implementierung von Funktionen wie der internen Verkehrssicherheitskonfiguration, die mTLS ähnlich ist, auch schnell Funktionen wie Verkehrskontrolle, Beobachtbarkeit und Codec-Protokoll durch Änderung der Konfiguration der Kontrollebene erweitern.

Fazit

Dieser Artikel führt kurz in die Grundkonzepte des Service Mesh, seine Funktionsweise und die Vorteile, die es uns bringt, ein. Service Mesh revolutioniert die Microservice-Architektur und hilft Entwicklern, sich von der komplexen Microservice-Laufzeitumgebung zu befreien, um sich auf die Entwicklung von Dienstfunktionen zu konzentrieren.

Obwohl Service Mesh viele Schmerzpunkte in der Microservice-Architektur löst, hat es immer noch Einschränkungen. Die Komplexität der Softwareentwicklung ist ewig und wird nur von einem Teil auf einen anderen übertragen. Wenn wir die Dienstverwaltung in eine separate Schicht abstrahieren, müssen wir uns zusätzlichen O&M-Schwierigkeiten und einer Zunahme der Verkehrsverbindungen stellen. Darüber hinaus muss Service Mesh in einer Cloud-nativen Umgebung verwendet werden, was die professionellen Fähigkeiten und die technische Erfahrung von DevOps erhöht. Deshalb sagen wir, Technologie ist nur ein Werkzeug zur Problemlösung, aber wir müssen die Vorteile, die Service Mesh bringt, nach seiner praktischen Anwendung abwägen.

Mit der explosiven Entwicklung von Cloud-nativen Technologien und der Optimierung des Service Mesh wird Service Mesh wahrscheinlich in Zukunft die Microservice-Architektur vollständig ersetzen und zur ersten Wahl für die Microservice- und Cloud-native-Rebuild-Architektur jedes Unternehmens werden.

Wenn Sie mehr über API-Management erfahren möchten, kontaktieren Sie uns jederzeit: https://api7.ai/contact.