Microsoft AZ-305: Architektura integracji i przesyłania komunikatów — Przewodnik do nauki

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

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

Przegląd

Architektura integracji i przesyłania komunikatów na platformie Azure opiera się na wyborze odpowiedniej usługi dla semantyki przenoszenia poleceń, zdarzeń i danych; projektowaniu pod kątem niezawodności, kolejności i skalowalności; oraz bezpiecznej integracji systemów hybrydowych. Podstawowe elementy składowe obejmują Azure Service Bus do komunikacji korporacyjnej z zaawansowanymi brokerami, Azure Event Grid do reaktywnego trasowania zdarzeń, Azure Event Hubs do pozyskiwania strumieniowego o wysokiej przepustowości oraz Storage Queues do prostego kolejkowania. Wokół nich znajdują się Azure Logic Apps do automatyzacji procesów, API Management do zarządzania i poprawy doświadczenia deweloperskiego, Azure Data Factory do procesów ETL/ELT, Azure Relay do łączności z systemami on-premises przyjaznej dla zapór sieciowych oraz Azure Notification Hubs do powiadomień push na urządzenia mobilne. Prawidłowy projekt wykorzystuje odpowiednią usługę do danego zadania, jawnie modeluje kontrakty i tryby awarii oraz stosuje wzorce orkiestracji lub choreografii tam, gdzie jest to właściwe.

Przesyłanie komunikatów i zdarzeń na platformie Azure

Azure Service Bus to broker korporacyjny dla poleceń i przepływów pracy, które wymagają uporządkowanego dostarczania, transakcji, kolejności FIFO w obrębie grup oraz obsługi niedostarczalnych wiadomości (dead-letter handling). Kolejki (Queues) zapewniają komunikację punkt-punkt między jednym producentem a jedną konkurującą grupą konsumentów. Tematy (Topics) umożliwiają komunikację w modelu pub/sub z wieloma niezależnymi subskrypcjami, które mogą filtrować i trasować komunikaty za pomocą filtrów i akcji podobnych do SQL. Sesje wiadomości (Message sessions) grupują powiązane komunikaty pod jednym identyfikatorem sessionId, umożliwiając przetwarzanie FIFO i stanowe dla każdej grupy; blokada sesji (session lock) zapewnia, że tylko jeden konsument przetwarza daną sesję w jednym czasie. Kolejki niedostarczonych wiadomości (Dead-letter queues) przechwytują błędne komunikaty (poison messages), gdy maksymalna liczba prób dostarczenia zostanie przekroczona, upłynie czas życia (TTL) lub gdy wiadomość zostanie jawnie oznaczona jako niedostarczalna, co umożliwia jej kwarantannę i późniejszą inspekcję; każda kolejka lub subskrypcja ma swoją podkolejkę $DeadLetterQueue. Transakcje pozwalają na atomowe operacje wysyłania/odbierania/kończenia (send/receive/complete) na wielu encjach w tej samej przestrzeni nazw, zapewniając na przykład, że wiadomość zostanie zakończona tylko wtedy, gdy kolejne komunikaty zostaną pomyślnie wysłane (mechanizm send-via wspiera przepływy pracy obejmujące wiele encji).

Azure Event Grid to w pełni zarządzany router zdarzeń dla reaktywnych wzorców opartych na mechanizmie push. Wykorzystuje natywny schemat Event Grid lub CloudEvents 1.0. Subskrypcje zdarzeń (Event subscriptions) wskazują na punkty końcowe (endpoints), takie jak Functions, Logic Apps, Service Bus, Event Hubs, WebHooks i Storage Queues, z filtrami tematu (subject) i filtrami zaawansowanymi w celu redukcji szumu. Dostarczanie jest ponawiane z wykładniczym czasem oczekiwania (exponential backoff); subskrypcje obsługują konfigurowalną politykę ponawiania (maksymalna liczba prób dostarczenia i czas życia zdarzenia) i mogą przenosić niedostarczalne zdarzenia na konto Storage. Walidacja typu handshake zabezpiecza punkty końcowe WebHook, a tożsamości zarządzane (managed identities) upraszczają publikowanie i dostarczanie do punktów końcowych na platformie Azure.

Azure Event Hubs pozyskuje dane telemetryczne i strumieniowe na masową skalę za pomocą partycjonowanych logów. Partycje zapewniają równoległość i zachowanie kolejności w obrębie partycji; należy wybrać klucz partycji (partition key), aby powiązane zdarzenia pozostały uporządkowane. Liczba partycji określa skalę i nie może być zmniejszona po utworzeniu, dlatego należy dobrać ją z myślą o przyszłej przepustowości. Grupy konsumentów (Consumer groups) zapewniają niezależne widoki strumienia zdarzeń dla różnych aplikacji, bez wzajemnego zakłócania swoich wskaźników (offsetów). Funkcja Capture trwale przenosi dane do Azure Blob Storage lub Data Lake Storage w czasie zbliżonym do rzeczywistego, w oparciu o okna czasowe lub rozmiarowe, zazwyczaj w formacie Avro, co umożliwia analizę wsadową bez wpływu na proces pozyskiwania danych. Wbudowany Schema Registry przechowuje schematy Avro/JSON z zasadami wersjonowania i kompatybilności, umożliwiając producentom i konsumentom bezpieczne walidowanie i rozwijanie kontraktów.

Storage Queues oferują proste, ekonomiczne dostarczanie typu „co najmniej raz” (at-least-once) z limitami czasu niewidoczności (invisibility timeouts) i podstawową obsługą niedostarczonych wiadomości poprzez TTL komunikatu oraz obsługę błędnych komunikatów (poison handling) zarządzaną przez aplikację. Nie posiadają transakcji, sesji ani zaawansowanego routingu, ale doskonale sprawdzają się do podstawowego oddzielania komponentów (decoupling) i masowej dystrybucji (fan-out) przy niskich kosztach.

Kiedy wybrać którą usługę:

• Użyj Service Bus do poleceń, przepływów pracy i scenariuszy integracyjnych wymagających FIFO (poprzez sesje), transakcji, odraczania, wykrywania duplikatów i audytu niedostarczonych wiadomości.
• Użyj Event Grid do lekkich powiadomień typu push o charakterze fan-out z usług Azure lub aplikacji niestandardowych, z precyzyjnym filtrowaniem i reakcjami w czasie zbliżonym do rzeczywistego.
• Użyj Event Hubs do pozyskiwania strumieniowej telemetrii i logów o wysokiej przepustowości, z niezależnymi konsumentami i dalszą analityką (downstream analytics).
• Użyj Storage Queues do prostego oddzielenia producenta od konsumenta, gdy zaawansowane funkcje brokera nie są konieczne, a priorytetem jest prostota i niski koszt.

Niezawodność i wzorce sterowane zdarzeniami

Projektowanie pod kątem niezawodności zaczyna się od jawnej obsługi błędów. Service Bus udostępnia kolejki niedostarczonych wiadomości (dead-letter queues) dla każdej jednostki; konsumenci powinni monitorować i klasyfikować DLQ, opcjonalnie automatycznie przekazując je do kolejek analitycznych. Używaj wykrywania duplikatów i idempotentnych procedur obsługi, aby uniknąć podwójnego przetwarzania. Wykorzystuj transakcje do atomowego rozliczania odbiorów i wysyłania wiadomości wychodzących (outbox) oraz używaj sesji do uporządkowanego przetwarzania dla każdej jednostki biznesowej, jednocześnie skalując w obrębie sesji. Zasady ponawiania prób w Event Grid wykorzystują wykładniczy backoff z konfigurowalnymi limitami; skonfiguruj kierowanie niedostarczonych wiadomości do Storage w celu zapewnienia audytowalności i zbuduj narzędzia do ponownego odtwarzania (replay). Event Hubs gwarantuje dostarczanie co najmniej raz; tworzenie punktów kontrolnych (checkpointing) za pomocą zestawów SDK (lub wyzwalaczy Azure Functions) zapewnia śledzenie postępów dla każdej partycji/grupy konsumentów. Storage Queues opierają się na limitach czasu widoczności i wzorcach wiadomości zatrutych (poison message), które implementujesz jawnie.

Architektura sterowana zdarzeniami zazwyczaj wykorzystuje choreografię lub orkiestrację. Choreografia rozprasza koordynację pomiędzy usługi reagujące na zdarzenia od innych usług. Jest luźno powiązana, skalowalna i odporna na częściowe awarie, ale może stać się trudna do wizualizacji i zarządzania, a akcje kompensujące są rozproszone. Orkiestracja centralizuje kontrolę przepływu w orkiestratorze, takim jak Azure Durable Functions, Logic Apps lub silnik przepływu pracy, poprawiając obserwowalność, logikę limitów czasu/kompensacji oraz kroki wymagające interwencji człowieka (human-in-the-loop) kosztem ściślejszego powiązania z orkiestratorem. Wzorzec saga implementuje długotrwałe, wieloetapowe transakcje z akcjami kompensującymi zamiast zatwierdzania dwufazowego. W choreografii każda usługa nasłuchuje zdarzeń domenowych i w razie potrzeby emituje kompensacje; w orkiestracjach orkiestrator wywołuje działania i uruchamia kompensacje w przypadku awarii lub przekroczenia limitu czasu. Na platformie Azure sagi można implementować za pomocą Durable Functions (stanowa orkiestracja, ponawianie prób, limity czasu, wzorce kompensacji) z Service Bus do niezawodnego dostarczania poleceń lub za pomocą Logic Apps Standard do solidnych przepływów pracy klasy enterprise z wbudowanymi łącznikami.

Praktyczny scenariusz problemowy

Firma Contoso Retail modernizuje swoje przetwarzanie zamówień obejmujące lokalny system ERP, witrynę e-commerce, aplikacje mobilne i analitykę dalszych etapów (downstream). Rozwiązanie musi obsługiwać powiadomienia dla partnerów, analizę telemetrii w czasie rzeczywistym, bezpieczny dostęp do zasobów lokalnych (on-prem) i powiadomienia push na urządzenia mobilne, z zachowaniem ścisłej kolejności operacji i mechanizmów kompensacji dla płatności i stanów magazynowych.

1. Przepływ pracy poleceń i pozyskiwania danych

• Użyj tematów Azure Service Bus do obsługi poleceń zamówień. Subskrypcje segmentują przetwarzanie (Płatności, Magazyn, Wysyłka). Włącz sesje wiadomości z kluczem OrderId, aby zagwarantować kolejność FIFO i pojedynczą współbieżność dla każdego zamówienia. Uzasadnienie: Service Bus zapewnia sesje, transakcje i obsługę niedostarczonych wiadomości, które są wymagane w uporządkowanych i niezawodnych biznesowych przepływach pracy.

2. Orkiestracja i kompensacje

• Zaimplementuj wzorzec saga za pomocą Azure Durable Functions. Aktywności wywołują bramkę płatności, rezerwują stany magazynowe i tworzą wysyłkę; akcje kompensujące zwracają pieniądze lub uzupełniają zapasy w przypadku awarii. Użyj wyzwalaczy i powiązań wyjściowych Service Bus w ramach zakresów transakcyjnych, aby atomowo finalizować przychodzące wiadomości i publikować kolejne. Uzasadnienie: Scentralizowana orkiestracja upraszcza obsługę limitów czasu, ponownych prób i kompensacji, zachowując jednocześnie niezawodność brokera.

3. Powiadomienia sterowane zdarzeniami

• Publikuj zdarzenia domenowe (OrderPlaced, OrderShipped) do niestandardowych tematów Azure Event Grid. Partnerzy i aplikacje wewnętrzne subskrybują je z filtrami według prefiksu tematu. Skonfiguruj kierowanie niedostarczonych wiadomości na konto Storage oraz zasady ponawiania prób z ograniczoną liczbą prób. Uzasadnienie: Event Grid oferuje dostarczanie typu push o niskim opóźnieniu z precyzyjnym filtrowaniem i audytem niedostarczonych wiadomości dla szerokiej dystrybucji (fan-out).

4. Strumieniowanie telemetrii i analityka

• Wysyłaj dane telemetryczne typu clickstream i z aplikacji do Azure Event Hubs z 8 partycjami kluczowanymi według sesji użytkownika. Włącz funkcję Capture do Data Lake Storage co 5 minut lub 100 MB. Zarejestruj schematy Avro w Schema Registry i wymuszaj zgodność schematów. Uzasadnienie: Event Hubs skaluje pozyskiwanie danych niezależnie od konsumentów; funkcja Capture oddziela analitykę; Schema Registry utrzymuje dyscyplinę kontraktów.

5. Integracja danych

• Użyj Azure Data Factory z Self-hosted Integration Runtime w środowisku lokalnym (on-prem), aby bezpiecznie wyodrębnić dane z systemu ERP, oraz Azure IR, aby umieścić przygotowane dane w Synapse. Zbuduj potoki i przepływy danych mapowania (mapping data flows) do przetwarzania SCD i wzbogacania danymi z plików Event Hubs Capture. Uzasadnienie: ADF orkiestruje hybrydowe przenoszenie i transformacje danych z zarządzanymi zasobami obliczeniowymi i połączeniami kontrolowanymi przez połączone usługi (linked services).

6. Zarządzanie API i partnerami

• Wystaw wszystkie punkty końcowe dla partnerów za pośrednictwem Azure API Management. Udostępnij API do sprawdzania statusu zamówienia i rejestracji webhooków. Zastosuj zasady: validate-jwt do walidacji tokenów wystawionych przez partnerów, rate-limit-by-key do bardziej rygorystycznego ograniczania przepustowości dla partnerów, rewrite/set-backend-service do przekierowywania do istniejących Logic Apps bez zmian w kodzie. Opublikuj produkt dla partnerów wymagający subskrypcji i kluczy; wdrażaj ich przez portal deweloperski. Uzasadnienie: APIM wymusza bezpieczeństwo, ograniczanie przepustowości i zapewnia samoobsługowe wdrażanie partnerów bez ingerencji w logikę backendu.

7. Automatyzacja przepływów pracy i łączniki

• Użyj Azure Logic Apps Standard do automatyzacji procesów back-office (np. wysyłanie e-maili, aktualizacja Dynamics) z wbudowanymi łącznikami i integracją z VNET. Uzasadnienie: Wydajność w modelu single-tenant, prywatna łączność i łączniki klasy enterprise upraszczają integrację z aplikacjami SaaS i biznesowymi (line-of-business).

8. Łączność hybrydowa

• Udostępnij wybrane usługi lokalnego systemu ERP za pomocą Azure Relay WCF Relay dla istniejących punktów końcowych WCF oraz Hybrid Connections dla lekkich aplikacji HTTP/WebSocket, unikając zmian w regułach zapory sieciowej dla ruchu przychodzącego. Uzasadnienie: Relay zapewnia bezpieczną łączność inicjowaną z wewnątrz sieci (outbound) bez złożoności związanej z VPN.

9. Powiadomienia mobilne (push)

• Wysyłaj aktualizacje o wysyłce za pośrednictwem Azure Notification Hubs, używając tagów do segmentacji urządzeń/użytkowników i szablonów do lokalizacji. Skonfiguruj poświadczenia tokenów APNs i klucze FCM. Uzasadnienie: Notification Hubs abstrahuje różnice między platformami PNS i skaluje dostarczanie powiadomień push.

Ten projekt przypisuje każde wymaganie do dedykowanych usług: Service Bus do niezawodnych poleceń, Durable Functions do orkiestrowanych sag, Event Grid do powiadomień push, Event Hubs + Capture + Schema Registry do analityki strumieniowej, ADF do hybrydowego ETL/ELT, APIM do zarządzania, Logic Apps do automatyzacji korporacyjnej, Relay do dostępu do zasobów lokalnych oraz Notification Hubs do angażowania użytkowników mobilnych.

← Architektura bezpieczeństwa i Zero Trust · Wszystkie domeny · Monitorowanie →

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

Przeglądaj Microsoft →