Styles d’architecture

Un style d’architecture est une famille d’architectures qui partagent certaines caractéristiques. Par exemple, multiniveau est un style d’architecture courant. Plus récemment, les architectures de microservices ont commencé à obtenir une place de choix. Les styles d’architecture ne nécessitent pas l’utilisation de technologies particulières, mais certaines technologies sont bien adaptées pour certaines architectures. Par exemple, les conteneurs sont naturellement adaptés aux microservices.

Nous avons identifié un ensemble de styles d’architecture qui sont couramment utilisés dans les applications cloud. L’article inclut pour chaque style :

  • Une description et un diagramme logique du style.
  • Des recommandations concernant le moment approprié pour choisir le style.
  • Les avantages, les défis et les meilleures pratiques.
  • Un déploiement recommandé à l’aide des services Azure appropriés.

Une présentation rapide des styles.

Cette section fournit une présentation rapide des styles d’architecture que nous avons identifiés, ainsi que certaines considérations de haut niveau pour leur utilisation. Obtenez plus de détails dans les rubriques associées.

Multiniveau

Diagramme logique d’un style d’architecture multiniveau.

Le multiniveau est une architecture classique pour les applications d’entreprise. Les dépendances sont gérées en divisant l’application en couches qui exécutent des fonctions logiques, telles que la présentation, la logique métier et l’accès aux données. Une couche ne peut appeler que des couches inférieures. Toutefois, cette superposition horizontale peut être une responsabilité. Il peut être difficile d’introduire des modifications dans une partie de l’application sans toucher le reste de l’application. Ainsi, les mises à jour fréquentes sont un défi, elles limitent la rapidité avec laquelle de nouvelles fonctionnalités peuvent être ajoutées.

L’architecture multiniveau convient parfaitement pour la migration d’applications existantes qui utilisent déjà une architecture en couches. Pour cette raison, l’architecture multiniveau est le plus souvent vue dans les solutions de type infrastructure as a service (IaaS), ou comme une application qui utilise une combinaison de IaaS et de services gérés.

Web-File d’attente-Worker

Diagramme logique du style d’architecture Web-File d’attente-Worker.

Pour une solution purement PaaS, envisagez une architecture Web-File d’attente-Worker . Dans ce style, l’application possède un serveur web frontal qui gère les requêtes HTTP et un Worker principal qui exécute les tâches sollicitant beaucoup le processeur ou les opérations longues. Le serveur frontal communique avec le Worker via une file d’attente de messages asynchrones.

L’architecture Web-File d’attente-Worker est adaptée aux domaines relativement simples avec certaines tâches gourmandes en ressources. Comme pour l’architecture multiniveau, cette architecture est facile à comprendre. L’utilisation de services gérés simplifie le déploiement et les opérations. Mais avec des domaines complexes, il peut être difficile de gérer les dépendances. Le serveur frontal et le Worker peuvent facilement devenir des composants monolithiques volumineux, difficiles à gérer et à mettre à jour. Comme avec l’architecture multicouche, cela peut réduire la fréquence des mises à jour et limiter l’innovation.

Microservices

Diagramme logique du style d’architecture de microservices.

Si votre application a un domaine plus complexe, envisagez de passer à une architecture de microservices . Une application de microservices est composée de nombreux services indépendants et de petite taille. Chaque service implémente une fonctionnalité unique. Les services sont faiblement couplés et communiquent via des contrats d’API.

Chaque service peut être généré par une équipe de développement petite et ciblée. Les services individuels peuvent être déployés sans beaucoup de coordination entre les équipes, ce qui permet des mises à jour fréquentes. Une architecture de microservices est plus complexe à créer et à gérer que les architectures multiniveau ou Web-File d’attente-Worker. Elle nécessite un développement mature et une culture DevOps. Mais bien mis en place, ce style peut libérer plus de rapidité, accélérer l’innovation et permettre une architecture plus résiliente.

Architecture basée sur les événements

Diagramme d’un style d’architecture basée sur les événements.

Les architectures basées sur les événements utilisent un modèle de publication-abonnement (pub-sub), où les producteurs publient des événements et les consommateurs s’y abonnent. Les producteurs sont indépendants des consommateurs et les consommateurs sont indépendants les uns des autres.

Envisagez une architecture basée sur les événements pour les applications qui reçoivent et traitent un gros volume de données avec une latence très faible, telles que les solutions IoT. Le style est également utile lorsque différents sous-systèmes doivent effectuer différents types de traitement sur les mêmes données d’événement.

Big Data et Big Compute

Diagramme logique d’un style d’architecture Big Data.

Big Data et Big Compute sont des styles d’architecture spécialisée pour les charges de travail qui correspondent à certains profils spécifiques. Le Big Data divise un très grand jeu de données en plusieurs blocs en exécutant un traitement parallèle sur l’ensemble du jeu de données à des fins d’analyse et de création de rapports. Big compute, également appelé High-Performance Computing, calcul haute performance (HPC), effectue des calculs parallèles sur un grand nombre (des milliers) de cœurs. Les domaines incluent des simulations, des modélisations et un rendu 3D.

Les styles d’architecture en tant que contraintes

Un style d’architecture implique des contraintes de conception, y compris l’ensemble d’éléments qui peuvent s’afficher et les relations autorisées entre ces éléments. Les contraintes encadrent la « forme » d’une architecture en limitant les choix possibles. Lorsqu’une architecture se conforme aux limites d’un style particulier, certaines propriétés souhaitables émergent.

Les contraintes de microservices incluent, par exemple :

  • Un service représente une seule responsabilité.
  • Chaque service est indépendant des autres.
  • Les données sont privées et accessibles uniquement au service auquel elles appartiennent. Les services ne partagent pas de données.

En adhérant à ces contraintes, ce qui apparaît est un système où les services peuvent être déployés indépendamment, les erreurs sont isolées, les mises à jour fréquentes sont possibles et il est facile d’introduire de nouvelles technologies dans l’application.

Avant de choisir un style d’architecture, assurez-vous de comprendre les principes sous-jacents et les contraintes de ce style. Dans le cas contraire, vous pouvez vous retrouver avec une conception qui est conforme au style à un niveau superficiel, mais qui n’atteint pas tout le potentiel de ce style. Il est également important d’être pragmatique. Il est parfois préférable d’assouplir une contrainte, plutôt que d’insister sur la pureté de l’architecture.

Le tableau suivant résume la façon dont chaque style gère les dépendances et les types de domaine qui sont le mieux adaptés pour chacun.

Style d’architecture Gestion des dépendances Type de domaine
Multiniveau Couches horizontales divisées par un sous-réseau. Domaine d’entreprise classique. La fréquence des mises à jour est faible.
Web-File d’attente-Worker Travaux frontaux et principaux, découplés par messagerie asynchrone. Domaine relativement simple avec des tâches gourmandes en ressources.
Microservices Services verticalement (fonctionnellement) décomposés qui s’appellent mutuellement via des API. Domaine complexe. Mises à jour fréquentes.
Architecture basée sur les événements Producteur/consommateur. Vue indépendante par sous-système. IoT et systèmes temps réel.
Big Data Divise un jeu de données volumineux en petits blocs. Traitement parallèle sur les jeux de données locaux. Analyse des données en mode batch et en temps réel Analyse prédictive à l’aide de ML.
Big Compute Allocation des données à des milliers de cœurs. Domaines nécessitant beaucoup de ressources système, tels que la simulation.

Prenez en compte les avantages et les défis

Les contraintes créent également des défis, il est donc important de comprendre les inconvénients lors de l’adoption d’un de ces styles. Les avantages peuvent l’emporter sur les défis liés au style architecture, pour ce sous-domaine et le contexte limité.

Voici quelques types de problèmes à prendre en compte lors de la sélection d’un style d’architecture :

  • Complexité : La complexité de l’architecture est-elle justifiée pour votre domaine ? À l’inverse, le style est-il trop simpliste pour votre domaine ? Dans ce cas, vous risquez de vous retrouver avec une « grande boule de boue » parce que l’architecture ne vous aide pas à gérer correctement les dépendances.
  • Messagerie asynchrone et cohérence éventuelle. La messagerie asynchrone peut être utilisée pour séparer des services et améliorer la fiabilité (étant donné que les messages peuvent être tentés à nouveau) et l’extensibilité. Toutefois, cela crée également des difficultés pour gérer la cohérence finale et une duplication possible des messages.
  • Communication interservice Lorsque vous décomposez une application en services distincts, il est possible que la communication entre services provoque une latence inacceptable ou crée une congestion du réseau (par exemple, dans une architecture microservices).
  • Facilité de gestion. Est-il difficile de gérer l’application, analyser, déployer des mises à jour et ainsi de suite ?
j.ramos
j.ramos

President Codevia & Senior Software Engineer, de plus de 10 ans d'expérience dans le domaine du développement logiciel, avec une spécialisation particulière dans la transition des logiciels obsolètes à caractère industriel. Fort de mon expertise technique et de ma compréhension approfondie des besoins spécifiques de l'industrie, j'ai consacré ma carrière à résoudre les défis complexes liés à la modernisation des systèmes logiciels obsolètes.

Articles: 59

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *