Microsoft AZ-204: Rozwiązania oparte na zdarzeniach i komunikatach w Azure — Przewodnik do nauki

By Laurynas Brazys · 5 August 2026 · #microsoft #az-204 #certification #exam-prep #study-guide

Część Microsoft Azure Developer Associate AZ-204 — Przewodnik do nauki. Ćwicz ze zweryfikowanymi odpowiedziami w centrum egzaminów Microsoft, albo rozwiąż testy na czas na ExamRoll.io.

Przegląd

Portfolio zdarzeń i komunikatów Azure obejmuje cztery uzupełniające się usługi: Event Grid do reaktywnego przetwarzania zdarzeń, Event Hubs do pozyskiwania strumieni o wysokiej przepustowości, Service Bus do obsługi komunikatów korporacyjnych i koordynacji przepływów pracy oraz Notification Hubs do powiadomień mobilnych typu push. Opanowanie ich wymaga znajomości podstawowych abstrakcji każdej usługi, semantyki dostarczania i ponawiania prób, modeli skalowania oraz wiedzy, kiedy preferować jedną usługę nad drugą w typowych wzorcach aplikacji, takich jak pub/sub, przetwarzanie poleceń, pozyskiwanie danych telemetrycznych oraz powiadomienia dla urządzeń lub użytkowników.

Event Grid: Tematy, subskrypcje, schemat, filtrowanie i dead-lettering

Event Grid to w pełni zarządzana, oparta na modelu push struktura pub/sub dla zdarzeń dyskretnych. Wydawcy wysyłają zdarzenia do tematu (topic); subskrybenci rejestrują subskrypcje zdarzeń w temacie i otrzymują pasujące zdarzenia w obsługiwanych punktach końcowych (handlers), takich jak webhooki HTTPS, Azure Functions, Logic Apps, Service Bus, Storage Queues i Event Hubs. Event Grid definiuje dwa modele wydawców. Tematy systemowe (System topics) to zarządzane przez Azure zasoby tematów, które reprezentują usługi Azure (first-party) publikujące zdarzenia w ramach Twojej subskrypcji lub grupy zasobów (na przykład utworzenie obiektu blob w Storage, rotacja sekretu w Key Vault lub zdarzenia Resource Manager). Tematy niestandardowe (Custom topics) to tworzone przez użytkownika punkty końcowe tematów, do których publikują Twoje aplikacje, umożliwiając stosowanie wzorców sterowanych zdarzeniami we własnych usługach i domenach. Tematy systemowe nie wymagają kodu po stronie wydawcy i upraszczają łączenie zasobów Azure z reaktywnymi punktami końcowymi; tematy niestandardowe dają pełną kontrolę nad kontraktami i cyklem życia zdarzeń.

Zdarzenia Event Grid mogą używać natywnego schematu Event Grid lub specyfikacji CloudEvents v1.0. W schemacie Event Grid każde zdarzenie zawiera id (unikalny identyfikator), eventType (akcja), subject (hierarchiczna ścieżka wspierająca filtrowanie), eventTime (UTC), data (ładunek), dataVersion, metadataVersion i topic. CloudEvents dostarcza ustandaryzowany zestaw atrybutów, takich jak id, source, type, time, subject i data. Wybór CloudEvents ułatwia interoperacyjność między platformami; schemat Event Grid zachowuje zgodność ze zdarzeniami pochodzącymi z Azure i umożliwia zaawansowane filtrowanie po polu subject.

Subskrypcje zdarzeń definiują routing, opcje dostarczania i filtry. Podstawowe filtry obejmują filtrowanie po typie zdarzenia oraz prefiksie/sufiksie tematu (subjectBeginsWith, subjectEndsWith), co jest wydajne w przypadku hierarchicznego nazewnictwa zasobów. Filtry zaawansowane dopasowują wartości w polach zdarzenia na najwyższym poziomie lub wewnątrz danych (na przykład porównania zakresów liczbowych, zawieranie ciągu znaków bez uwzględniania wielkości liter, równość logiczna i zawieranie w tablicy). Można łączyć filtry w celu precyzyjnej kontroli dystrybucji (fan-out), minimalizując pracę systemów podrzędnych i ruch wychodzący (egress).

Dostarczanie odbywa się w modelu push z semantyką co najmniej jednokrotnego dostarczenia (at-least-once). Event Grid ponawia próby z wykładniczym czasem oczekiwania (exponential back-off). Można skonfigurować maksymalną liczbę ponownych prób i czas życia zdarzenia (time-to-live); gdy dostarczenie ostatecznie się nie powiedzie lub zdarzenie wygaśnie, Event Grid może przenieść je do kolejki niedostarczonych komunikatów (dead-letter) w kontenerze Blob Storage wskazanym w subskrypcji. Przenoszenie do kolejki niedostarczonych komunikatów (dead-lettering) zachowuje ładunki i metadane do celów audytu lub ponownego przetwarzania; w razie potrzeby należy użyć osobnego procesu do odtworzenia i ponownego wysłania zdarzeń. Punkty końcowe typu webhook uczestniczą w uzgadnianiu poprawności (validation handshake) w celu potwierdzenia własności, a w przypadku sieci o ograniczonym dostępie można preferować zarządzane punkty końcowe Azure (Functions, Service Bus, Storage Queue), które nie wymagają publicznej ekspozycji i mogą korzystać z autoryzacji opartej na Azure AD.

Event Hubs: Partycje, grupy konsumentów, przepustowość, funkcja Capture i niezawodna konsumpcja

Usługa Event Hubs pozyskuje strumienie telemetrii i logów o dużej objętości z niskim opóźnieniem. Dane są dołączane do partycji, które są niezależnymi, uporządkowanymi dziennikami zatwierdzeń. Partycje są wybierane w momencie tworzenia w celu zrównoleglenia przepustowości; producenci przypisują klucz partycji, aby zachować kolejność dla danego klucza, a usługa haszuje klucze do odpowiednich partycji. Wielu czytelników może przetwarzać partycje równolegle; w obrębie jednej partycji kolejność jest gwarantowana.

Grupy konsumentów zapewniają niezależne widoki strumienia, pozwalając różnym aplikacjom przetwarzającym na utrzymywanie własnych pozycji bez wzajemnego zakłócania się (na przykład detektor anomalii w czasie rzeczywistym i potok do archiwizacji). Skalowanie czytelników w poziomie wymaga równoważenia własności partycji; klient EventProcessorClient z SDK koordynuje przypisywanie i ponowne równoważenie partycji między instancjami.

Jednostki przepustowości (Throughput Units, TU) w warstwie Standard definiują pojemność: każda jednostka TU uprawnia do określonych limitów przepustowości dla ruchu przychodzącego (ingress) i wychodzącego (egress). Funkcja Auto-inflate może automatycznie skalować jednostki TU w górę, aby sprostać szczytowemu obciążeniu. Warstwa Premium wykorzystuje jednostki przetwarzania (Processing Units) z dedykowaną mocą obliczeniową i przewidywalnym opóźnieniem. Monitoruj metryki ograniczania przepustowości (throttling), aby zweryfikować poprawność aprowizacji. Event Hubs obsługuje protokół Kafka na tym samym punkcie końcowym, co upraszcza migrację typu lift-and-shift dla klientów Kafka bez konieczności uruchamiania brokerów.

Producenci mogą używać protokołu AMQP lub HTTPS. AMQP (w tym AMQP-over-WebSockets na porcie 443) zapewnia multipleksowane, trwałe połączenia i wydajne batchowanie, i jest zalecany zarówno do wysyłania, jak i odbierania danych. HTTPS jest odpowiedni do prostych lub sporadycznych wysyłek, ale nie jest obsługiwany do odbierania danych; long-polling nie jest dostępny, a użytkownik traci na wydajności i kontroli przepływu. W ograniczonych sieciach korporacyjnych AMQP-over-WebSockets zachowuje wydajność, przechodząc przez typowe serwery proxy dla ruchu wychodzącego.

Tworzenie punktów kontrolnych (checkpointing) i zarządzanie przesunięciami (offsetami) są kluczowe dla poprawności działania. Każde zdarzenie ma numer sekwencyjny i przesunięcie (offset) w ramach danej partycji. Odbiorcy przesuwają się w strumieniu, a po pomyślnym przetworzeniu partii danych zapisują swoją pozycję jako punkt kontrolny w trwałym magazynie — zazwyczaj w kontenerze Azure Blob Storage za pośrednictwem EventProcessorClient. W przypadku ponownego uruchomienia lub przełączenia awaryjnego (failover), procesor wznawia pracę od ostatniego punktu kontrolnego, osiągając przetwarzanie “co najmniej raz” (at-least-once) przy użyciu idempotentnych procedur obsługi. Bez punktów kontrolnych konsumenci rozpoczynają pracę od domyślnej pozycji (najnowszej lub najwcześniejszej) i ryzykują ponowne przetworzenie lub pominięcie zdarzeń.

Funkcja Capture zapewnia archiwizację po stronie serwera poprzez automatyczne zapisywanie wsadowych plików Avro w trybie tylko do dołączania (append-only) do usługi Azure Blob Storage lub Azure Data Lake Storage Gen2, w konfigurowalnym oknie czasowym lub rozmiarowym. Eliminuje to potrzebę tworzenia niestandardowych mechanizmów wsadowych dla analityki ścieżki zimnej (cold-path), umożliwiając narzędziom podrzędnym (takim jak Spark, Synapse) konsumowanie niezmiennych segmentów strumienia z semantyką “dokładnie raz” (exactly-once) w odniesieniu do potoku funkcji Capture.

Service Bus i Queue Storage: Polecenia, przepływy pracy, sesje i obsługa zatrutych wiadomości

Service Bus to broker wiadomości klasy korporacyjnej przeznaczony do obsługi poleceń, przepływów pracy i scenariuszy integracyjnych, które wymagają zaawansowanych gwarancji dostarczenia. Kolejki implementują komunikację typu punkt-punkt; każda wiadomość jest odbierana przez jednego konkurującego konsumenta. Tematy z subskrypcjami umożliwiają model pub/sub: wydawcy wysyłają wiadomości do tematu, a niezależne subskrypcje otrzymują ich kopie na podstawie reguł. Reguły subskrypcji mogą być filtrami SQL, filtrami korelacji lub filtrami logicznymi (boolean true), które określają dla każdej wiadomości, czy ma zostać dołączona, i mogą dodawać lub modyfikować jej właściwości za pomocą akcji.

Sesje zapewniają uporządkowane i wyłączne przetwarzanie powiązanych ze sobą wiadomości. Należy przypisać ten sam identyfikator SessionId do wiadomości, które należą do jednej grupy (na przykład wszystkie kroki w zamówieniu nr 123). Odbiorca akceptuje blokadę sesji i przetwarza wiadomości w kolejności ich nadejścia dla tej sesji, opcjonalnie utrzymując jej stan, a następnie zwalnia sesję, aby kolejny konsument mógł przejąć jej obsługę. Jest to preferowany wzorzec do implementacji FIFO na dużą skalę. Bez sesji kolejność przetwarzania nie jest gwarantowana pomiędzy konkurującymi konsumentami.

Service Bus obsługuje tryby PeekLock i ReceiveAndDelete. PeekLock jest domyślnym trybem zapewniającym niezawodność: konsument blokuje wiadomość na czas trwania blokady, przetwarza ją, a następnie finalizuje operacją Complete. Jeśli przetwarzanie się nie powiedzie, konsument może użyć operacji Abandon (udostępniając wiadomość ponownie), Defer (odraczając jej pobranie na później na podstawie numeru sekwencyjnego) lub Dead-letter (przenosząc ją do oddzielnej podkolejki utraconych wiadomości danej encji z podaniem przyczyny i opisu błędu). Tryb ReceiveAndDelete zamienia niezawodność na przepustowość, usuwając wiadomość natychmiast po jej odebraniu.

Kluczowe właściwości kontrolują cykl życia wiadomości. Właściwość Time to Live (TTL) można ustawić jako domyślną dla całej encji i nadpisać dla pojedynczej wiadomości; wygasłe wiadomości są przenoszone do kolejki utraconych wiadomości lub odrzucane, w zależności od konfiguracji. Czas trwania blokady (lock duration) kontroluje, jak długo wiadomość pozostaje zablokowana na czas przetwarzania; SDK może automatycznie odnawiać blokady dla długotrwałych zadań w ramach maksymalnych limitów. Maksymalna liczba dostarczeń (max delivery count) jest konfigurowana dla każdej kolejki lub subskrypcji; po tej liczbie prób dostarczenia (w wyniku operacji Abandon lub utraty blokady) wiadomość jest automatycznie przenoszona do kolejki utraconych wiadomości (DLQ). Operatorzy opróżniają kolejkę DLQ w celach diagnostycznych lub w celu ponownego przetworzenia wiadomości z zastosowaniem logiki naprawczej.

Azure Queue Storage to prostsza, masowo skalowalna usługa kolejek z interfejsem REST, idealna do podstawowego oddzielania komponentów (decoupling), scenariuszy o wysokim stopniu rozproszenia (high fan-out) i obciążeń wrażliwych na koszty. Zapewnia dostarczenie co najmniej raz (at-least-once), limit czasu widoczności (visibility timeout) do ukrywania wiadomości podczas przetwarzania oraz TTL dla każdej wiadomości (domyślnie 7 dni, z możliwością konfiguracji, w tym braku wygasania). Pojedyncze wiadomości mają ograniczony rozmiar, a funkcje takie jak sesje, transakcje, gwarancje kolejności, wykrywanie duplikatów, podkolejki utraconych wiadomości i zaawansowane filtry nie są dostępne. Wybierz Queue Storage do prostych zadań w tle i bardzo wysokiej przepustowości przy niskich kosztach. Wybierz Service Bus, gdy potrzebujesz zaawansowanego routingu (tematy/subskrypcje), kolejności FIFO za pomocą sesji, zaplanowanego dostarczania, odraczania wiadomości, transakcji obejmujących wiele encji, okien do wykrywania duplikatów, wsparcia dla AMQP lub gdy niezawodność i ład integracyjny (governance) mają kluczowe znaczenie. Częstym wzorcem jest zbieranie lekkich zdarzeń za pomocą Event Grid lub Queue Storage i koordynowanie krytycznych dla biznesu poleceń oraz przejść stanów za pomocą Service Bus.

Notification Hubs: Routing powiadomień push i zarządzanie poświadczeniami platformy

Notification Hubs to wieloplatformowy silnik push, który zarządza rejestracjami urządzeń na dużą skalę i kieruje ukierunkowane powiadomienia do platform Apple (APNs), Android (FCM), Windows (WNS) i innych. Aplikacje rejestrują urządzenia za pomocą tagów i wyrażeń tagów, co umożliwia precyzyjny wybór odbiorców (na przykład user:42 AND region:emea OR topic:promotions). Szablony pozwalają wysłać pojedynczy, zlokalizowany ładunek (payload), który jest rozwijany przez renderery specyficzne dla danej platformy, redukując logikę serwera i umożliwiając personalizację dla każdego urządzenia przy minimalnym rozgałęzieniu logiki backendowej. Model instalacji (Installation model) usprawnia zarządzanie cyklem życia urządzenia, hermetyzując uchwyt platformy (platform handle), tagi i szablony w jednym zasobie na urządzenie.

Zarządzanie poświadczeniami platformy ma kluczowe znaczenie dla niezawodnego dostarczania. Dla APNs, prześlij poświadczenia oparte na certyfikacie lub tokenie (z Key ID, Team ID i tokenem .p8) i wybierz punkty końcowe typu sandbox lub produkcyjne dla każdego huba lub przestrzeni nazw, aby odizolować środowiska. Dla FCM, skonfiguruj odpowiednie poświadczenia serwera (dla HTTP v1, użyj konta usługi Google z zakresami OAuth2). Dla WNS, zarejestruj aplikację, aby uzyskać Package SID i klucz tajny klienta (client secret). Poświadczenia są okresowo rotowane; zaplanuj rotację i monitoruj kanały zwrotne pod kątem nieprawidłowych uchwytów urządzeń. Notification Hubs używa SAS do uwierzytelniania na poziomie huba z serwera aplikacji, podczas gdy role Azure AD chronią operacje zarządzania. Używaj konwencji tagowania do partycjonowania aplikacji wielodostępnych (multi-tenant) i ograniczaj wysyłanie za pomocą zaplanowanych lub wsadowych powiadomień push, aby spełnić limity platform.

Praktyczny Scenariusz Problemu

Starbucks wprowadza globalne rozwiązanie do zamawiania mobilnego, które musi powiadamiać klientów o gotowości zamówień, niezawodnie przetwarzać etapy pracy baristy i analizować telemetrię sprzętu w celu proaktywnej konserwacji.

1. Połącz sterowany zdarzeniami cykl życia zamówienia za pomocą Event Grid

• Utwórz niestandardowy temat Event Grid o nazwie OrderEvents i publikuj dyskretne zdarzenia domenowe, takie jak OrderPlaced, PaymentAuthorized i OrderReady. Użyj ścieżek tematu (subject paths) takich jak /stores/{storeId}/orders/{orderId}, aby umożliwić filtrowanie po prefiksie według sklepu. Skonfiguruj subskrypcje: jedną do tematu Service Bus do przetwarzania przepływu pracy i jedną do Azure Function w celu lekkiego wzbogacania danych. Wybrano Event Grid ze względu na niskie opóźnienia przy rozsyłaniu (fan-out), normalizację schematów (CloudEvents) i wydajne filtrowanie, które pozwala uniknąć niepotrzebnych wywołań w dalszych częściach systemu.

2. Koordynuj przepływ pracy baristy za pomocą tematów i sesji Service Bus

• Zdefiniuj temat Service Bus o nazwie Orders z subskrypcjami dla każdego etapu przetwarzania (Preparation, Handoff), każda z filtrami korelacji lub SQL na eventType. Publikuj polecenia jako wiadomości z SessionId = {orderId}, aby zagwarantować kolejność FIFO dla każdego zamówienia. Konsumenci używają trybu PeekLock z automatycznym odnawianiem blokady i wywołują Complete po pomyślnym przetworzeniu; w przypadku przejściowego błędu, Abandon wyzwala ponowienie próby; w przypadku trwałego błędu lub wiadomości zatrutych (poison messages), przekroczenie Max delivery count przenosi je do kolejki utraconych wiadomości (DLQ) w celu późniejszej inspekcji. TTL na wiadomościach specyficznych dla etapu zapobiega przetwarzaniu nieaktualnych zadań po zamknięciu sklepu. Wybrano Service Bus ze względu na uporządkowaną, niezawodną obsługę poleceń, bogate opcje rozliczania wiadomości (settlement) oraz publikowanie/subskrybowanie oparte na regułach.

3. Pozyskuj i archiwizuj telemetrię sprzętu za pomocą Event Hubs

• Zapewnij Event Hub o nazwie Telemetry z wystarczającą liczbą partycji do zrównoleglenia przetwarzania według deviceId i włącz automatyczne skalowanie (auto-inflate) jednostek przepustowości (TU), aby absorbować skoki obciążenia. Bramy urządzeń wysyłają dane przez AMQP-over-WebSockets, aby efektywnie przechodzić przez korporacyjne serwery proxy. Użyj EventProcessorClient z zapisywaniem punktów kontrolnych (checkpointing) w Blob Storage do uruchamiania wykrywania anomalii i alertów w czasie zbliżonym do rzeczywistego. Włącz funkcję Capture do ADLS Gen2 w celu tworzenia niezmiennych archiwów w formacie Avro, wspierających analizę offline w Synapse. Wybrano Event Hubs ze względu na stałe, wysokoprzepustowe pozyskiwanie danych z trwałymi wskaźnikami (durable offsets) i łatwy eksport do ścieżki zimnej (cold-path).

4. Ukierunkuj powiadomienia push za pomocą Notification Hubs

• Zarejestruj urządzenia mobilne za pomocą modelu instalacji (Installation model), tagując każde z nich user:{userId}, store:{storeId} i tagami platformy. Prześlij poświadczenia tokenowe APNs dla iOS i konto usługi FCM dla Androida; oddziel huby deweloperskie i produkcyjne, aby odizolować poświadczenia i informacje zwrotne. Gdy nadejdą zdarzenia OrderReady, Azure Function wysyła pojedyncze powiadomienie szablonowe do Notification Hubs, adresowane do tagów user:{userId} AND store:{storeId}. Wybrano Notification Hubs ze względu na niezależne od platformy kierowanie, wyrażenia tagów i scentralizowane zarządzanie poświadczeniami na skalę globalną.

5. Zapewnij obserwowalność i odporność

• Skonfiguruj przesyłanie niedostarczalnych zdarzeń (dead-lettering) z Event Grid do kontenera Blob, aby zachować je do celów audytu i ponownego odtworzenia. Monitoruj kolejki DLQ w Service Bus i udostępnij przepływ pracy dla operatora do analizy i ponownego kolejkowania poprawionych wiadomości. Śledź opóźnienie konsumenta (consumer lag) w Event Hubs za pomocą metryk, aby weryfikować działanie punktów kontrolnych i skalować w poziomie procesory, gdy rośnie zaległość. Ta kombinacja zapewnia kompleksową trwałość (end-to-end durability): dostarczanie co najmniej raz (at-least-once) ze ścieżkami ponownego odtwarzania dla wyjątkowych warunków, jednocześnie utrzymując szybką i efektywną kosztowo ścieżkę pomyślną (happy path).

Ta architektura czysto rozdziela zadania: Event Grid napędza reaktywną orkiestrację, Service Bus gwarantuje poprawność i kolejność przepływu pracy, Event Hubs obsługuje ciągłą telemetrię na dużą skalę, a Notification Hubs dostarcza precyzyjne, specyficzne dla platformy powiadomienia dla klientów przy minimalnej złożoności backendu.

← Azure API Management · Wszystkie domeny · Buforowanie →

Przećwicz te pytania → · Testy na czas na ExamRoll.io →

Przeglądaj Microsoft →