Cvičení – vytvoření vrstvené struktury stavu

  • 11 min

V tomto cvičení je vaším úkolem navrhnout vrstvený model stavu pro ukázkovou aplikaci. Začněte kontrolou architektury aplikace, klíčových služeb Azure, které aplikace používá, a tím, jak služby Azure přispívají k celkovému uživatelskému prostředí.

Příklad aplikace

Příkladem pro toto cvičení je webová aplikace, kterou společnost Contoso Shoes používá. Aplikace umožňuje zaměstnancům procházet katalog produktů, aktualizovat jednotlivé položky v katalogu a pracovat s ostatními uživateli vytvořením komentářů v aplikaci.

Provozní tým společnosti Contoso Shoes identifikoval pro tuto aplikaci dva důležité obchodní požadavky. Zaměstnanci musí být schopni:

  • Interakce s katalogem zobrazením seznamů položek a procházením položek
  • Vytvořte komentáře pro jednotlivé položky, které uvidí ostatní uživatelé.

Model stavu by měl alespoň zahrnovat tyto dvě kritické operace.

Architektura

Diagram znázorňující architekturu aplikace Contoso Shoes

Komponenty

  • Front-endová webová aplikace: Uživatelské rozhraní této úlohy, které běží ve službě Azure Web Apps.

    • Čtení z: Rozhraní API katalogu, Azure Blob Storage
    • Zápisy do: Rozhraní API katalogu

  • Rozhraní API katalogu: Vrstva rozhraní API, kterou front-endová webová aplikace používá pro operace s daty s položkami a komentáři katalogu. Nezapisuje se do databáze. Místo toho se zpráva odešle do centra událostí, která se zpracuje asynchronně. Tato komponenta je hostovaná ve službě Azure Functions.

    • Čtení z: Azure Cosmos DB
    • Zápisy do: Azure Event Hubs

  • Procesor na pozadí: Komponenta, která asynchronně zpracovává aktualizace databáze. Procesor nemá veřejný koncový bod. Tato komponenta je hostovaná ve službě Azure Functions.

    • Čtení z: Azure Event Hubs
    • Zápisy do: Azure Cosmos DB

  • Zprostředkovatel zpráv: Procesor zasílání zpráv používá službu Azure Event Hubs k předávání zpráv mezi rozhraním API katalogu a procesorem na pozadí.

  • Databáze: Data se uchovávají ve službě Azure Cosmos DB. Rozhraní API katalogu čte přímo z databáze. Procesor na pozadí zpracovává zápisy. Obrázky se ukládají ve službě Azure Blob Storage.

  • Tajné kódy: Součásti aplikace této úlohy používají tajné kódy k autorizaci přístupu. Tajné kódy jsou uložené ve službě Azure Key Vault. Rozhraní API katalogu a procesor na pozadí používají připojovací řetězec pro přístup k databázi a službě Azure Event Hubs. Front-endová webová aplikace používá klíč rozhraní API k volání rozhraní API katalogu.

  • Monitorování: Komponenty aplikací odesílají všechna měření dat do Application Insights, která je založená na pracovním prostoru služby Log Analytics. Stejný pracovní prostor slouží ke shromažďování dalších protokolů a metrik pro tuto úlohu.

Rozdělení architektury ve vrstvách

Jak je popsáno v předchozí lekci, model stavu by měl být vrstvenou strukturou. Proces modelování stavu je architektonické cvičení, které definuje všechny toky uživatelů, mapuje závislosti mezi funkčními a logickými komponentami a také závislosti mezi prostředky Azure.

Identifikace toků uživatelů a sestavení modelu stavu je koncepční cvičení v této fázi. Pomocí pera a papíru nebo prázdného dokumentu si poznamenejte jednotlivé vrstvy a nakreslete strukturu.

V tomto cvičení má náš model stavu tři vrstvy: toky uživatelů, komponenty aplikací a prostředky Azure.

Toky uživatele

Od začátku architektury se zamyslete nad možnými toky uživatelů na základě očekávané funkčnosti aplikace. Zkuste abstrahovat technické podrobnosti a služby Azure a vyhodnotit toky z pohledu uživatele.

  • Jaké procesy jsou kritické?
  • Jak zaměstnanci aplikaci používají k dosažení obchodních cílů?

Na základě požadavků identifikovaných provozním týmem byste měli mít v horní vrstvě alespoň dva toky uživatelů: Zobrazit položky katalogu a Přidat komentář.

Pokud si můžete představit více, zahrňte je do svého zdravotnického modelu.

Komponenty aplikace

Přesuňte vrstvu dolů a vyhodnoťte komponenty aplikace. Začněte tím, že položíte otázky, například:

  • "Která část mé aplikace tok funguje?"
  • "Které mikroslužby nebo komponenty se účastní tohoto toku?"
  • "Bude tento tok fungovat i v případě, že tato část selže?"

Cílem je identifikovat komponenty aplikací na technické úrovni, které přispívají k jednotlivým tokům uživatelů. Tyto komponenty můžou být rozhraní API, pracovní procesy na pozadí, mikroslužby atd.

Tato úloha má aspoň tři komponenty aplikace, které se účastní dvou identifikovaných toků uživatelů: front-end, rozhraní API katalogu a procesor na pozadí.

Prostředky Azure

Dolní vrstva obsahuje prostředky Azure používané jednotlivými komponentami aplikace. V tomto cvičení jsou komponenty a prostředky popsané v části Součásti .

Poznámka:

Skutečný scénář pravděpodobně bude mít více služeb a bude mezi nimi mít složitější vztahy. Klíčem k vytvoření úspěšného modelu stavu je identifikace důležitých částí a toho, jak každá komponenta přispívá k celkovému stavu systému.

Nakreslete konečnou strukturu modelu stavu.

Vložte informace, které jste shromáždili, do grafické reprezentace struktury modelu stavu. Měl by vypadat podobně jako tento diagram:

Diagram znázorňující architekturu pro tento vrstvený model stavu

Odshora dolů má model stavu webové aplikace tyto vrstvy:

Toky uživatele
  • Vypsat položky katalogu Závisí na front-end webové aplikaci a rozhraní API katalogu.
  • Přidat komentář Závisí na front-endové webové aplikaci, rozhraní API katalogu a procesoru na pozadí.
Komponenty aplikace
  • Front-endová webová aplikace Závisí na službě Blob Storage a rozhraní API katalogu.
  • Rozhraní API katalogu Závisí na službě Azure Cosmos DB, key Vaultu a službě Event Hubs.
  • Procesor na pozadí Závisí na službě Azure Cosmos DB, key Vaultu a službě Event Hubs.
Prostředky Azure
  • Blob Storage
  • Azure Cosmos DB
  • Key Vault
  • Event Hubs