Oefening: een gelaagde statusstructuur bouwen
In deze oefening is uw taak het ontwerpen van een gelaagd statusmodel voor een voorbeeldtoepassing. Begin met het controleren van de toepassingsarchitectuur, de belangrijkste Azure-services die door de toepassing worden gebruikt en hoe de Azure-services bijdragen aan de algehele gebruikerservaring.
Voorbeeldtoepassing
Het voorbeeld voor deze oefening is een webtoepassing die wordt gebruikt door Contoso Shoes. Met de toepassing kunnen werknemers door een catalogus met producten bladeren, afzonderlijke items in de catalogus bijwerken en communiceren met andere gebruikers door opmerkingen in de toepassing te maken.
Het operationele team van Contoso Shoes heeft twee kritieke bedrijfsvereisten voor deze toepassing geïdentificeerd. Werknemers moeten het volgende kunnen:
- Interactie met de catalogus door lijsten met items weer te geven en door te bladeren door items.
- Opmerkingen maken voor afzonderlijke items die andere gebruikers kunnen zien.
Het statusmodel moet ten minste deze twee kritieke bewerkingen bevatten.
Architectuur
Onderdelen
Front-endwebtoepassing: de gebruikersinterface van deze workload, die wordt uitgevoerd in Azure Web Apps.
- Leesbewerkingen van: Catalogus-API, Azure Blob Storage
- Schrijfbewerkingen naar: Catalogus-API
Catalogus-API: de API-laag die door de front-endwebtoepassing wordt gebruikt voor gegevensbewerkingen op catalogusitems en opmerkingen. Er wordt niet naar de database geschreven. In plaats daarvan wordt een bericht verzonden naar een Event Hub om asynchroon te worden verwerkt. Dit onderdeel wordt gehost in Azure Functions.
- Leesbewerkingen van: Azure Cosmos DB
- Schrijfbewerkingen naar: Azure Event Hubs
Achtergrondprocessor: een onderdeel dat asynchroon database-updates verwerkt. De processor heeft geen openbaar eindpunt. Dit onderdeel wordt gehost in Azure Functions.
- Leesbewerkingen van: Azure Event Hubs
- Schrijfbewerkingen naar: Azure Cosmos DB
Berichtbroker: De berichtenprocessor maakt gebruik van Azure Event Hubs om berichten door te geven tussen de Catalogus-API en de achtergrondprocessor.
Database: gegevens blijven behouden in Azure Cosmos DB. De Catalogus-API leest rechtstreeks uit de database. De achtergrondprocessor verwerkt de schrijfbewerkingen. Installatiekopieën worden opgeslagen in Azure Blob Storage.
Geheimen: De toepassingsonderdelen van deze workload maken gebruik van geheimen om toegang te autoriseren. Geheimen worden opgeslagen in Azure Key Vault. De Catalogus-API en achtergrondprocessor gebruiken verbindingsreeks s voor toegang tot de database en Azure Event Hubs. De front-endwebtoepassing gebruikt een API-sleutel om de Catalogus-API aan te roepen.
Bewaking: Toepassingsonderdelen verzenden alle gegevensmetingen naar Application Insights, ondersteund met een Log Analytics-werkruimte. Dezelfde werkruimte wordt gebruikt voor het verzamelen van andere logboeken en metrische gegevens voor deze workload.
De architectuur in lagen verdelen
Zoals beschreven in de vorige les, moet een statusmodel een gelaagde structuur zijn. Het proces van modelleringsstatus is een architectuuroefening voor het definiëren van alle gebruikersstromen, het toewijzen van afhankelijkheden tussen functionele en logische onderdelen en ook afhankelijkheden tussen Azure-resources.
Het identificeren van gebruikersstromen en het bouwen van het statusmodel is in deze fase een conceptuele oefening. Gebruik pen en papier of een leeg document om de afzonderlijke lagen te noteren en de structuur te tekenen.
Voor deze oefening heeft ons statusmodel drie lagen: gebruikersstromen, toepassingsonderdelen en Azure-resources.
Gebruikersstromen
Denk vanaf het begin van de architectuur na over de mogelijke gebruikersstromen op basis van de verwachte functionaliteit van de toepassing. Probeer de technische details en Azure-services te abstraheren en evalueer de stromen vanuit het perspectief van een gebruiker.
- Welke processen zijn essentieel?
- Hoe gebruiken de werknemers de toepassing om bedrijfsdoelen te bereiken?
Op basis van de vereisten die door het operations-team zijn geïdentificeerd, moet u ten minste twee gebruikersstromen in de bovenste laag hebben: Catalogusitems vermelden en opmerking toevoegen.
Als u meer kunt bedenken, neemt u deze op in uw statusmodel.
Toepassingsonderdelen
Een laag omlaag verplaatsen en de toepassingsonderdelen evalueren. Begin met het stellen van vragen, zoals:
- "Welk deel van mijn toepassing zorgt ervoor dat deze stroom werkt?"
- "Welke microservices of onderdelen nemen deel aan deze stroom?"
- 'Werkt deze stroom nog steeds als dit onderdeel mislukt?'
Het doel is om toepassingsonderdelen te identificeren op technisch niveau die bijdragen aan elke gebruikersstroom. Deze onderdelen kunnen API's, achtergrondmedewerkers, microservices, enzovoort zijn.
Deze workload heeft ten minste drie toepassingsonderdelen die deelnemen aan de twee geïdentificeerde gebruikersstromen: Front-end, Catalogus-API en een achtergrondprocessor.
Azure-resources
De onderste laag bevat de Azure-resources die worden gebruikt door de afzonderlijke toepassingsonderdelen. Voor deze oefening worden de onderdelen en resources beschreven in de sectie Onderdelen .
Notitie
Een praktijkscenario heeft waarschijnlijk meer services en heeft complexere relaties tussen deze services. Een sleutel voor het bouwen van een geslaagd statusmodel is om te bepalen welke onderdelen essentieel zijn en hoe elk onderdeel bijdraagt aan de algehele status van het systeem.
De uiteindelijke structuur van het statusmodel tekenen
Plaats de informatie die u hebt verzameld in een grafische weergave van de structuur van het statusmodel. Deze ziet er ongeveer als volgt uit:
Van boven naar beneden heeft het statusmodel van de webtoepassing de volgende lagen:
Gebruikersstromen
- Catalogusitems weergeven. Afhankelijk van de front-endwebtoepassing en de Catalogus-API.
- Opmerking toevoegen. Afhankelijk van de front-endwebtoepassing, catalogus-API en achtergrondprocessor.
Toepassingsonderdelen
- Front-endwebtoepassing. Afhankelijk van Blob Storage en de Catalogus-API.
- Catalogus-API. Afhankelijk van Azure Cosmos DB, Key Vault en Event Hubs.
- Achtergrondprocessor. Afhankelijk van Azure Cosmos DB, Key Vault en Event Hubs.
Azure-resources
- Blob Storage
- Azure Cosmos DB
- Sleutelkluis
- Event Hubs