Microsoft AZ-204: Azure: Ereignis- und nachrichtenbasierte Lösungen — Lernleitfaden

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

Teil des Microsoft Azure Developer Associate AZ-204 — Lernleitfaden. Üben Sie mit verifizierten Antworten im Microsoft-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Das Portfolio von Azure für Events und Messaging umfasst vier komplementäre Dienste: Event Grid für reaktive Ereignisverarbeitung, Event Hubs für die Erfassung von Streaming-Daten mit hohem Durchsatz, Service Bus für Enterprise-Messaging und Workflow-Koordination und Notification Hubs für mobile Push-Benachrichtigungen. Um sie zu beherrschen, muss man die Kernabstraktionen, die Semantik für Zustellung und Wiederholungsversuche, die Skalierungsmodelle jedes Dienstes kennen und wissen, wann man einen Dienst gegenüber einem anderen in typischen Anwendungsmustern wie Pub/Sub, Befehlsverarbeitung, Telemetrieerfassung und Geräte- oder Benutzerbenachrichtigungen bevorzugen sollte.

Event Grid: Topics, Subscriptions, Schema, Filtering und Dead-Lettering

Event Grid ist eine vollständig verwaltete, Push-basierte Pub/Sub-Fabric für diskrete Ereignisse. Publisher senden Ereignisse an ein Topic; Abonnenten registrieren Ereignisabonnements (Event Subscriptions) für ein Topic und empfangen passende Ereignisse an unterstützten Handlern wie HTTPS-Webhooks, Azure Functions, Logic Apps, Service Bus, Storage Queues und Event Hubs. Event Grid definiert zwei Publisher-Modelle. System-Topics sind von Azure verwaltete Topic-Ressourcen, die Erstanbieter-Azure-Dienste repräsentieren, die Ereignisse innerhalb Ihres Abonnements oder Ihrer Ressourcengruppe veröffentlichen (z. B. Erstellen eines Storage-Blobs, Rotation eines Key Vault-Geheimnisses oder Resource Manager-Ereignisse). Benutzerdefinierte Topics (Custom Topics) sind vom Benutzer erstellte Topic-Endpunkte, an die Ihre Anwendungen veröffentlichen, was ereignisgesteuerte Muster über Ihre eigenen Dienste und Domänen hinweg ermöglicht. System-Topics erfordern keinen Publisher-Code und vereinfachen die Verknüpfung von Azure-Ressourcen mit reaktiven Handlern; benutzerdefinierte Topics geben Ihnen die volle Kontrolle über Ereignisverträge (Event Contracts) und den Lebenszyklus.

Event Grid-Ereignisse können das native Event Grid-Schema oder die CloudEvents v1.0-Spezifikation verwenden. Mit dem Event Grid-Schema enthält jedes Ereignis id (eindeutiger Bezeichner), eventType (die Aktion), subject (hierarchischer Pfad, der Filterung unterstützt), eventTime (UTC), data (Nutzlast), dataVersion, metadataVersion und topic. CloudEvents bietet einen standardisierten Satz von Attributen wie id, source, type, time, subject und data. Die Wahl von CloudEvents erleichtert die Interoperabilität zwischen Plattformen; das Event Grid-Schema wahrt die Parität mit von Azure stammenden Ereignissen und ermöglicht eine umfangreiche Filterung nach dem subject.

Ereignisabonnements (Event Subscriptions) definieren Routing, Zustelloptionen und Filter. Einfache Filter umfassen die Einbeziehung von Ereignistypen und Subjekt-Präfixe/Suffixe (subjectBeginsWith, subjectEndsWith), die für die hierarchische Benennung von Ressourcen effizient sind. Erweiterte Filter prüfen Felder im Top-Level-Ereignis oder innerhalb der Daten (zum Beispiel numerische Bereichsvergleiche, contains für Zeichenfolgen ohne Berücksichtigung der Groß-/Kleinschreibung, equals für boolesche Werte und contains für Arrays). Sie können Filter für eine präzise Fan-Out-Steuerung kombinieren, um nachgelagerte Arbeit und ausgehenden Datenverkehr (Egress) zu minimieren.

Die Zustellung erfolgt per Push mit At-least-once-Semantik. Event Grid führt Wiederholungsversuche mit exponentiellem Backoff durch. Sie können die maximale Anzahl von Wiederholungsversuchen und die Gültigkeitsdauer (Time-to-Live) des Ereignisses konfigurieren; wenn die Zustellung endgültig fehlschlägt oder das Ereignis veraltet, kann Event Grid das Ereignis in einen Blob Storage-Container, den Sie im Abonnement festlegen, als unzustellbare Nachricht (Dead-Letter) ablegen. Das Dead-Lettering bewahrt Nutzlasten und Metadaten für Auditing oder Wiederverarbeitung auf; verwenden Sie bei Bedarf einen separaten Prozess, um Ereignisse wiederherzustellen (rehydrate) und erneut abzuspielen (replay). Webhook-Endpunkte nehmen an einem Validierungs-Handshake teil, um den Besitz nachzuweisen. Für eingeschränkte Netzwerke können Sie verwaltete Azure-Endpunkte (Functions, Service Bus, Storage Queue) bevorzugen, die keine öffentliche Erreichbarkeit benötigen und eine durch Azure AD gestützte Autorisierung verwenden können.

Event Hubs: Partitionen, Consumergruppen, Durchsatz, Erfassung und zuverlässiger Konsum

Event Hubs erfasst hochvolumige Telemetrie- und Protokolldatenströme mit geringer Latenz. Daten werden an Partitionen angehängt, bei denen es sich um unabhängige, geordnete Commit-Protokolle handelt. Partitionen werden bei der Erstellung ausgewählt, um den Durchsatz zu parallelisieren; Produzenten weisen einen Partitionsschlüssel zu, um die Reihenfolge pro Schlüssel beizubehalten, und der Dienst hasht die Schlüssel auf die Partitionen. Mehrere Leser können Partitionen parallel verarbeiten; innerhalb einer Partition ist die Reihenfolge garantiert.

Consumergruppen bieten unabhängige Sichten auf den Stream und ermöglichen es verschiedenen Verarbeitungsanwendungen, ihre eigenen Positionen beizubehalten, ohne sich gegenseitig zu stören (z. B. eine Echtzeit-Anomalieerkennung und eine Archivierungs-Pipeline). Die horizontale Skalierung von Lesern erfordert einen Ausgleich des Partitionsbesitzes; der EventProcessorClient des SDKs koordiniert die Zuweisung und Neugewichtung von Partitionen über Instanzen hinweg.

Durchsatzeinheiten (Throughput Units, TUs) im Standard-Tarif definieren die Kapazität: Jede TU berechtigt zu Ingress- und Egress-Bandbreitenkontingenten. Auto-Inflate kann TUs automatisch hochskalieren, um Spitzenlasten zu bewältigen. Premium verwendet Verarbeitungseinheiten (Processing Units) mit dedizierter Rechenleistung und vorhersagbarer Latenz. Überwachen Sie Metriken zur Drosselung, um die Bereitstellung zu validieren. Event Hubs unterstützt das Kafka-Protokoll auf demselben Endpunkt, was das Lift-and-Shift von Kafka-Clients vereinfacht, ohne dass Broker betrieben werden müssen.

Produzenten können AMQP oder HTTPS verwenden. AMQP (einschließlich AMQP-over-WebSockets auf Port 443) bietet gemultiplexte, persistente Verbindungen und effizientes Batching und wird sowohl für das Senden als auch für das Empfangen empfohlen. HTTPS eignet sich für einfache oder sporadische Sendevorgänge, wird aber für den Empfang nicht unterstützt; Long-Polling ist nicht verfügbar, und man verzichtet auf Effizienz und Flusskontrolle. In restriktiven Unternehmensnetzwerken erhält AMQP-over-WebSockets die Leistung, während es typische Outbound-Proxys passiert.

Checkpointing und die Offset-Verwaltung sind für die Korrektheit entscheidend. Jedes Ereignis hat eine Sequenznummer und einen Offset pro Partition. Empfänger bewegen sich durch den Stream vorwärts, und nachdem sie einen Batch erfolgreich verarbeitet haben, speichern sie ihre Position als Checkpoint in einem dauerhaften Speicher – üblicherweise ein Azure Blob Storage-Container über den EventProcessorClient. Bei einem Neustart oder Failover setzt der Prozessor die Verarbeitung am letzten Checkpoint fort, wodurch mit idempotenten Handlern eine Mindestens-einmal-Verarbeitung (at-least-once processing) erreicht wird. Ohne Checkpoints starten Consumer von einer Standardposition (neueste oder früheste) und riskieren, Ereignisse erneut zu verarbeiten oder zu überspringen.

Die Erfassung (Capture) bietet eine serverseitige Archivierung, indem sie automatisch gebündelte, nur anfügbare Avro-Dateien nach einem konfigurierbaren Zeit- oder Größenfenster in Azure Blob Storage oder Azure Data Lake Storage Gen2 schreibt. Dies eliminiert die Notwendigkeit benutzerdefinierter Batch-Prozesse für die Cold-Path-Analyse und ermöglicht nachgelagerten Tools (Spark, Synapse), unveränderliche Stream-Segmente mit Genau-einmal-Semantik (exactly-once semantics) in Bezug auf die Capture-Pipeline zu konsumieren.

Service Bus und Queue Storage: Befehle, Workflows, Sitzungen und Poison-Handling

Service Bus ist ein Nachrichtenbroker auf Unternehmensniveau für Befehle, Workflows und Integrationsszenarien, die umfassende Zustellungsgarantien erfordern. Queues implementieren Punkt-zu-Punkt-Messaging; ein konkurrierender Consumer empfängt jede Nachricht. Topics mit Subscriptions ermöglichen Pub/Sub: Publisher senden an ein Topic, und unabhängige Subscriptions erhalten Kopien basierend auf Regeln. Abonnementregeln können SQL-Filter, Korrelationsfilter oder boolesche True-Filter sein, die die Aufnahme pro Nachricht berechnen und über Aktionen Nachrichteneigenschaften hinzufügen oder ändern können.

Sitzungen (Sessions) bieten eine geordnete, exklusive Verarbeitung für zusammengehörige Nachrichten. Weisen Sie Nachrichten, die zusammengehören (zum Beispiel alle Schritte in Bestellung 123), eine SessionId zu. Ein Empfänger akzeptiert die Sitzungssperre und verarbeitet die Nachrichten in der Reihenfolge ihres Eingangs für diese Sitzung, wobei er optional den Sitzungszustand beibehält, und gibt die Sitzung dann frei, damit der nächste Consumer sie übernehmen kann. Dies ist das bevorzugte Muster für FIFO bei Skalierung. Ohne Sitzungen ist die Reihenfolge über konkurrierende Consumer hinweg nicht garantiert.

Service Bus unterstützt die Modi PeekLock und ReceiveAndDelete. PeekLock ist der Standard für Zuverlässigkeit: Ein Consumer sperrt eine Nachricht für die Dauer der Sperre, verarbeitet sie und schließt sie dann mit Complete ab. Wenn die Verarbeitung fehlschlägt, kann der Consumer die Nachricht mit Abandon (macht sie wieder verfügbar), Defer (verschiebt den Abruf auf später anhand der Sequenznummer) oder Dead-letter (verschiebt sie in die separate Dead-Letter-Subqueue der Entität mit Grund und Fehlerbeschreibung) behandeln. ReceiveAndDelete tauscht Zuverlässigkeit gegen Durchsatz, indem die Nachricht sofort nach dem Empfang entfernt wird.

Wichtige Eigenschaften steuern den Lebenszyklus. Die Time to Live (TTL) kann als Standard für die Entität festgelegt und pro Nachricht überschrieben werden; abgelaufene Nachrichten werden je nach Konfiguration in die Dead-Letter-Queue verschoben oder verworfen. Die Lock Duration (Sperrdauer) steuert, wie lange eine Nachricht für die Verarbeitung gesperrt bleibt; das SDK kann Sperren für lang andauernde Aufgaben innerhalb maximaler Grenzen automatisch erneuern. Die maximale Zustellungsanzahl (Max Delivery Count) wird pro Warteschlange oder Abonnement konfiguriert; nach so vielen Zustellversuchen (durch Abandon oder Verlust der Sperre) wird die Nachricht automatisch in die Dead-Letter-Queue (DLQ) verschoben. Operatoren leeren die DLQ für die Diagnose oder zur Wiederverarbeitung mit korrigierender Logik.

Azure Queue Storage ist ein einfacherer, massiv skalierbarer Warteschlangendienst mit einer REST-Schnittstelle, der sich am besten für einfache Entkopplung, hohen Fan-Out und kostensensible Workloads eignet. Er bietet eine Mindestens-einmal-Zustellung (At-least-once Delivery), ein Sichtbarkeits-Timeout (Visibility Timeout), um Nachrichten während der Verarbeitung auszublenden, und eine TTL pro Nachricht (Standard 7 Tage, konfigurierbar, einschließlich niemals ablaufend). Einzelne Nachrichten sind in ihrer Größe begrenzt, und Funktionen wie Sitzungen, Transaktionen, Reihenfolgen-Garantien, Duplikaterkennung, Dead-Letter-Subqueues und erweiterte Filter sind nicht verfügbar. Wählen Sie Queue Storage für einfache Hintergrundarbeiten und sehr hohen Durchsatz bei niedrigen Kosten. Wählen Sie Service Bus, wenn Sie anspruchsvolles Routing (Topics/Subscriptions), FIFO über Sitzungen, geplante Zustellung, Zurückstellung (Deferral), entitätsübergreifende Transaktionen, Fenster zur Duplikaterkennung, AMQP-Unterstützung benötigen oder wenn Zuverlässigkeit und Governance bei der Integration wichtig sind. Ein gängiges Muster ist das Zusammenführen (Fan-In) von einfachen Ereignissen über Event Grid oder Queue Storage und die Koordination von geschäftskritischen Befehlen und Zustandsübergängen auf Service Bus.

Notification Hubs: Push-Routing und Verwaltung von Plattform-Anmeldeinformationen

Notification Hubs ist eine plattformübergreifende Push-Engine, die Geräteregistrierungen in großem Umfang verwaltet und gezielte Benachrichtigungen an Apple (APNs), Android (FCM), Windows (WNS) und andere Plattformen weiterleitet. Anwendungen registrieren Geräte mithilfe von Tags und Tag-Ausdrücken, was eine präzise Zielgruppenauswahl ermöglicht (zum Beispiel user:42 AND region:emea OR topic:promotions). Vorlagen (Templates) ermöglichen es Ihnen, eine einzige, lokalisierte Nutzlast (Payload) zu senden, die plattformspezifische Renderer erweitern. Dies reduziert die Serverlogik und ermöglicht eine gerätespezifische Personalisierung mit minimaler Verzweigung im Backend. Das Installationsmodell (Installation model) optimiert die Verwaltung des Gerätelebenszyklus, indem es Plattform-Handle, Tags und Vorlagen in einer einzigen Ressource pro Gerät kapselt.

Die Verwaltung der Plattform-Anmeldeinformationen ist entscheidend für eine zuverlässige Zustellung. Laden Sie für APNs zertifikat- oder tokenbasierte Anmeldeinformationen (mit Key ID, Team ID und .p8-Token) hoch und wählen Sie Sandbox- oder Produktions-Endpunkte pro Hub oder Namespace, um Umgebungen zu trennen. Konfigurieren Sie für FCM die entsprechenden Server-Anmeldeinformationen (verwenden Sie für HTTP v1 ein Google-Dienstkonto mit OAuth2-Scopes). Registrieren Sie für WNS die App, um die Package SID und das Client Secret zu erhalten. Anmeldeinformationen werden regelmäßig rotiert; planen Sie die Rotation und überwachen Sie die Feedback-Kanäle auf ungültige Geräte-Handles. Notification Hubs verwendet SAS für die Authentifizierung auf Hub-Ebene von Ihrem App-Server aus, während Azure AD-Rollen die Verwaltungsvorgänge schützen. Verwenden Sie Tagging-Konventionen, um mandantenfähige Apps zu partitionieren, und drosseln Sie den Versand mit geplanten oder gebündelten Pushes, um die Plattformkontingente einzuhalten.

Praktisches Problemszenario

Starbucks führt ein globales mobiles Bestellerlebnis ein, das Kunden benachrichtigen muss, wenn Bestellungen fertig sind, die Arbeitsschritte der Baristas zuverlässig verarbeiten und die Telemetrie der Geräte für eine proaktive Wartung analysieren muss.

1. Verknüpfen des ereignisgesteuerten Bestelllebenszyklus mit Event Grid

• Erstellen Sie ein benutzerdefiniertes Event Grid-Thema (Topic) OrderEvents und veröffentlichen Sie diskrete Domänenereignisse wie OrderPlaced, PaymentAuthorized und OrderReady. Verwenden Sie Subjektpfade wie /stores/{storeId}/orders/{orderId}, um eine Präfixfilterung nach Filiale zu ermöglichen. Konfigurieren Sie Abonnements (Subscriptions): eines für ein Service Bus-Thema zur Workflow-Verarbeitung und eines für eine Azure Function zur einfachen Anreicherung von Daten. Event Grid wird aufgrund seines latenzarmen Fan-Outs, der Schemanormalisierung (CloudEvents) und der effizienten Filterung, die unnötige nachgelagerte Aufrufe vermeidet, ausgewählt.

2. Koordinieren des Barista-Workflows mit Service Bus-Themen und -Sitzungen

• Definieren Sie ein Service Bus-Thema Orders mit Abonnements pro Verarbeitungsstufe (Vorbereitung, Übergabe), jeweils mit Korrelations- oder SQL-Filtern für eventType. Veröffentlichen Sie Befehle als Nachrichten mit SessionId = {orderId}, um FIFO pro Bestellung zu garantieren. Consumer verwenden PeekLock mit automatischer Sperrverlängerung und Complete bei Erfolg; bei vorübergehenden Fehlern löst Abandon einen Wiederholungsversuch aus; bei dauerhaften Fehlern oder fehlerhaften Nachrichten (Poison Messages) verschiebt die maximale Zustellungsanzahl (Max delivery count) diese zur späteren Überprüfung in die DLQ (Dead-Letter Queue). Eine TTL für stufenspezifische Nachrichten verhindert veraltete Arbeit nach Geschäftsschluss. Service Bus wird für die geordnete, zuverlässige Befehlsverarbeitung, das umfassende Settlement und das regelbasierte Pub/Sub-Modell ausgewählt.

3. Erfassen und Archivieren von Gerätetelemetrie mit Event Hubs

• Stellen Sie einen Event Hub Telemetry mit ausreichend Partitionen bereit, um nach deviceId zu parallelisieren, und aktivieren Sie die automatische Skalierung (Auto-Inflate) von TUs, um Lastspitzen abzufangen. Geräte-Gateways senden über AMQP-over-WebSockets, um Unternehmensproxys effizient zu durchqueren. Verwenden Sie den EventProcessorClient mit Blob Storage-Checkpointing, um Anomalieerkennung und Alarmierung nahezu in Echtzeit durchzuführen. Aktivieren Sie Capture nach ADLS Gen2 für unveränderliche Avro-Archive, die Offline-Analysen in Synapse unterstützen. Event Hubs wird für die nachhaltige Erfassung mit hohem Durchsatz, dauerhaften Offsets und dem einfachen Export für den Cold Path ausgewählt.

4. Gezielte Push-Benachrichtigungen mit Notification Hubs

• Registrieren Sie mobile Geräte über das Installationsmodell (Installation model) und versehen Sie jedes mit den Tags user:{userId}, store:{storeId} und Plattform-Tags. Laden Sie APNs-Token-Anmeldeinformationen für iOS und das FCM-Dienstkonto für Android hoch; trennen Sie Entwicklungs- und Produktions-Hubs, um Anmeldeinformationen und Feedback zu isolieren. Wenn OrderReady-Ereignisse eintreffen, sendet die Azure Function eine einzelne Vorlagenbenachrichtigung an Notification Hubs, die an die Tags user:{userId} AND store:{storeId} adressiert ist. Notification Hubs wird für das plattformunabhängige Routing, die Tag-Ausdrücke und die zentralisierte Verwaltung von Anmeldeinformationen in globalem Maßstab ausgewählt.

5. Sicherstellen von Beobachtbarkeit und Resilienz

• Konfigurieren Sie das Dead-Lettering von Event Grid in einen Blob-Container, um unzustellbare Ereignisse für Audits und zur Wiederholung aufzubewahren. Überwachen Sie die Service Bus DLQs und stellen Sie einen Operator-Workflow bereit, um korrigierte Nachrichten zu sichten und erneut in die Warteschlange zu stellen. Verfolgen Sie die Verzögerung der Event Hubs-Consumer (Consumer Lag) über Metriken, um das Checkpointing zu validieren und die Prozessoren aufzuskalieren, wenn der Rückstand wächst. Diese Kombination bietet durchgängige Dauerhaftigkeit (End-to-End Durability): mindestens einmalige Zustellung (At-least-once Delivery) mit Wiederholungspfaden für Ausnahmesituationen, während der „Happy Path“ schnell und kosteneffizient bleibt.

Diese Architektur trennt die Verantwortlichkeiten sauber: Event Grid steuert die reaktive Orchestrierung, Service Bus garantiert die Korrektheit und Reihenfolge des Workflows, Event Hubs verarbeitet kontinuierliche Telemetriedaten in großem Umfang und Notification Hubs liefert präzise, plattformspezifische Kundenbenachrichtigungen mit minimaler Komplexität im Backend.

← Azure API Management · Alle Domänen · Azure Caching →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Microsoft durchsuchen →