Exercice - Créer une structure d’intégrité en couches

  • 11 minutes

Dans cet exercice, votre tâche consiste à concevoir un modèle d’intégrité en couches pour un exemple d’application. Commencez par passer en revue l’architecture de l’application, les services Azure clés utilisés par l’application et la façon dont ils contribuent à l’expérience utilisateur générale.

Exemple d’application

L’exemple de cet exercice est une application web utilisée par Contoso Shoes. L’application permet aux employés de parcourir un catalogue de produits, de mettre à jour des éléments individuels dans le catalogue et d’interagir avec d’autres utilisateurs en créant des commentaires dans l’application.

L’équipe des opérations Contoso Shoes a identifié deux exigences métier critiques pour cette application. Les employés doivent être en mesure de :

  • Interagir avec le catalogue pour afficher des listes d’éléments et parcourir les éléments.
  • Créer des commentaires pour des éléments individuels que d’autres utilisateurs peuvent voir.

Le modèle d’intégrité doit avoir au moins ces deux opérations critiques.

Architecture

Diagram that shows the architecture for the Contoso Shoes application.

Composants

  • Application web de front-end : interface utilisateur de cette charge de travail, qui s’exécute sur Azure Web Apps.

    • Lit dans : API du catalogue, Stockage Blob Azure
    • Écrit dans : API du catalogue

  • API du catalogue : couche d’API que l’application web de front-end utilise pour les opérations de données sur les éléments de catalogue et les commentaires. Elle n’écrit pas dans la base de données. À la place, un message est envoyé à un hub d’événements pour être traité de manière asynchrone. Ce composant est hébergé sur Azure Functions.

    • Lit dans : Azure Cosmos DB
    • Écrit dans : Azure Event Hubs

  • Processeur en arrière-plan : composant qui traite de manière asynchrone les mises à jour de base de données. Le processeur n’a pas de point de terminaison public. Ce composant est hébergé sur Azure Functions.

    • Lit dans : Azure Event Hubs
    • Écrit dans : Azure Cosmos DB

  • Répartiteur de messages : le processeur de messagerie utilise Azure Event Hubs pour passer des messages entre l’API du catalogue et le processeur en arrière-plan.

  • Base de données : les données sont conservées dans Azure Cosmos DB. L’API du catalogue lit directement dans la base de données. Les écritures sont gérées par le processeur en arrière-plan. Les données sont stockées dans le Stockage Blob Azure.

  • Secrets : les composants d’application de cette charge de travail utilisent des secrets pour autoriser l’accès. Les secrets sont stockés dans Azure Key Vault. L’API du catalogue et le processeur en arrière-plan utilisent des chaînes de connexion pour accéder à la base de données et Azure Event Hubs. L’application web de front-end utilise une clé API pour appeler l’API du catalogue.

  • Monitoring : les composants d’application envoient toutes les mesures de données à Application Insights, basé sur un espace de travail Log Analytics. Le même espace de travail est utilisé afin de collecter d’autres journaux et métriques pour cette charge de travail.

Diviser l’architecture en couches

Comme décrit dans l’unité précédente, un modèle d’intégrité doit être une structure en couches. Le processus de modélisation de l’intégrité est un exercice architectural permettant de définir tous les flux utilisateur, de mapper les dépendances entre les composants fonctionnels et logiques, ainsi que les dépendances entre les ressources Azure.

L’identification des flux utilisateur et la création du modèle d’intégrité représentent un exercice conceptuel à ce stade. Utilisez du papier et un crayon, ou un document vierge pour noter les couches individuelles et dessiner la structure.

Pour cet exercice, notre modèle d’intégrité a trois couches : flux utilisateur, composants d’application et ressources Azure.

Flux d’utilisateurs

En commençant en haut de l’architecture, réfléchissez aux flux utilisateur possibles en fonction des fonctionnalités attendues de l’application. Essayez de faire abstraction des détails techniques et des services Azure, et d’évaluer les flux du point de vue de l’utilisateur.

  • Quels sont les processus critiques ?
  • Comment les employés utilisent-ils l’application pour atteindre les objectifs métier ?

En fonction des exigences identifiées par l’équipe des opérations, vous devez avoir au moins deux flux utilisateur dans la couche supérieure : Lister les éléments du catalogue et Ajouter un commentaire.

Si vous pensez à d’autres flux, ajoutez-les à votre modèle d’intégrité.

Composants d’application

Descendez d’une couche et évaluez les composants d’application. Commencez par des questions de type :

  • « Quelle partie de mon application fait fonctionner ce flux ? »
  • « Quels microservices ou composants participent à ce flux ? »
  • « Ce flux fonctionne-t-il toujours en cas d’échec de cette partie ? »

L’objectif est d’identifier les composants d’application au niveau technique qui contribuent à chaque flux utilisateur. Ces composants peuvent être des API, des workers en arrière-plan, des microservices, etc.

Cette charge de travail a au moins trois composants d’application qui participent aux deux flux utilisateur identifiés : front-end, API du catalogue et processeur en arrière-plan.

Ressources Azure

La couche inférieure contient les ressources Azure utilisées par les composants d’application individuels. Pour cet exercice, les composants et les ressources sont décrits dans la section Composants.

Notes

Un scénario réel a probablement plus de services avec des relations plus compliquées entre eux. Un élément clé de la création d’un modèle d’intégrité réussi est d’identifier les parties critiques et comment chaque composant contribue à l’intégrité générale du système.

Dessiner la structure du modèle d’intégrité final

Placez les informations que vous avez collectées dans une représentation graphique de la structure du modèle d’intégrité. Elle doit ressembler à ce diagramme :

Diagram that shows the architecture for this layered health model.

De haut en bas, le modèle d’intégrité de l’application web a ces couches :

Flux d’utilisateurs
  • Lister les éléments du catalogue. Dépend de l’application web de front-end et de l’API du catalogue.
  • Ajouter un commentaire. Dépend de l’application web de front-end, de l’API du catalogue et du processeur en arrière-plan.
Composants d’application
  • Application web de front-end. Dépend du Stockage Blob et de l’API du catalogue.
  • API du Catalogue. Dépend d’Azure Cosmos DB, Key Vault et Event Hubs.
  • Processeur en arrière-plan. Dépend d’Azure Cosmos DB, Key Vault et Event Hubs.
Ressources Azure
  • Stockage Blob
  • Azure Cosmos DB
  • Key Vault
  • Hubs d'événements