Övning – Skapa en hälsostruktur i lager

  • 11 minuter

I den här övningen är uppgiften att utforma en hälsomodell i lager för ett exempelprogram. Börja med att granska programarkitekturen, de viktiga Azure-tjänster som programmet använder och hur Azure-tjänsterna bidrar till den övergripande användarupplevelsen.

Exempelprogram

Exemplet för den här övningen är ett webbprogram som används av Contoso Shoes. Programmet gör det möjligt för anställda att bläddra i en katalog med produkter, uppdatera enskilda objekt i katalogen och interagera med andra användare genom att skapa kommentarer i programmet.

Driftteamet på Contoso Shoes identifierade två viktiga affärskrav för det här programmet. Anställda måste kunna:

  • Interagera med katalogen genom att visa listor över objekt och genom att bläddra bland objekt.
  • Skapa kommentarer för enskilda objekt som andra användare kan se.

Hälsomodellen bör minst innehålla dessa två kritiska åtgärder.

Arkitektur

Diagram som visar arkitekturen för Contoso Shoes-programmet.

Komponenter

  • Klientwebbprogram: Användargränssnittet för den här arbetsbelastningen, som körs på Azure Web Apps.

    • Läser från: Katalog-API, Azure Blob Storage
    • Skriver till: Katalog-API

  • Katalog-API: DET API-lager som klientdelens webbprogram använder för dataåtgärder på katalogobjekt och kommentarer. Den skriver inte till databasen. I stället skickas ett meddelande till en händelsehubb som ska bearbetas asynkront. Den här komponenten finns i Azure Functions.

    • Läser från: Azure Cosmos DB
    • Skriver till: Azure Event Hubs

  • Bakgrundsprocessor: En komponent som asynkront bearbetar databasuppdateringar. Processorn har ingen offentlig slutpunkt. Den här komponenten finns i Azure Functions.

    • Läser från: Azure Event Hubs
    • Skriver till: Azure Cosmos DB

  • Meddelandekö: Meddelandeprocessorn använder Azure Event Hubs för att skicka meddelanden mellan katalog-API:et och bakgrundsprocessorn.

  • Databas: Data sparas i Azure Cosmos DB. Katalog-API:et läser direkt från databasen. Bakgrundsprocessorn hanterar skrivningarna. Avbildningar lagras i Azure Blob Storage.

  • Hemligheter: Programkomponenterna i den här arbetsbelastningen använder hemligheter för att auktorisera åtkomst. Hemligheter lagras i Azure Key Vault. Katalog-API:et och bakgrundsprocessorn använder anslutningssträng för att komma åt databasen och Azure Event Hubs. Klientwebbprogrammet använder en API-nyckel för att anropa katalog-API:et.

  • Övervakning: Programkomponenter skickar alla datamätningar till Application Insights, som backas upp med en Log Analytics-arbetsyta. Samma arbetsyta används för att samla in andra loggar och mått för den här arbetsbelastningen.

Dela upp arkitekturen i lager

Enligt beskrivningen i föregående lektion ska en hälsomodell vara en lagerstruktur. Modelleringsprocessen är en arkitekturövning för att definiera alla användarflöden, mappa beroenden mellan funktionella och logiska komponenter och även beroenden mellan Azure-resurser.

Att identifiera användarflöden och skapa hälsomodellen är en konceptuell övning i det här skedet. Använd penna och papper eller ett tomt dokument för att notera de enskilda lagren och rita strukturen.

I den här övningen har vår hälsomodell tre lager: användarflöden, programkomponenter och Azure-resurser.

Användarflöden

Börja längst upp i arkitekturen och tänk på möjliga användarflöden baserat på programmets förväntade funktioner. Försök att sammanfatta teknisk information och Azure-tjänster och utvärdera flödena från en användares perspektiv.

  • Vilka processer är kritiska?
  • Hur använder de anställda programmet för att uppnå affärsmål?

Baserat på de krav som identifierats av driftteamet bör du ha minst två användarflöden i det översta lagret: Lista katalogobjekt och Lägg till kommentar.

Om du kan tänka dig mer kan du inkludera dem i din hälsomodell.

Programkomponenter

Flytta ned ett lager och utvärdera programkomponenterna. Börja med att ställa frågor, till exempel:

  • "Vilken del av mitt program gör att det här flödet fungerar?"
  • "Vilka mikrotjänster eller komponenter deltar i det här flödet?"
  • "Fungerar det här flödet fortfarande om den här delen misslyckas?"

Syftet är att identifiera programkomponenter på en teknisk nivå som bidrar till varje användarflöde. Dessa komponenter kan vara API:er, bakgrundsarbetare, mikrotjänster och så vidare.

Den här arbetsbelastningen har minst tre programkomponenter som deltar i de två identifierade användarflödena: klientdel, katalog-API och en bakgrundsprocessor.

Azure-resurser

Det nedre lagret innehåller de Azure-resurser som används av de enskilda programkomponenterna. I den här övningen beskrivs komponenterna och resurserna i avsnittet Komponenter .

Kommentar

Ett verkligt scenario kommer förmodligen att ha fler tjänster och ha mer komplicerade relationer mellan dem. En nyckel för att skapa en lyckad hälsomodell är att identifiera vilka delar som är kritiska och hur varje komponent bidrar till systemets övergripande hälsa.

Rita den slutliga hälsomodellstrukturen

Placera den information som du samlade in i en grafisk representation av hälsomodellstrukturen. Det bör se ut ungefär så här:

Diagram som visar arkitekturen för den här hälsomodellen i lager.

Hälsomodellen för webbprogram har följande lager uppifrån och ned:

Användarflöden
  • Lista katalogobjekt. Beroende på klientdelswebbprogrammet och katalog-API:et.
  • Lägg till kommentar. Beroende på klientdelswebbprogrammet, katalog-API:et och bakgrundsprocessorn.
Programkomponenter
  • Klientwebbprogram. Beroende av Blob Storage och katalog-API:et.
  • Katalog-API. Beroende av Azure Cosmos DB, Key Vault och Event Hubs.
  • Bakgrundsprocessor. Beroende av Azure Cosmos DB, Key Vault och Event Hubs.
Azure-resurser
  • Blob Storage
  • Azure Cosmos DB
  • Key Vault
  • Event Hubs