Styles d'architecture et modes de communication

Développer des applications sur AWS

Ricardo Sueiras

Principal Technologist

Votre formateur ou formatrice

Qu'est-ce qu'un patron d'architecture ?

 

 

 

• Solution réutilisable à un problème courant.
• Les patrons aident à assembler les services AWS.
• L'architecture détermine la tenue sous charge.
• Quelques patrons clés à connaître.

Monolithes

 

 

 

 

• Unité unique, fortement couplée.
• Un code source, un déploiement.
• Simple au départ.
• Difficile à faire évoluer : tout monte en charge ensemble.

Microservices

 

 

• Petits services indépendants : chacun couvre une capacité d'affaires.
• Déployer, mettre à l'échelle et mettre à jour séparément.
• Compromis : plus de complexité opérationnelle et de communication interservices.

Serverless

• Aucune infrastructure à gérer : seulement du code et de la configuration.
• Construction par composition de services AWS gérés.
• AWS gère l'approvisionnement, la mise à l'échelle et l'entretien.
• Compromis : limites de temps d'exécution, démarrages à froid, verrou du fournisseur.
• Surcharge opérationnelle quasi nulle et mise à l'échelle automatique.

 

Architecture axée sur les événements (EDA)

• Les composants communiquent par événements, pas par appels directs.
• Un événement consigne un fait (commande passée, paiement reçu, article expédié).
• Des producteurs émettent des événements.
• Des consommateurs s'abonnent aux événements pertinents.

 

Systèmes fortement et faiblement couplés

• Les applis infonuagiques modernes regroupent plusieurs services.
• Les services doivent communiquer et se coordonner.
• La communication synchrone est fortement couplée.
• L'asynchrone est faiblement couplée.

Communication synchrone

 

• Un service envoie une requête et attend la réponse.
• L'appelant est bloqué jusqu'à la réponse ou l'échéance.
• Simple à mettre en œuvre et à comprendre.
• Fort couplage : lenteur ou panne en aval en cascade.
• Atténuer par délais d'attente, nouvelles tentatives et coupe-circuit.

Patron : requête/réponse

• Ossature de la plupart des interfaces d'applis.
• Comportement prévisible.
• Rétroaction immédiate aux utilisateurs.

Communication asynchrone

 

• L'expéditeur n'attend pas de réponse.
• Envoie un message ou événement, puis poursuit.
• Le récepteur traite le message de façon autonome.
• Faible couplage : meilleure évolutivité et tolérance aux pannes.
• Gère bien les pointes de trafic et pannes partielles.
• Défis : doublons, ordre, cohérence éventuelle.

Patron : découplage par file d'attente

• Un producteur envoie des messages à une file.
• Un consommateur récupère et traite les messages de façon indépendante.
• Évite l'effet domino des pannes.
• Producteur et consommateur montent en charge séparément.

 

Patron : file de travailleurs

• Plusieurs travailleurs tirent des messages d'une file.
• Traitement des messages en parallèle.
• Favorise l'échelle horizontale et un débit accru.
• L'ordre des messages n'est pas garanti.

Patron : publier/s'abonner

• Des éditeurs envoient des messages à un sujet SNS.
• Plusieurs abonnés reçoivent le même message.
• Diffusion en temps réel à de nombreux consommateurs.

 

Patron : répartition en éventail (fan-out)

• Un message remis à plusieurs consommateurs simultanément.
• Très utilisé en architectures axées sur les événements.
• Utile quand plusieurs services doivent réagir au même événement.

Ordre des messages

• Certains travaux exigent un traitement des messages dans l'ordre.
• Amazon SQS FIFO et Kinesis prennent en charge l'ordre.
• L'ordre strict réduit le débit.
• Équilibrer exactitude et évolutivité.

Passons à la pratique !

Développer des applications sur AWS