Sidecar-Muster

Stellen Sie Anwendungskomponenten in einem Prozess oder Container getrennt von der Hauptanwendung bereit, um Isolation und Kapselung bereitzustellen. Mit diesem Muster können Sie Anwendungen aus verschiedenen Komponenten und Technologien erstellen.

Wie ein Motorrad-Sidecar befestigen sich diese Komponenten an der übergeordneten Anwendung und teilen deren Lebenszyklus, sodass Sie sie zusammen erstellen und entfernen. Dieses Muster wird auch als Sidekick-Muster bezeichnet und unterstützt die Anwendungskomposition.

Kontext und Problem

Anwendungen und Dienste erfordern häufig verwandte Funktionen wie Überwachung, Protokollierung, Konfiguration und Netzwerkdienste. Sie können diese Peripherieaufgaben als separate Komponenten oder Dienste implementieren.

Eng aneinander gekoppelte Komponenten werden im selben Prozess ausgeführt und verwenden gemeinsame Ressourcen effizient, es fehlt jedoch an Isolation. Ein Ausfall in einer Komponente kann sich auf die gesamte Anwendung auswirken. Außerdem ist eine Implementierung in der Sprache der übergeordneten Anwendung erforderlich, die eine Interdependenz erzeugt.

Wenn Sie die Anwendung in Dienste dekompilieren, können Sie jeden Dienst mithilfe verschiedener Sprachen und Technologien erstellen. Dieser Ansatz bietet mehr Flexibilität. Jede Komponente verfügt jedoch über eigene Abhängigkeiten und erfordert sprachspezifische Bibliotheken für den Zugriff auf die Plattform und gemeinsam genutzte Ressourcen. Wenn Sie diese Features als separate Dienste bereitstellen, fügen Sie Latenz hinzu. Sprachspezifischer Code und Abhängigkeiten erhöhen auch die Komplexität für Hosting und Bereitstellung.

Lösung

Stellen Sie einen zusammenhängenden Satz von Aufgaben zusammen mit der primären Anwendung in einem separaten Prozess oder Container bereit. Dieser Ansatz bietet eine einheitliche Schnittstelle für Plattformdienste in allen Sprachen.

Das Diagramm zeigt die primäre Anwendung und das Sidecar, die miteinander verbunden sind. Die Anwendung übernimmt die Kernfunktionen, während das Sidecar Peripherieaufgaben wie Plattformabstraktion, Proxy für Remotedienste, Protokollierung und Konfiguration verarbeitet. Sowohl die Anwendung als auch das Sidecar befinden sich in einem Host.

Ein Sidecar-Dienst stellt eine Verbindung mit der Anwendung her, ohne Teil von ihr zu sein, und wird nebeneinander bereitgestellt. Jede Anwendungsinstanz erhält eine eigene Sidecar-Instanz, die ihren Lebenszyklus teilt.

Das Sidecar-Muster bietet die folgenden Vorteile:

• Sprachunabhängigkeit: Das Sidecar wird unabhängig von der Laufzeitumgebung und Programmiersprache der primären Anwendung ausgeführt. Sie können eine Sidecar-Implementierung für anwendungen verwenden, die in verschiedenen Sprachen geschrieben wurden.

• Zugriff auf freigegebene Ressourcen: Der Sidecar kann auf die gleichen Ressourcen wie die Hauptanwendung zugreifen. Beispielsweise kann das Sidecar Systemressourcen überwachen, die beide Komponenten verwenden.

• Geringe Latenz: Die Nähe des Sidecars zur primären Anwendung minimiert die Kommunikationslatenz.

• Erweiterte Erweiterbarkeit: Sie können Anwendungen erweitern, bei denen systemeigene Erweiterbarkeitsmechanismen fehlen, indem Sie ein Sidecar als separaten Prozess auf demselben Host oder Untercontainer anfügen.

Die am häufigsten verwendete Implementierung dieses Musters verwendet Container, die auch als Sidecarcontainer oder Sidekickcontainer bezeichnet werden.

Probleme und Überlegungen

Berücksichtigen Sie beim Implementieren dieses Musters die folgenden Punkte:

• Berücksichtigen Sie das Bereitstellungs- und Verpackungsformat zum Bereitstellen von Diensten, Prozessen oder Containern. Container funktionieren gut für das Sidecar-Muster.

• Wenn Sie einen Sidecar-Dienst entwerfen, wählen Sie sorgfältig den Interprozesskommunikationsmechanismus aus. Verwenden Sie sprachagnostische oder frameworkagnostische Technologien, es sei denn, Leistungsanforderungen machen diesen Ansatz unpraktisch.

• Bevor Sie einem Sidecar Funktionen hinzufügen, bewerten Sie, ob es besser als separater Dienst oder herkömmlicher Daemon funktioniert.

• Überlegen Sie, ob Sie die Funktionalität als Bibliothek oder über einen herkömmlichen Erweiterungsmechanismus implementieren möchten. Sprachspezifische Bibliotheken bieten eine tiefere Integration und weniger Netzwerkaufwand.

Wann dieses Muster verwendet werden soll

Verwenden Sie dieses Muster in folgenden Fällen:

• Ihre primäre Anwendung verwendet verschiedene Sprachen und Frameworks. Sidecars bieten eine konsistente Schnittstelle, die verschiedene Anwendungen unabhängig von ihrer Sprache oder ihrem Framework verwenden können.

• Ein separater Team- oder externer Partner besitzt eine Komponente.

• Sie müssen eine Komponente oder ein Feature auf demselben Host wie die Anwendung bereitstellen.

• Sie benötigen einen Dienst, der den gesamten Lebenszyklus Ihrer Hauptanwendung teilt, den Sie jedoch unabhängig aktualisieren können.

• Für eine bestimmte Ressource oder Komponente benötigen Sie eine differenzierte Kontrolle über Ressourcengrenzwerte. Sie können beispielsweise eine Komponente als Sidecar bereitstellen, um die Speicherauslastung unabhängig von der Hauptanwendung einzuschränken und zu verwalten.

Dieses Muster ist möglicherweise nicht geeignet, wenn:

• Sie müssen die Interprozesskommunikation optimieren. Sidecars fügen Mehraufwand hinzu, insbesondere Latenz, wodurch sie für Anwendungen mit häufiger Kommunikation zwischen Komponenten ungeeignet sind.

• Ihre Anwendung ist klein. Die Ressourcenkosten für die Bereitstellung eines Sidecars für jede Instanz könnte die Isolationsvorteile übersteigen.

• Sie müssen die Komponente unabhängig skalieren. Wenn Sie die Komponente anders als die Hauptanwendung skalieren müssen, stellen Sie sie stattdessen als separater Dienst bereit.

• Ihre Plattform bietet gleichwertige Funktionen. Wenn Ihre Anwendungsplattform bereits die erforderlichen Funktionen nativ bereitstellt, fügen Sidecars unnötige Komplexität hinzu.

Workloadentwurf

Bewerten Sie die Verwendung des Sidecar-Musters im Entwurf einer Workload, um die in den Azure Well-Architected Framework-Säulen behandelten Ziele und Prinzipien zu erfüllen. Die folgende Tabelle enthält Anleitungen dazu, wie dieses Muster die Ziele jeder Säule unterstützt.

Säule	So unterstützt dieses Muster die Säulenziele
Sicherheitsdesignentscheidungen tragen dazu bei, die Vertraulichkeit, Integrität und Verfügbarkeit der Daten und Systeme Ihrer Workload sicherzustellen.	Wenn Sie diese Aufgaben kapseln und in separaten Prozessen bereitstellen, reduzieren Sie die Angriffsfläche auf den erforderlichen Code. Sie können Sidecars auch verwenden, um übergreifende Sicherheitskontrollen zu Anwendungskomponenten hinzuzufügen, die keine systemeigene Unterstützung für diese Features bieten. - SE:04 Segmentierung - SE:07 Verschlüsselung
Operational Excellence unterstützt die Arbeitsauslastungsqualität durch standardisierte Prozesse und Teamzusammenhalt.	Mit diesem Muster können Sie Observability-Tools flexibel integrieren, ohne Dem Anwendungscode Abhängigkeiten hinzuzufügen. Sie können das Sidecar unabhängig von der Anwendung aktualisieren und pflegen. - OE:04 Tools und Prozesse - OE:07 Überwachungssystem
Performance Efficiency hilft Ihrem Workload durch Optimierungen bei Skalierung, Daten und Code, die Anforderungen effizient zu erfüllen .	Mit diesem Muster können Sie querschnittliche Aufgaben in Sidecars zentralisieren, die über mehrere Anwendungsinstanzen hinweg skaliert werden. Sie müssen keine doppelten Funktionen für jede Anwendungsinstanz bereitstellen. - PE:07-Code und -Infrastruktur

Wenn dieses Muster Kompromisse innerhalb einer Säule einführt, sollten Sie sie gegen die Ziele der anderen Säulen berücksichtigen.

Example

Sie können das Sidecar-Muster auf viele Szenarien anwenden. Betrachten Sie die folgenden Beispiele:

• Abstraktion von Abhängigkeiten: Stellen Sie einen benutzerdefinierten Dienst zusammen mit jeder Anwendung bereit, um den Zugriff auf freigegebene Abhängigkeitsfunktionen über eine konsistente API bereitzustellen. Dieser Ansatz ersetzt sprachspezifische Clientbibliotheken durch ein Sidecar, das Probleme wie Protokollierung, Konfiguration, Dienstermittlung, Zustandsverwaltung und Integritätsprüfungen behandelt.

  Der Distributed Application Runtime (Dapr)-Sidecar veranschaulicht diesen Anwendungsfall.

• Service Mesh Data Plane: Stellen Sie einen Sidecar-Proxy neben jeder Dienstinstanz bereit, um übergreifende Netzwerkaufgaben wie Traffic-Routing, Wiederholungsversuche, gegenseitiges Transport Layer Security (mTLS), Richtliniendurchsetzung und Telemetrie zu bearbeiten.

  Dienstgitter wie Istio verwenden Sidecar-Proxys, um diese Funktionen zu implementieren, ohne dass Änderungen am Anwendungscode erforderlich sind.

• Ambassador Sidecar: Stellen Sie einen Ambassador-Dienst als Sidecar bereit. Die Anwendung leitet Aufrufe über den Ambassador weiter, der das Request-Logging, das Routing, das Circuit Breaking und andere Konnektivitätsfunktionen verarbeitet.

• Protokolladapter: Stellen Sie ein Sidecar bereit, um zwischen inkompatiblen Protokollen oder Datenformaten zu übersetzen, oder um Messagingsysteme zu überbrücken. Mit diesem Ansatz kann die Anwendung einfachere oder ältere Schnittstellen verwenden.

• Telemetrieanreicherung: Stellen Sie ein Sidecar bereit, um Telemetriedaten wie Metriken, Protokolle und Ablaufverfolgungen vorzuverarbeiten oder anzureichern, bevor die Daten an externe Überwachungssysteme weitergeleitet werden. Komponenten wie der OpenTelemetry Collector können als Sidecars ausgeführt werden, um Telemetrie separat von der Anwendung zu normalisieren, zu erweitern oder zu leiten.

Nächste Schritte

• Microservice-APIs, die Dapr verwenden: Erfahren Sie, wie Azure Container-Apps Dapr-Sidecars verwenden, um einfache, tragbare, robuste und sichere Microservices zu erstellen.

• Nativer Sidecar-Modus für istio-basiertes Dienstgitterfeature in Azure Kubernetes Service (AKS):Erfahren Sie, wie das Istio-Dienstgitterfeature für AKS das Sidecar-Muster verwendet, um verteilte Architekturprobleme zu bewältigen.

Verwandte Ressource

• Botschaftermuster