Ćwiczenie — tworzenie warstwowej struktury kondycji

  • 11 min

W tym ćwiczeniu twoim zadaniem jest zaprojektowanie modelu kondycji warstwowej dla przykładowej aplikacji. Zacznij od przejrzenia architektury aplikacji, kluczowych usług platformy Azure używanych przez aplikację oraz sposobu współtworzenia przez usługi platformy Azure ogólnego środowiska użytkownika.

Przykładowa aplikacja

Przykładem tego ćwiczenia jest aplikacja internetowa używana przez firmę Contoso Shoes. Aplikacja umożliwia pracownikom przeglądanie katalogu produktów, aktualizowanie poszczególnych elementów w katalogu i interakcję z innymi użytkownikami przez tworzenie komentarzy w aplikacji.

Zespół operacyjny firmy Contoso Shoes zidentyfikował dwa krytyczne wymagania biznesowe dla tej aplikacji. Pracownicy muszą mieć możliwość:

  • Wchodzenie w interakcję z wykazem przez wyświetlanie list elementów i przeglądanie elementów.
  • Utwórz komentarze dla poszczególnych elementów dla innych użytkowników, aby zobaczyć.

Model kondycji powinien obejmować co najmniej te dwie operacje krytyczne.

Architektura

Diagram przedstawiający architekturę aplikacji Contoso Shoes.

Składniki

  • Aplikacja internetowa frontonu: interfejs użytkownika tego obciążenia, który działa w usłudze Azure Web Apps.

    • Odczyty z: interfejs API wykazu, usługa Azure Blob Storage
    • Zapisy do: interfejs API wykazu

  • Interfejs API wykazu: warstwa interfejsu API używana przez aplikację internetową frontonu na potrzeby operacji na danych dotyczących elementów katalogu i komentarzy. Nie zapisuje w bazie danych. Zamiast tego komunikat jest wysyłany do centrum zdarzeń, które ma być przetwarzane asynchronicznie. Ten składnik jest hostowany w usłudze Azure Functions.

    • Odczyty z: Azure Cosmos DB
    • Zapisy do: Azure Event Hubs

  • Procesor w tle: składnik, który asynchronicznie przetwarza aktualizacje bazy danych. Procesor nie ma publicznego punktu końcowego. Ten składnik jest hostowany w usłudze Azure Functions.

    • Odczyty z: Azure Event Hubs
    • Zapisy do: Azure Cosmos DB

  • Broker komunikatów: procesor obsługi komunikatów używa usługi Azure Event Hubs do przekazywania komunikatów między interfejsem API wykazu a procesorem w tle.

  • Baza danych: dane są utrwalane w usłudze Azure Cosmos DB. Interfejs API wykazu odczytuje bezpośrednio z bazy danych. Procesor w tle obsługuje operacje zapisu. Obrazy są przechowywane w usłudze Azure Blob Storage.

  • Wpisy tajne: składniki aplikacji tego obciążenia używają wpisów tajnych do autoryzowania dostępu. Wpisy tajne są przechowywane w usłudze Azure Key Vault. Interfejs API wykazu i procesor w tle używają parametry połączenia w celu uzyskania dostępu do bazy danych i usługi Azure Event Hubs. Aplikacja internetowa frontonu używa klucza interfejsu API do wywoływania interfejsu API wykazu.

  • Monitorowanie: składniki aplikacji wysyłają wszystkie miary danych do usługi Application Insights, wspierane przez obszar roboczy usługi Log Analytics. Ten sam obszar roboczy służy do zbierania innych dzienników i metryk dla tego obciążenia.

Dzielenie architektury w warstwach

Zgodnie z opisem w poprzedniej lekcji model kondycji powinien być strukturą warstwową. Proces modelowania kondycji to ćwiczenie architektoniczne do definiowania wszystkich przepływów użytkownika, mapowania zależności między składnikami funkcjonalnymi i logicznymi, a także zależności między zasobami platformy Azure.

Identyfikowanie przepływów użytkowników i tworzenie modelu kondycji jest ćwiczeniem koncepcyjnym na tym etapie. Użyj pióra i papieru lub pustego dokumentu, aby zanotować poszczególne warstwy i narysować strukturę.

W tym ćwiczeniu nasz model kondycji ma trzy warstwy: przepływy użytkownika, składniki aplikacji i zasoby platformy Azure.

Przepływy użytkowników

Począwszy od góry architektury, pomyśl o możliwych przepływach użytkownika na podstawie oczekiwanej funkcjonalności aplikacji. Spróbuj wyodrębnić szczegóły techniczne i usługi platformy Azure oraz ocenić przepływy z perspektywy użytkownika.

  • Jakie procesy są krytyczne?
  • Jak pracownicy korzystają z aplikacji, aby osiągnąć cele biznesowe?

Na podstawie wymagań zidentyfikowanych przez zespół operacyjny należy mieć co najmniej dwa przepływy użytkowników w górnej warstwie: elementy wykazu listy i Dodaj komentarz.

Jeśli możesz myśleć o więcej, uwzględnij je w modelu kondycji.

Składniki aplikacji

Przenieś warstwę w dół i oceń składniki aplikacji. Zacznij od zadawania pytań, takich jak:

  • "Która część mojej aplikacji sprawia, że ten przepływ działa?"
  • "Które mikrousługi lub składniki uczestniczą w tym przepływie?"
  • "Czy ten przepływ będzie nadal działać, jeśli ta część nie powiedzie się?".

Celem jest zidentyfikowanie składników aplikacji na poziomie technicznym, które przyczyniają się do każdego przepływu użytkownika. Te składniki mogą być interfejsami API, pracownikami w tle, mikrousługami itd.

To obciążenie ma co najmniej trzy składniki aplikacji, które uczestniczą w dwóch zidentyfikowanych przepływach użytkowników: frontonu, interfejsu API wykazu i procesora w tle.

Zasoby platformy Azure

Warstwa dolna zawiera zasoby platformy Azure używane przez poszczególne składniki aplikacji. W tym ćwiczeniu składniki i zasoby są opisane w sekcji Składniki .

Uwaga

Rzeczywisty scenariusz prawdopodobnie będzie miał więcej usług i ma bardziej skomplikowane relacje między nimi. Kluczem do utworzenia pomyślnego modelu kondycji jest określenie, które części są krytyczne i jak każdy składnik przyczynia się do ogólnej kondycji systemu.

Rysowanie ostatecznej struktury modelu kondycji

Umieść informacje zebrane w graficznej reprezentacji struktury modelu kondycji. Powinien wyglądać podobnie do tego diagramu:

Diagram przedstawiający architekturę dla tego modelu kondycji warstwowej.

Od góry do dołu model kondycji aplikacji internetowej ma następujące warstwy:

Przepływy użytkowników
  • Wyświetlanie listy elementów wykazu. Zależne od aplikacji internetowej frontonu i interfejsu API wykazu.
  • Dodaj komentarz. Zależne od aplikacji internetowej frontonu, interfejsu API wykazu i procesora w tle.
Składniki aplikacji
  • Aplikacja internetowa frontonu. Zależne od usługi Blob Storage i interfejsu API wykazu.
  • Interfejs API wykazu. Zależne od usług Azure Cosmos DB, Key Vault i Event Hubs.
  • Procesor w tle. Zależne od usług Azure Cosmos DB, Key Vault i Event Hubs.
Zasoby platformy Azure
  • Blob Storage
  • Azure Cosmos DB
  • Magazyn kluczy
  • Event Hubs