Architecture d’applications conteneur et basées sur des microservices
Conseil
Ce contenu est un extrait du livre électronique « .NET Microservices Architecture for Containerized .NET Applications », disponible sur .NET Docs ou sous forme de PDF téléchargeable gratuitement et pouvant être lu hors ligne.
Si les microservices offrent de nombreux avantages, ils soulèvent aussi de nouveaux problèmes de taille. Les modèles d’architecture des microservices sont les piliers fondamentaux de la création d’une application basée sur des microservices.
Plus haut dans ce guide, vous avez découvert les concepts de base des conteneurs et de Docker. Ces informations constituaient le minimum à savoir pour commencer à utiliser des conteneurs. Même si les conteneurs sont des facilitateurs parfaitement adaptés aux microservices, ils ne sont pas obligatoires pour une architecture de microservice. De nombreux concepts architecturaux décrits dans cette section pourraient être appliqués sans conteneurs. Toutefois, ce guide porte sur l’intersection des deux en raison de l’importance déjà évoquée des conteneurs.
Les applications d’entreprise peuvent être complexes et sont souvent composées non pas d’un mais de plusieurs services. En pareils cas, vous devez comprendre d’autres approches architecturales, telles que les microservices et certains modèles de conception déterminée par le domaine (DDD), ainsi que les concepts de l’orchestration de conteneurs. Notez que ce chapitre concerne non seulement les microservices présents dans les conteneurs, mais aussi n’importe quelle application en conteneur.
Principes de conception basée sur des conteneurs
Dans le modèle à base de conteneurs, une instance d’image de conteneur représente un processus unique. En définissant une image de conteneur en tant que limite de processus, vous pouvez créer des primitives utilisables pour mettre à l’échelle ou traiter par lots le processus.
Quand vous concevez une image de conteneur, vous constaterez que le fichier Dockerfile contient une définition ENTRYPOINT. Celle-ci 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 prend fin. Les conteneurs peuvent représenter des processus de longue durée comme des serveurs web, mais peuvent aussi représentent des processus de courte durée comme les programmes de traitement par lots, qui auraient pu auparavant être implémentés comme des tâches web Azure WebJobs.
Si le processus échoue, le conteneur prend fin et l’orchestrateur prend le contrôle. Si l’orchestrateur a été configuré pour maintenir cinq instances en exécution et qu’une défaillance touche l’une d’elles, l’orchestrateur crée une autre instance de conteneur pour remplacer le processus défaillant. Dans un programme de traitement par lots, le processus démarre avec des paramètres. Quand le processus prend fin, le travail est terminé. Ces considérations s’attachent ultérieurement plus en détails aux orchestrateurs.
Le cas peut se présenter où vous voulez que plusieurs processus s’exécutent dans un même conteneur. Pour ce scénario, comme 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 le nombre de programmes voulu. Par exemple, vous pouvez utiliser Supervisor ou un outil similaire pour prendre en charge le lancement de plusieurs processus à l’intérieur d’un même conteneur. Toutefois, même s’il existe des architectures qui contiennent plusieurs processus par conteneur, cette approche n’est pas très courante.