Esercizio - Creare una struttura di integrità a più livelli

  • 11 minuti

In questo esercizio, l'attività consiste nel progettare un modello di integrità a più livelli per un'applicazione di esempio. Per iniziare, esaminare l'architettura dell'applicazione, i principali servizi di Azure usati dall'applicazione e il modo in cui i servizi di Azure contribuiscono all'esperienza utente complessiva.

Applicazione di esempio

L'esempio per questo esercizio è un'applicazione Web usata da Contoso Shoes. L'applicazione consente ai dipendenti di esplorare un catalogo di prodotti, aggiornare i singoli elementi nel catalogo e interagire con altri utenti creando commenti nell'applicazione.

Il team operativo di Contoso Shoes ha identificato due requisiti aziendali critici per questa applicazione. I dipendenti devono essere in grado di:

  • Interagire con il catalogo visualizzando elenchi di elementi ed esplorandoli.
  • Creare commenti per i singoli elementi da poter mostrare agli altri utenti.

Il modello di integrità deve includere almeno queste due operazioni critiche.

Architettura

Diagram that shows the architecture for the Contoso Shoes application.

Componenti

  • Applicazione Web front-end: interfaccia utente di questo carico di lavoro, che viene eseguita in Azure App Web.

    • Legge da: API catalogo, Archiviazione BLOB di Azure
    • Scrive in: API catalogo

  • API catalogo: livello API usato dall'applicazione Web front-end per le operazioni sui dati sugli elementi e sui commenti del catalogo. Non scrive nel database. Viene invece inviato un messaggio a un hub eventi da elaborare in modo asincrono. Questo componente è ospitato in Funzioni di Azure.

    • Legge da: Azure Cosmos DB
    • Scrive in: Hub eventi di Azure

  • Processore in background: componente che elabora in modo asincrono gli aggiornamenti del database. Il processore non ha un endpoint pubblico. Questo componente è ospitato in Funzioni di Azure.

    • Legge da: Hub eventi di Azure
    • Scrive in: Azure Cosmos DB

  • Broker messaggi: il processore di messaggistica usa Hub eventi di Azure per passare messaggi tra l'API catalogo e il processore in background.

  • Database: i dati vengono salvati in modo permanente in Azure Cosmos DB. L'API catalogo legge direttamente dal database. Le scritture vengono gestite dal processore in background. Le immagini vengono archiviate in Archiviazione BLOB di Azure.

  • Segreti: i componenti dell'applicazione di questo carico di lavoro utilizzano segreti per autorizzare l'accesso. I segreti vengono archiviati in Azure Key Vault. L'API Catalogo e Il processore in background usano stringhe di connessione per accedere al database e a Hub eventi di Azure. L'applicazione Web front-end usa una chiave API per chiamare l'API catalogo.

  • Monitoraggio: i componenti dell'applicazione inviano tutte le misurazioni dei dati ad Application Insights, supportate da un'area di lavoro Log Analytics. La stessa area di lavoro viene usata per raccogliere altri log e metriche per questo carico di lavoro.

Dividere l'architettura nei livelli

Come descritto nell'unità precedente, un modello di integrità deve rappresentare una struttura a più livelli. Il processo di modellazione dell'integrità è un esercizio architettonico per definire tutti i flussi utente, eseguire il mapping delle dipendenze tra componenti funzionali e logici e anche le dipendenze tra le risorse di Azure.

In questa fase, l'identificazione dei flussi utente e la creazione del modello di integrità sono un esercizio concettuale. Utilizzare penna e carta o un documento vuoto per annotare i singoli livelli e disegnare la struttura.

Per questo esercizio, il modello di integrità dispone di tre livelli: i flussi utente, i componenti dell'applicazione e le risorse di Azure.

Flussi degli utenti

A partire dall'inizio dell'architettura, considerare i possibili flussi utente in base alle funzionalità previste dell'applicazione. Provare ad astrarre i dettagli tecnici e i servizi di Azure e valutare i flussi dal punto di vista di un utente.

  • Quali processi sono critici?
  • In che modo i dipendenti usano l'applicazione per raggiungere gli obiettivi aziendali?

In base ai requisiti identificati dal team operativo, è necessario disporre di almeno due flussi utente nel livello superiore: Elencare gli elementi del catalogo e Aggiungi commento.

Se ne vengono in mente altri, includerli nel modello di integrità.

Componenti dell'applicazione

Spostare verso il basso un livello e valutare i componenti dell'applicazione. Iniziare ponendo domande, ad esempio:

  • "Quale parte dell'applicazione rende questo flusso funzionante?"
  • "Quali microservizi o componenti partecipano a questo flusso?"
  • "Questo flusso funziona ancora se questa parte ha esito negativo?"

L'obiettivo è identificare a livello tecnico i componenti dell'applicazione che contribuiscono a ciascun flusso utente. Questi componenti possono essere API, ruoli di lavoro in background, microservizi e così via.

Questo carico di lavoro include almeno tre componenti dell'applicazione che partecipano ai due flussi utente identificati: Front-end, API catalogo e processore in background.

Risorse di Azure

Il livello inferiore contiene le risorse di Azure usate dai singoli componenti dell'applicazione. Per questo esercizio, i componenti e le risorse sono descritti nella sezione Componenti.

Nota

Uno scenario reale probabilmente avrà più servizi e avrà relazioni più complesse tra di esse. Una chiave per creare un modello di integrità efficace consiste nell'identificare quali parti sono fondamentali e in che modo ciascun componente contribuisce all'integrità complessiva del sistema.

Disegnare la struttura finale del modello di integrità

Inserire le informazioni raccolte in una rappresentazione grafica della struttura del modello di integrità. Dovrebbe essere simile all'esempio seguente:

Diagram that shows the architecture for this layered health model.

Dall'alto in basso, il modello di integrità dell'applicazione Web presenta questi livelli:

Flussi degli utenti
  • Elencare gli elementi del catalogo. Dipendente dall'applicazione Web front-end e dall'API catalogo.
  • Aggiungi commento. Dipendente dall'applicazione Web front-end, dall'API catalogo e dal processore in background.
Componenti dell'applicazione
  • Applicazione Web front-end. Dipendente dall'archiviazione BLOB e dall'API catalogo.
  • API Catalogo. Dipendente da Azure Cosmos DB, Key Vault e Hub eventi.
  • Processore in background. Dipendente da Azure Cosmos DB, Key Vault e Hub eventi.
Risorse di Azure
  • Archiviazione BLOB
  • Azure Cosmos DB
  • Insieme di credenziali delle chiavi di
  • Hub eventi