Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Azure bietet mehrere Dienste für die Bereitstellung von Ereignissen und Nachrichten in einer Lösung. Jeder Dienst zielt auf unterschiedliche Szenarien ab, von reaktiver Ereignisrouting bis hin zum Streaming mit hohem Durchsatz bis hin zu Transaktionsnachrichten auf Unternehmensniveau.
In diesem Artikel werden die folgenden Dienste verglichen:
Auswählen eines Kandidatendiensts
In diesem Abschnitt können Sie die in Frage kommenden Dienste für Ihre Anforderungen auswählen.
Verwenden Sie die folgende Tabelle, um schnell einzugrenzen, welcher Dienst zu Ihrem Szenario passt:
| Kriterium | Ereignisraster | Ereignis-Hubs | Dienstbus |
|---|---|---|---|
| Hauptzweck | Reaktives Ereignisrouting | Big Data Streaming und Datenaufnahme | Unternehmenstransaktionsnachrichten |
| Datenmodell | Ereignisse (diskrete Benachrichtigungen) | Ereignisströme (zeitlich geordnete Reihen) | Nachrichten (hochwertige Nutzlasten) |
| Liefergarantie | Mindestens einmal | Mindestens einmal | Mindestens einmal (optional mit Reihenfolge, genau einmal bei Sitzungen) |
| Wann verwenden | Reagieren auf Statusänderungen, serverlose Architekturen | Telemetrie, verteiltes Datenstreaming, Echtzeitanalysen | Auftragsverarbeitung, Finanztransaktionen, Workflows |
Das Ergebnis dieses Abschnitts ist ein Ausgangspunkt für die Berücksichtigung. Verwenden Sie die folgenden Abschnitte, um eine detaillierte Auswertung der Dienste durchzuführen.
Ereignisse im Vergleich zu Nachrichten in Azure Messagingdiensten
Es gibt einen wichtigen Unterschied zwischen Azure Diensten, die ein Ereignis und Dienste liefern, die eine Nachricht liefern.
Ereignis: Eine einfache Benachrichtigung über eine Bedingungs- oder Zustandsänderung. Der Herausgeber erwartet nicht, wie das Ereignis behandelt wird. Ereignisse können diskret sein (melden einer Zustandsänderung, die handlungsfähig ist) oder Teil einer zeitgeordneten Datenreihe (eine Bedingung melden, die analyzierbar ist). Eigenständige Ereignisse eignen sich ideal für serverlose Lösungen, die skaliert werden müssen.
Nachricht: Rohdaten, die von einem Dienst erstellt wurden, die an anderer Stelle genutzt oder gespeichert werden sollen. Die Nachricht enthält die Daten, die die Nachrichtenpipeline ausgelöst haben. Zwischen Herausgeber und Verbraucher besteht ein Vertrag. Beispielsweise sendet der Herausgeber eine Nachricht mit Unformatierten Daten und erwartet, dass der Verbraucher eine Datei aus diesen Daten erstellt und eine Antwort sendet, wenn die Arbeit abgeschlossen ist.
Skalierbarkeit und Durchsatz
In der folgenden Tabelle wird verglichen, wie Azure Event Grid, Azure Event Hubs und Azure Service Bus Skalierbarkeit und Durchsatz behandeln.
| Kriterium | Ereignisraster | Ereignis-Hubs | Dienstbus |
|---|---|---|---|
| Throughput | Dynamisch skalierbar, serverlos | Millionen von Ereignissen pro Sekunde | Zuverlässige asynchrone Übermittlung |
| Latenzmodell | Nah-Echtzeit-Ereignisübermittlung | Streaming mit geringer Latenz | Vermittelt mit optionalem Long Polling |
| Skalierungsmodell | Automatisch (serverlos) | Durchsatzeinheiten/Verarbeitungseinheiten | Nachrichteneinheiten (Premium) |
Nachrichtenfunktionen
In der folgenden Tabelle werden die Messagingfunktionen von Azure Event Grid, Azure Event Hubs und Azure Service Bus verglichen.
| Kriterium | Ereignisraster | Ereignis-Hubs | Dienstbus |
|---|---|---|---|
| Protokoll | MQTT, HTTP | AMQP, Kafka, HTTP | AMQP, HTTP |
| Pub/Sub | Ja (Publish-Subscribe) | Ja (Verbrauchergruppen) | Ja (Themen und Abonnements) |
| Sortieren | Keine Garantie | Pro Partition | FIFO (Sitzungen) |
| Transaktionen | No | No | Ja |
| Duplikaterkennung | No | No | Ja |
| Inaktiver Buchstabe | Ja | No | Ja |
| Batchverarbeitung | Ja | Ja (Ereignisstapel) | Ja (Sitzungen) |
| Aufzeichnung/Wiedergabe | No | Ja (Event Hubs Capture) | No |
Integration und Bereitstellung
In der folgenden Tabelle werden Integrations- und Bereitstellungsoptionen für Azure Event Grid, Azure Event Hubs und Azure Service Bus verglichen.
| Kriterium | Ereignisraster | Ereignis-Hubs | Dienstbus |
|---|---|---|---|
| Azure Dienstintegration | Umfassende Integration in Azure-Dienste und Drittanbieterdienste | Streamverarbeitungsinfrastrukturen und Analysedienste | Unternehmensanwendungen, Hybridcloud, lokale Konnektivität |
| Editionen | Azure Event Grid (PaaS), Event Grid auf Kubernetes mit Azure Arc | Standard, Premium, Dediziert | Basic, Standard und Premium |
Verwenden von Event Grid, Event Hubs und Service Bus zusammen
In manchen Fällen werden Dienste parallel verwendet, um bestimmte Rollen zu erfüllen. Beispielsweise kann eine E-Commerce-Website Service Bus verwenden, um Bestellungen zu verarbeiten, Event Hubs zum Erfassen von Website-Telemetrie und Ereignisraster, um auf Ereignisse wie ein zu versendender Artikel zu reagieren.
In anderen Fällen können die Dienste zu einer Ereignis- und Datenpipeline verknüpft werden. Event Grid wird verwendet, um auf Ereignisse in den anderen Diensten zu reagieren. Ein Beispiel für die Verwendung von Event Grid mit Event Hubs für die Migration von Daten zu Azure Synapse Analytics finden Sie unter Streamen von Big Data in Azure Synapse Analytics. Die folgende Abbildung zeigt den Workflow zum Streamen der Daten:
Zugehöriger Inhalt
- Asynchrone Messagingoptionen in Azure
- Events, Data Points, and Messages - Choosing the right Azure messaging service for your data (Ereignisse, Datenpunkte und Nachrichten: Auswählen des passenden Azure-Messagingdiensts für Ihre Daten)