Partager via

Styles d’architecture

Un style d’architecture est une famille d’architectures qui partagent certaines caractéristiques. Par exemple, le niveau N est un style d’architecture courant. Plus récemment, les architectures de microservice ont commencé à gagner en faveur. Les styles d’architecture ne nécessitent pas l’utilisation de technologies particulières, mais certaines technologies conviennent bien à certaines architectures. Par exemple, les conteneurs sont une solution naturelle pour les microservices.

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

  • Description et diagramme logique du style.
  • Recommandations pour quand choisir ce style.
  • Avantages, défis et meilleures pratiques.
  • Déploiement recommandé à l’aide des services Azure pertinents.

Une visite guidée rapide des styles

Cette section fournit une visite guidée rapide des styles d’architecture que nous avons identifiés, ainsi que quelques considérations générales pour leur utilisation. Notez que la liste n’est pas exhaustive. Pour plus d’informations, consultez les rubriques liées.

Niveau N

Diagramme logique d’un style d’architecture de niveau N.

Le niveau N est une architecture traditionnelle 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 un inconvénient. Il peut être difficile d’introduire des modifications dans une partie de l’application sans toucher le reste de l’application. Cela rend les mises à jour fréquentes un défi, ce qui limite la rapidité avec laquelle de nouvelles fonctionnalités peuvent être ajoutées.

La couche N est naturelle pour la migration d’applications existantes qui utilisent déjà une architecture en couches. Pour cette raison, le niveau N est le plus souvent vu dans les solutions IaaS (Infrastructure as a Service) ou les applications qui utilisent une combinaison d’IaaS et de services managés.

Web-File d’attente-Worker

Diagramme logique du style d’architecture Web-Queue-Worker.

Pour une solution PaaS purement, envisagez une architecture Web-Queue-Worker . Dans ce style, l’application dispose d’un front-end web qui gère les requêtes HTTP et un worker back-end qui effectue des tâches nécessitant beaucoup d’UC ou des opérations de longue durée. Le serveur frontal communique avec le travailleur via une file d'attente asynchrone de messages.

Web-queue-worker est adapté aux domaines relativement simples avec des tâches gourmandes en ressources. Comme le niveau N, l’architecture est facile à comprendre. L’utilisation des services managé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 le niveau N, 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 de petite taille. Chaque service implémente une seule fonctionnalité métier. Les services sont faiblement couplés et communiquent par le biais de contrats d’API.

Chaque service peut être créé par une petite équipe de développement spécialisée. Les services individuels peuvent être déployés sans beaucoup de coordination entre les équipes, ce qui encourage les mises à jour fréquentes. Une architecture de microservices est plus complexe à créer et à gérer que les architectures N-tier ou Web-queue-worker. Elle nécessite un développement mature et une culture DevOps. Bien maîtrisé, ce style peut entraîner une vitesse de mise en production plus élevée, une innovation plus rapide et une architecture plus résiliente.

Architecture basée sur les événements

Diagramme d’un style d’architecture piloté par les événements.

Event-Driven Architectures utilisent un modèle publish-subscribe (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.

Considérez une architecture pilotée par les événements pour les applications qui ingèrent et traitent un grand volume de données avec une très faible latence, comme 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, calculabilité massive

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

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

Styles d’architecture en tant que contraintes

Un style d’architecture place des contraintes sur la conception, y compris l’ensemble d’éléments qui peuvent apparaître et les relations autorisées entre ces éléments. Les contraintes guident la « forme » d’une architecture en limitant l’univers des choix. Lorsqu’une architecture est conforme aux contraintes d’un style particulier, certaines propriétés souhaitables émergent.

Par exemple, les contraintes dans les microservices sont les suivantes :

  • Un service représente une responsabilité unique.
  • Chaque service est indépendant des autres.
  • Les données sont privées au service qui le possède. Les services ne partagent pas de données.

En respectant ces contraintes, ce qui ressort 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.

Chaque style d’architecture a ses propres compromis. Par conséquent, avant de choisir un style architectural, veillez à comprendre les principes et contraintes sous-jacents de ce style. Sinon, vous pouvez finir par une conception conforme au style à un niveau superficiel, mais n’obtient pas le plein potentiel de ce style. Vous devez faire attention davantage à la raison pour laquelle vous choisissez un certain style architectural que la façon de l’implémenter. Il est également important d’être pragmatique. Parfois, il est préférable de détendre une contrainte, plutôt que d’insister sur la pureté architecturale.

Le choix d’un style architectural approprié doit être effectué idéalement avec un consensus des parties prenantes de charge de travail informées. L’équipe de charge de travail doit d’abord identifier la nature du problème qu’elle tente de résoudre. Ensuite, ils doivent identifier les pilotes métier et les caractéristiques d’architecture correspondantes (également appelées exigences non fonctionnelles), puis les hiérarchiser. Par exemple, s’ils ont besoin d’un délai plus court pour le marché, ils peuvent hiérarchiser la maintenance, la testabilité et la fiabilité par les fonctionnalités de déploiement rapide. Ou si l’équipe de la charge de travail dispose d'un budget limité, elle pourrait prioriser la faisabilité et la simplicité. Choisir et maintenir un style architectural n’est pas une activité ponctuelle, mais une approche continue : l’architecture doit être mesurée en permanence, validée et affinée au fil du temps. Il y a généralement un coût important dans le changement de style architectural, de sorte que plus d’efforts peuvent être justifiés pour l’efficacité de l’équipe à long terme et l’atténuation des risques.

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

Style d’architecture Gestion des dépendances Type de domaine
Niveau N Niveaux horizontaux divisés par sous-réseau Domaine métier traditionnel. 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 certaines tâches gourmandes en ressources.
Microservices Les services décomposés verticalement (fonctionnellement) qui s’appellent les uns les autres par le biais d’API. Domaine compliqué. Mises à jour fréquentes.
Architecture pilotée par les événements Producteur/consommateur. Affichage indépendant par sous-système. Systèmes IoT et en temps réel.
Big Data Divisez un jeu de données énorme en petits blocs. Traitement parallèle sur les jeux de données locaux. Analyse des données par lots et en temps réel. Analyse prédictive à l’aide de ML.
Calcul intensif Allocation des données à des milliers de cœurs. Domaines gourmands en calcul, tels que la simulation.

Prendre en compte les défis et les avantages

Les contraintes créent également des défis, il est donc important de comprendre les compromis lors de l’adoption d’un de ces styles. Les avantages du style d’architecture l’emportent sur les défis liés à ce sous-domaine et à ce contexte limité.

Voici quelques-uns des types de défis à 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 finir par une « grosse boule de boue », car l’architecture ne vous aide pas à gérer les dépendances correctement.

  • Messagerie asynchrone et cohérence éventuelle. La messagerie asynchrone peut être utilisée pour dissocier les services et augmenter la fiabilité (car les messages peuvent être retentés) et la scalabilité. Toutefois, cela crée également des défis dans la gestion de la cohérence éventuelle, ainsi que la possibilité de doublons de messages.

  • Communication inter-services. Lorsque vous décomposez une application en services distincts, il existe un risque que la communication entre les services entraîne une latence inacceptable ou crée une congestion du réseau (par exemple, dans une architecture de microservices).

  • Facilité de gestion. Est-il difficile de gérer l’application, analyser, déployer des mises à jour et ainsi de suite ?