Architecture du pattern Sidecar pour microservices

Diagramme d'architecture du pattern sidecar montrant le proxy Envoy, le collecteur de logs et le watcher de configuration fonctionnant aux côtés des conteneurs applicatifs dans un pod Kubernetes, avec un plan de contrôle gérant la configuration. Ce modèle démontre comment les préoccupations auxiliaires comme la journalisation, la surveillance et la configuration sont déployées en tant que conteneurs co-localisés. Fondamental pour les équipes adoptant des patterns d'orchestration de conteneurs cloud-native.

Télécharger le fichier .fz

Code FlowZap complet

ControlPlane { # Control Plane
n1: rectangle label:"Service Mesh Control Plane"
n2: rectangle label:"Push Configuration"
n3: rectangle label:"Certificate Authority"
n15: rectangle label:"Receive Config Ack"
n16: rectangle label:"Config Confirmed"
n1.handle(right) -> n2.handle(left) [label="Policy"]
n2.handle(bottom) -> Pod.n4.handle(top) [label="xDS Config"]
n3.handle(bottom) -> Pod.n4.handle(top) [label="mTLS Cert"]
n15.handle(right) -> n16.handle(left)
}
Pod { # Kubernetes Pod
n4: rectangle label:"Envoy Sidecar Proxy"
n5: rectangle label:"Config Watcher Sidecar"
n6: rectangle label:"Application Container"
n7: rectangle label:"Log Collector Sidecar"
n8: rectangle label:"Send Log Batch"
n13: rectangle label:"Receive Log Ack"
n14: rectangle label:"Acknowledge Config"
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Config Applied"]
n6.handle(right) -> n7.handle(left) [label="Logs"]
n7.handle(right) -> n8.handle(left)
n8.handle(bottom) -> Observability.n9.handle(top) [label="Ship Logs"]
n13.handle(right) -> n14.handle(left)
n14.handle(top) -> ControlPlane.n15.handle(bottom) [label="Config Ack"]
}
Observability { # Observability Stack
n9: rectangle label:"ELK Log Aggregation"
n10: rectangle label:"Prometheus Metrics"
n11: rectangle label:"Jaeger Tracing"
n12: rectangle label:"Return Log Ack"
n9.handle(right) -> n10.handle(left)
n10.handle(right) -> n11.handle(left) [label="Traces"]
n11.handle(right) -> n12.handle(left)
n12.handle(top) -> Pod.n13.handle(bottom) [label="Logs Received"]
}

Pourquoi ce workflow ?

Cross-cutting concerns like logging, monitoring, and configuration management clutter application code and vary across programming languages. The sidecar pattern deploys these concerns as separate containers co-located with the application, providing language-agnostic infrastructure capabilities without modifying business logic.

Comment ça fonctionne

Step 1: The application container and sidecar containers are deployed together in a Kubernetes pod.
Step 2: The Envoy sidecar proxy intercepts all network traffic for mTLS and load balancing.
Step 3: The log collector sidecar ships application logs to the centralized logging system.
Step 4: The config watcher sidecar monitors configuration changes and updates the application.
Step 5: The control plane pushes policy updates and certificates to sidecar proxies.
Step 6: The observability stack collects metrics, traces, and logs from all sidecars.

Alternatives

Embedding these concerns in application libraries creates language-specific maintenance burden. DaemonSets handle node-level concerns but not pod-level isolation. This template shows the pod-level sidecar approach used by service meshes.

Key Facts

Template Name	Architecture du pattern Sidecar pour microservices
Category	Architecture
Steps	6 workflow steps
Format	FlowZap Code (.fz file)

Modèles associés

Architecture d'orchestration de conteneurs Kubernetes

Diagramme d'architecture d'orchestration de conteneurs Kubernetes montrant le plan de contrôle (API Server, etcd, Scheduler, Controller Manager), les nœuds worker (Kubelet, runtime de conteneurs, kube-proxy, pods), la couche réseau (Ingress, Network Policy, Service Mesh) et le stockage persistant avec pilotes CSI. Ce modèle fournit une vue complète de la pile architecturale Kubernetes du plan de contrôle à la couche de stockage. Référence fondamentale pour les ingénieurs DevOps et les équipes plateforme gérant des clusters Kubernetes.

Voir le modèle

Architecture d'observabilité des trois piliers

Diagramme d'architecture d'observabilité implémentant les trois piliers (métriques, traces, logs) avec instrumentation SDK OpenTelemetry, pipeline de collecteur OTLP, backends Prometheus, Jaeger et Loki, tableaux de bord Grafana, suivi SLO/SLI et intégration d'alertes PagerDuty. Ce modèle fournit une référence complète de pile d'observabilité montrant comment les données de télémétrie circulent de l'instrumentation applicative à la collecte, au stockage, à la visualisation et à la réponse aux incidents. Essentiel pour les équipes SRE construisant une infrastructure de surveillance de production.

Voir le modèle

Architecture de passerelle API pour microservices

Diagramme d'architecture de passerelle API pour microservices montrant le routage des requêtes, l'authentification JWT, la limitation de débit, la découverte de services et l'agrégation des réponses à travers des services backend distribués. Ce modèle représente le point d'entrée de tout le trafic client dans un écosystème de microservices, appliquant les politiques de sécurité avant que les requêtes n'atteignent les services internes. Idéal pour les ingénieurs plateforme concevant une infrastructure API évolutive avec des préoccupations transversales centralisées.

Voir le modèle

Architecture de maillage de services pour microservices

Diagramme d'architecture de maillage de services avec proxys sidecar Istio ou Linkerd gérant le chiffrement mTLS, les politiques de trafic, le disjoncteur et le traçage distribué à travers les microservices. Ce modèle visualise comment un maillage de services abstrait les préoccupations réseau du code applicatif, permettant une communication zero-trust entre les services. Essentiel pour les équipes adoptant une infrastructure de maillage de services pour améliorer l'observabilité et la sécurité.

Voir le modèle

Architecture base de données par service pour microservices

Diagramme d'architecture base de données par service où chaque microservice possède son propre magasin de données dédié, avec synchronisation événementielle via Kafka pour la cohérence des données inter-services. Ce modèle démontre le principe fondamental d'isolation des données des microservices, montrant comment PostgreSQL et MongoDB coexistent dans une stratégie de persistance polyglotte. Critique pour les architectes imposant l'autonomie des services tout en maintenant la cohérence à terme.

Voir le modèle

Décomposition de microservices par capacité métier

Diagramme d'architecture de décomposition de microservices organisé par capacités métier : Identité, Catalogue produits, Tarification et Exécution des commandes, chacun avec des magasins de données et des API indépendants. Ce modèle montre comment découper un monolithe en services alignés sur les domaines métier, en utilisant un pattern Backend-for-Frontend (BFF) pour l'agrégation spécifique au client. Utile pour les architectes planifiant les frontières de microservices orientées domaine.

Voir le modèle

Retour à tous les modèles