Architecture d’applications basées sur des conteneurs et des microservices

Conseil / Astuce

Ce contenu est un extrait du livre électronique 'Architecture des microservices .NET pour les applications .NET conteneurisées', disponible sur .NET Docs ou en tant que PDF téléchargeable gratuitement, lisible hors ligne.

Télécharger le PDF

Les microservices offrent de grands avantages, mais soulèvent également de nouveaux défis énormes. Les modèles d’architecture de microservice sont des piliers fondamentaux lors de la création d’une application basée sur un microservice.

Plus haut dans ce guide, vous avez découvert des concepts de base sur les conteneurs et Docker. Ces informations étaient le minimum nécessaire pour commencer à utiliser des conteneurs. Même si les conteneurs sont des outils d’activation et qu’ils conviennent parfaitement aux microservices, ils ne sont pas obligatoires pour une architecture de microservice. De nombreux concepts architecturaux de cette section d’architecture peuvent être appliqués sans conteneurs. Toutefois, ce guide se concentre sur l’intersection des deux en raison de l’importance déjà introduite des conteneurs.

Les applications d’entreprise peuvent être complexes et sont souvent composées de plusieurs services au lieu d’une application basée sur un seul service. Dans ce cas, vous devez comprendre d’autres approches architecturales, telles que les microservices et certains modèles Domain-Driven Conception (DDD), ainsi que des concepts d’orchestration de conteneur. Notez que ce chapitre décrit non seulement les microservices sur les conteneurs, mais également toute application conteneurisée.

Principes de conception de conteneur

Dans le modèle de conteneur, une instance d’image conteneur représente un processus unique. En définissant une image conteneur en tant que limite de processus, vous pouvez créer des primitives qui peuvent être utilisées pour mettre à l’échelle ou traiter le processus par lots.

Lorsque vous concevez une image conteneur, vous verrez une définition ENTRYPOINT dans le fichier Dockerfile. Cette définition définit le processus dont la durée de vie contrôle la durée de vie du conteneur. Une fois le processus terminé, le cycle de vie du conteneur se termine. Les conteneurs peuvent représenter des processus de longue durée comme des serveurs web, mais peuvent également représenter des processus de courte durée comme des travaux par lots, qui ont été précédemment implémentés en tant que WebJobs Azure.

Si le processus échoue, le conteneur se termine et l’orchestrateur prend le relais. Si l’orchestrateur a été configuré pour conserver cinq instances en cours d’exécution et qu’un échec échoue, l’orchestrateur crée une autre instance de conteneur pour remplacer le processus ayant échoué. Dans un travail de traitement par lots, le processus est démarré avec des paramètres. Une fois le processus terminé, le travail est terminé. Ces considérations s’attachent ultérieurement plus en détails aux orchestrateurs.

Vous pouvez trouver un scénario dans lequel vous souhaitez exécuter plusieurs processus dans un seul conteneur. Pour ce scénario, étant donné qu’il ne peut y avoir qu’un seul point d’entrée par conteneur, vous pouvez exécuter un script dans le conteneur qui lance autant de programmes que nécessaire. Par exemple, vous pouvez utiliser Superviseur ou un outil similaire pour prendre en charge le lancement de plusieurs processus à l’intérieur d’un seul conteneur. Toutefois, même si vous pouvez trouver des architectures qui contiennent plusieurs processus par conteneur, cette approche n’est pas très courante.

PrécédentSuivant