Dieser Artikel beschreibt die verschiedenen Typen von Nachrichten und die Entitäten, die Teil einer Messaginginfrastruktur sind. Ausgehend von den Anforderungen der einzelnen Nachrichtentypen empfiehlt der Artikel Azure-Messagingdienste. Zu den Optionen gehören Azure Service Bus Messaging, Azure Event Grid und Azure Event Hubs. Einen Produktvergleich finden Sie unter Messaging-Dienste vergleichen.
Auf architektonischer Ebene wird ein Datagramm von einer Entität (Erzeuger) erstellt, um Informationen zu verteilen, damit andere Entitäten (Consumer) informiert sind und entsprechend handeln können. Der Erzeuger und der Consumer können direkt oder optional über eine zwischengeschaltete Entität (Nachrichtenbroker) kommunizieren. Dieser Artikel legt den Schwerpunkt auf asynchrones Messaging unter Verwendung eines Nachrichtenbrokers.
Nachrichten können in zwei Hauptkategorien klassifiziert werden. Wenn der Erzeuger eine Aktion vom Consumer erwartet, ist die betreffende Nachricht ein Befehl. Wenn die Nachricht den Consumer darüber informiert, dass eine Aktion stattgefunden hat, ist die Nachricht ein Ereignis.
Befehle
Der Erzeuger sendet einen Befehl in der Absicht, dass der/die Consumer einen Vorgang im Rahmen einer Geschäftstransaktion ausführt/ausführen.
Ein Befehl ist eine Nachricht mit hohem Stellenwert und muss mindestens einmal übermittelt werden. Wenn ein Befehl verloren geht, schlägt möglicherweise die gesamte Geschäftstransaktion fehl. Außerdem sollte ein Befehl nicht öfter als einmal verarbeitet werden. Denn mehr als einmalige Verarbeitung könnte zu einer fehlerhaften Transaktion führen. Ein Kunde könnte doppelte Bestellungen erhalten oder zweimal abgerechnet werden.
Befehle werden häufig verwendet, um den Workflow einer mehrstufigen Geschäftstransaktion zu verwalten. Abhängig von der Geschäftslogik erwartet der Producer möglicherweise, dass der Consumer die Nachricht bestätigt und die Ergebnisse des Vorgangs meldet. Auf der Grundlage dieses Ergebnisses kann der Producer einen passenden Handlungsablauf wählen.
Events
Ein Ereignis ist ein Nachrichtentyp, den ein Erzeuger auslöst, um Fakten bekanntzugeben.
Der Producer (der in diesem Kontext als Herausgeber bezeichnet wird) hat keine Erwartungen, dass die Ereignisse zu irgendwelchen Aktionen führen.
Interessierte Consumer können abonnieren, nach Ereignissen lauschen und je nach Verwendungsszenario Maßnahmen ergreifen. Ereignisse können mehrere oder auch gar keine Abonnenten haben. Zwei verschiedene Abonnenten können mit verschiedenen Aktionen auf ein Ereignis reagieren, ohne von einander Kenntnis zu haben.
Erzeuger und Consumer sind locker gekoppelt und werden unabhängig voneinander verwaltet. Der Producer erwartet nicht, dass der Consumer ihm das Ereignis bestätigt. Ein Consumer, der kein Interesse mehr an den Ereignissen hat, kann das Abonnement abbestellen, wodurch der Consumer aus der Pipeline entfernt wird, ohne dass sich dies auf den Producer oder die Gesamtfunktionalität des Systems auswirkt.
Es gibt zwei Kategorien von Ereignissen:
Der Erzeuger löst Ereignisse aus, um diskrete Fakten bekanntzugeben. Ein häufiger Anwendungsfall ist die Ereignisbenachrichtigung. Beispielsweise löst Azure Resource Manager Ereignisse aus, wenn er Ressourcen erstellt, ändert oder löscht. Ein Abonnent solcher Ereignisse könnte eine Logik-App sein, die Benachrichtigungs-E-Mails sendet.
Der Erzeuger löst verwandte Ereignisse in einer Abfolge oder einem Strom von Ereignissen verteilt über einen Zeitraum aus. Normalerweise wird ein Datenstrom zur statistischen Auswertung verbraucht. Die Auswertung kann in einem Zeitfenster oder bei Eingang der Ereignisse erfolgen. Telemetriedaten stellen einen gängigen Anwendungsfall dar (z. B. bei der Integritäts- und Auslastungsüberwachung eines Systems). Ein weiterer Fall ist das Streamen von Ereignissen von IoT-Geräten.
Ein gängiges Muster für das Implementieren von Ereignismessaging ist das Herausgeber-Abonnent-Muster.
Rolle und Vorteile eines Nachrichtenbrokers
Ein zwischengeschalteter Nachrichtenbroker bietet unter anderem die Möglichkeit, Nachrichten vom Producer zum Consumer bewegen zu können.
Entkopplung
Ein Nachrichtenbroker entkoppelt den Erzeuger vom Consumer in der Logik, die die Nachrichten erzeugt bzw. verwendet. In einem komplexen Workflow kann der Broker die Entkopplung von Geschäftsvorgängen fördern und die Koordinierung des Workflows unterstützen.
Beispielsweise sind für eine einzelne Geschäftstransaktion verschiedene getrennte Vorgänge erforderlich, die in einer Geschäftslogiksequenz ausgeführt werden. Der Erzeuger gibt einen Befehl aus, der einem Consumer signalisiert, dass er einen Vorgang starten soll. Der Consumer bestätigt die Nachricht in einer separaten Warteschlange, die für das Einstellen von Antworten für den Erzeuger reserviert ist. Erst nach dem Erhalt der Antwort sendet der Producer eine neue Nachricht, um den nächsten Vorgang in der Sequenz zu starten. Ein anderer Consumer verarbeitet diese Nachricht und sendet eine Abschlussnachricht an die Antwortwarteschlange. Mithilfe von Nachrichten koordinieren die Dienste den Workflow der Transaktion untereinander.
Ein Nachrichtenbroker bietet zeitliche Entkopplung. Der Erzeuger und der Consumer brauchen nicht gleichzeitig ausgeführt zu werden. Ein Erzeuger kann eine Nachricht unabhängig von der Verfügbarkeit des Consumers an den Nachrichtenbroker senden. Umgekehrt ist auch der Consumer nicht durch die Verfügbarkeit des Erzeugers eingeschränkt.
Beispielsweise generiert die Benutzeroberfläche einer Web-App Nachrichten und verwendet eine Warteschlange als Nachrichtenbroker. Wenn der Consumer bereit ist, kann er Nachrichten aus der Warteschlange abrufen und Aktionen ausführen. Die zeitliche Entkopplung unterstützt die Reaktionsfähigkeit der Benutzeroberfläche. Sie ist nicht blockiert, während die Nachrichten asynchron verarbeitet werden.
Bestimmte Vorgänge brauchen lange bis zum Abschluss. Nach der Ausgabe eines Befehls sollte der Producer nicht darauf warten müssen, bis der Consumer den Vorgang abgeschlossen hat. Ein Nachrichtenbroker unterstützt die asynchrone Verarbeitung von Nachrichten.
Lastenausgleich
Producer können eine große Anzahl von Nachrichten veröffentlichen, die von vielen Consumern verarbeitet werden. Verwenden Sie einen Nachrichtenbroker, um die Verarbeitung auf die Server zu verteilen und den Durchsatz zu verbessern. Consumer können auf verschiedenen Servern ausgeführt werden, um die Last zu verteilen. Consumer können bei Bedarf dynamisch hinzugefügt oder entfernt werden, um das System aufzuskalieren.
Das Muster konkurrierender Consumer veranschaulicht, wie mehrere Nachrichten gleichzeitig verarbeitet werden, um den Durchsatz zu optimieren, die Skalierbarkeit und Verfügbarkeit zu verbessern und die Workload auszugleichen.
Belastungsausgleich
Das Volumen der vom Erzeuger oder einer Gruppe von Erzeugern generierten Nachrichten kann variieren. Es kann manchmal zu einem großen Volumen kommen, das zu Spitzen bei den Nachrichten führt. Anstatt Consumer hinzuzufügen, um diese Arbeit zu verarbeiten, kann ein Nachrichtenbroker als Puffer fungieren, und Consumer lassen Nachrichten in ihrem eigenen Tempo graduell ablaufen, ohne das System unter Stress zu setzen.
Im Artikel zum Muster für warteschlangenbasierte Lastenausgleiche finden Sie weitere Informationen.
Zuverlässiges Messaging
Ein Nachrichtenbroker hilft dabei, sicherzustellen, dass keine Nachrichten verloren gehen, selbst wenn Fehler in der Kommunikation zwischen dem Erzeuger und dem Consumer auftreten. Der Erzeuger kann Nachrichten auf dem Nachrichtenbroker veröffentlichen, und der Consumer kann sie abrufen, wenn die Kommunikation wieder hergestellt ist. Der Erzeuger ist nicht blockiert, sofern er nicht die Konnektivität mit dem Nachrichtenbroker verliert.
Resilientes Messaging
Ein Nachrichtenbroker kann den Consumern in Ihrem System zu Resilienz verhelfen. Wenn ein Consumer während der Verarbeitung einer Nachricht ausfällt, kann eine andere Instanz des Consumers die betreffende Nachricht verarbeiten. Die erneute Verarbeitung ist möglich, da die Nachricht im Broker dauerhaft erhalten bleibt.
Technologieoptionen für einen Nachrichtenbroker
Azure bietet verschiedene Nachrichtenbrokerdienste, von denen jeder eine Reihe von Features aufweist. Bevor Sie einen Dienst auswählen, bestimmen Sie Absicht und Anforderungen der Nachricht.
Azure Service Bus Messaging
Azure Service Bus Messaging-Warteschlangen eignen sich gut zum Übertragen von Befehlen von Producer an Consumer. Hier finden Sie einige Überlegungen dazu.
Pull-Modell
Ein Consumer einer Service Bus-Warteschlange ruft den Service Bus ständig ab, um zu prüfen, ob neue Nachrichten verfügbar sind. Die Client-SDKs und Azure Functions-Trigger für Service Bus abstrahieren dieses Modell. Wenn eine neue Nachricht verfügbar ist, wird die Rückruffunktion des Consumers aufgerufen, und die Nachricht wird an den Consumer gesendet.
Garantierte Übermittlung
Service Bus ermöglicht es einem Consumer, die Warteschlange einzusehen und eine Nachricht für andere Consumer zu sperren.
Es liegt in der Verantwortung des Consumers, den Verarbeitungsstatus der Nachricht zu melden. Erst wenn der Consumer die Nachricht als verarbeitet meldet, wird sie von Service Bus aus der Warteschlange entfernt. Bei Auftreten eines Fehlers, Timeouts oder Absturzes hebt Service Bus die Sperre der Nachricht auf, so dass andere Consumer sie abrufen können. Auf diese Weise gehen keine Nachrichten bei der Übertragung verloren.
Ein Erzeuger sendet eine Nachricht möglicherweise versehentlich zweimal. Beispielsweise tritt bei einer Producerinstanz nach dem Senden einer Nachricht ein Fehler auf. Ein neuer Erzeuger ersetzt die ursprüngliche Instanz und sendet die Nachricht noch einmal. Azure Service Bus-Warteschlangen bieten eine integrierte Deduplizierungsfunktion, die doppelte Nachrichten erkennt und entfernt. Es besteht trotzdem noch die Möglichkeit, dass eine Nachricht zweimal übermittelt wird. Wenn beispielsweise ein Consumer während der Verarbeitung ausfällt, wird die Nachricht an die Warteschlange zurückgegeben und von dem gleichen oder einem anderen Consumer abgerufen. Die Logik zur Nachrichtenverarbeitung im Consumer sollte idempotent sein, sodass sich der Zustand des Systems auch dann nicht ändert, wenn die Arbeit wiederholt wird.
Nachrichtensortierung
Wenn Sie möchten, dass Consumer die Nachrichten in der Reihenfolge erhalten, in der sie gesendet werden, garantieren Service Bus-Warteschlangen mithilfe von Sitzungen eine Übermittlung in FIFO-Reihenfolge (First-In-First-Out). Eine Sitzung kann eine oder mehrere Nachrichten enthalten. Die Nachrichten werden mit der Eigenschaft SessionID korreliert. Nachrichten, die Teil einer Sitzung sind, laufen nie ab. Eine Sitzung kann für einen Consumer gesperrt werden, um zu verhindern, dass die Nachrichten von einem anderen Consumer verarbeitet werden.
Weitere Informationen finden Sie unter Nachrichtensitzungen.
Nachrichtenpersistenz
Service Bus-Warteschlangen unterstützen zeitliche Entkopplung. Selbst wenn kein Consumer verfügbar ist oder die Nachricht verarbeiten kann, verbleibt sie in der Warteschlange.
Prüfpunkte für Transaktionen mit langer Ausführungsdauer
Die Ausführung von Geschäftstransaktionen kann längere Zeit in Anspruch nehmen. Jeder Vorgang in einer Transaktion kann mehrere Nachrichten aufweisen. Verwenden Sie Prüfpunkte, und sorgen Sie für Resilienz für den Fall eines Fehlers bei einer Transaktion.
Service Bus-Warteschlangen ermöglichen mithilfe der Sitzungszustandsfunktion das Festlegen von Prüfpunkten. Zustandsinformationen werden für Nachrichten, die zu einer Sitzung gehören, in der Warteschlange inkrementell aufgezeichnet (SetState). Beispielsweise kann ein Consumer den Fortschritt nachverfolgen, indem er von Zeit zu Zeit den Zustand überprüft (GetState). Beim Ausfall eines Consumers kann ein anderer Consumer die Zustandsinformationen verwenden, um den letzten bekannten Prüfpunkt zu bestimmen und die Sitzung fortzusetzen.
Warteschlange für unzustellbare Nachrichten (Dead-Letter Queue, DLQ)
Eine Service Bus-Warteschlange weist standardmäßig eine Unterwarteschlange auf, die als Warteschlange für unzustellbare Nachrichten (Dead Letter Queue, DLQ) bezeichnet wird und Nachrichten enthält, die nicht übermittelt oder verarbeitet werden konnten. Service Bus oder die Logik zur Nachrichtenverarbeitung im Consumer können der DLQ Nachrichten hinzufügen. Die DLQ bewahrt die Nachrichten auf, bis sie aus der Warteschlange abgerufen werden.
Dies sind Beispiele dafür, wann eine Nachricht in der DLQ enden kann:
Eine nicht verarbeitbare Nachricht ist eine Nachricht, die nicht verarbeitet werden kann, da sie ein ungültiges Format aufweist oder unerwartete Informationen enthält. In Service Bus Warteschlangen lassen sich nicht verarbeitbare Nachrichten durch Festlegen der maxdeliverycount-Eigenschaft der Warteschlange erkennen. Wenn die Häufigkeit, mit der dieselbe Nachricht empfangen wird, den Eigenschaftswert überschreitet, verschiebt Service Bus die Nachricht in die DLQ.
Eine Nachricht ist unter Umständen nicht mehr relevant, wenn sie nicht innerhalb eines bestimmten Zeitraums verarbeitet wird. Service Bus-Warteschlangen ermöglichen es dem Erzeuger, Nachrichten mit einem Time-to-Live-Attribut zu senden. Wenn dieser Zeitraum abläuft, bevor die Nachricht empfangen wurde, wird die Nachricht in der DLQ abgelegt.
Untersuchen Sie die Nachrichten in der DLQ, um den Grund für den Fehler zu bestimmen.
Hybridlösung
Service Bus schlägt eine Brücke zwischen lokalen Systemen und Cloudlösungen. Lokale Systeme sind aufgrund von Firewalleinschränkungen oftmals schwierig zu erreichen. Sowohl Erzeuger als auch Consumer (beide können lokal oder in der Cloud gehostet sein) können den Endpunkt der Service Bus-Warteschlange als Abhol- und Ablageort für Nachrichten verwenden.
Das Messaging Bridge-Muster ist eine weitere Möglichkeit, mit diesen Szenarios zu arbeiten.
Themen und Abonnements
Service Bus unterstützt das Herausgeber-Abonnent-Muster in Form von Service Bus-Themen und -Abonnements.
Diese Funktion bietet dem Erzeuger die Möglichkeit, Nachrichten an mehrere Consumer zu senden. Wenn ein Thema eine Nachricht empfängt, wird sie an alle abonnierten Consumer weitergeleitet. Optional kann ein Abonnement Filterkriterien aufweisen, die es dem Consumer ermöglichen, eine Teilmenge der Nachrichten zu erhalten. Jeder Consumer ruft Nachrichten aus einem Abonnement in ähnlicher Weise wie aus einer Warteschlange ab.
Weitere Informationen finden Sie in den Azure Service Bus-Themen.
Azure Event Grid
Azure Event Grid empfiehlt sich für diskrete Ereignisse. Event Grid folgt dem Herausgeber-Abonnent-Muster. Wenn Ereignisquellen Ereignisse auslösen, werden sie in den Event Grid-Themen veröffentlicht. Consumer dieser Ereignisse erstellen Event Grid-Abonnements durch Angeben von Ereignistypen und Ereignishandlern zur Verarbeitung der Ereignisse. Wenn keine Abonnenten vorhanden sind, werden die Ereignisse verworfen. Für jedes Ereignis können mehrere Abonnements bestehen.
Push-Modell
Event Grid gibt Nachrichten in einem Push-Modell an die Abonnenten weiter. Angenommen, Sie verfügen über ein Event Grid-Abonnement mit einem Webhook. Wenn ein neues Ereignis eintrifft, sendet Event Grid das Ereignis an den Webhook-Endpunkt.
In Azure AD integriert
Wählen Sie Event Grid, wenn Sie Benachrichtigungen zu Azure-Ressourcen erhalten möchten. Viele Azure-Dienste fungieren als Ereignisquellen, die über integrierte Event Grid-Themen verfügen. Event Grid unterstützt darüber hinaus verschiedene Azure-Dienste, die als Ereignishandler konfiguriert werden können. Es ist einfach, diese Themen zu abonnieren, um Ereignisse an die Ereignishandler Ihrer Wahl weiterzuleiten. Beispielsweise können Sie Event Grid wählen, um eine Azure-Funktion aufzurufen, wenn ein Blobspeicher erstellt oder gelöscht wird.
Benutzerdefinierte Themen
Erstellen Sie benutzerdefinierte Event Grid-Themen, wenn Sie Ereignisse von Ihrer Anwendung oder einem Azure-Dienst senden möchten, der nicht mit Event Grid integriert ist.
Um beispielsweise den Fortschritt einer Geschäftstransaktion im Ganzen anzuzeigen, sollten die teilnehmenden Dienste Ereignisse auslösen, während sie ihre einzelnen Geschäftsvorgänge verarbeiten. Diese Ereignisse werden in einer Web-App angezeigt. Eine Möglichkeit besteht darin, ein benutzerdefiniertes Thema zu erstellen und ein über einen HTTP-Webhook registriertes Abonnement für Ihre Web-App hinzuzufügen. Wenn Geschäftsdienste Ereignisse an das benutzerdefinierte Thema senden, überträgt Event Grid sie per Push an Ihre Web-App.
Gefilterte Ereignisse
Sie können Filter in einem Abonnement angeben, um Event Grid anzuweisen, nur eine Teilmenge von Ereignissen an einen bestimmten Ereignishandler zu routen. Sie geben die Filter im Abonnementschema an. Alle Ereignisse, die mit Werten an das Thema gesendet werden, die mit dem Filter übereinstimmen, werden automatisch an das betreffende Abonnement weitergeleitet.
Beispielsweise werden Inhalte in verschiedenen Formaten auf Blob Storage hochgeladen. Jedes Mal, wenn eine Datei hinzugefügt wird, wird ein Ereignis ausgelöst und in Event Grid veröffentlicht. Das Ereignisabonnement könnte beispielsweise einen Filter aufweisen, der nur Ereignisse für Bilder sendet, sodass ein Ereignishandler Miniaturansichten generieren kann.
Weitere Informationen über Filterung finden Sie unter Filtern von Ereignissen für Event Grid.
Hoher Durchsatz
Event Grid kann 10.000.000 Ereignisse pro Sekunde und Region routen. Die ersten 100.000 Vorgänge pro Monat sind kostenlos. Informationen zu den anfallenden Kosten finden Sie unter Was kostet Event Grid?
Resiliente Übermittlung
Zwar ist die erfolgreiche Übermittlung für Ereignisse nicht gleichermaßen kritisch wie für Befehle, trotzdem möchten Sie, abhängig vom Ereignistyp, wohl eine Form von Garantie haben. Event Grid bietet Funktionen, die Sie aktivieren und anpassen können, wie etwa Wiederholungsrichtlinien, Ablaufzeiten und Verarbeitung unzustellbarer Nachrichten. Weitere Informationen finden Sie unter Event Grid – Nachrichtenübermittlung und -wiederholung.
Der Wiederholungsprozess von Event Grid kann die Resilienz erhöhen, ist aber nicht ausfallsicher. Im Rahmen des Wiederholungsvorgangs übermittelt Event Grid die Nachricht möglicherweise mehr als einmal und überspringt oder verzögert manche Wiederholungsversuche, wenn der Endpunkt für eine lange Zeit nicht reagiert. Weitere Informationen finden Sie unter Wiederholungszeitplan.
Sie können nicht übermittelte Ereignisse dauerhaft in einem Blob-Speicherkonto aufbewahren, indem Sie die Verarbeitung unzustellbarer Nachrichten aktivieren. Es gibt eine Verzögerung bei der Übermittlung der Nachricht an den Blob-Speicherendpunkt, und wenn dieser Endpunkt nicht reagiert, verwirft Event Grid das Ereignis. Weitere Informationen finden Sie unter Festlegen eines Speicherorts und einer Wiederholungsrichtlinie für unzustellbare Nachrichten.
Azure Event Hubs
Bei Verwendung eines Ereignisdatenstroms empfiehlt sich Azure Event Hubs als Nachrichtenbroker. Im Wesentlichen handelt es sich um einen großen Puffer, der große Datenmengen mit geringer Latenz empfangen kann. Die empfangenen Daten können durch gleichzeitige Vorgänge schnell gelesen werden. Sie können die empfangenen Daten mithilfe beliebiger Echtzeitanalyse-Anbieter transformieren. Event Hubs bietet außerdem die Möglichkeit, Ereignisse in einem Speicherkonto zu speichern.
Schnelle Datenerfassung
Mit Event Hubs können Millionen Ereignisse pro Sekunde erfasst werden. Die Ereignisse werden lediglich an den Stream angehängt und sind nach Zeit geordnet.
Pull-Modell
Wie Event Grid bietet auch Event Hubs Herausgeber-Abonnent-Funktionen. Ein wichtiger Unterschied zwischen Event Grid und Event Hubs besteht in der Weise, wie Daten den Abonnenten zur Verfügung gestellt werden. Event Grid pusht die erfassten Daten an die Abonnenten, während Event Hubs die Daten in einem Pull-Modell zur Verfügung stellt. Empfangene Ereignisse werden von Event Hubs an den Datenstrom angehängt. Ein Abonnent verwaltet seinen Cursor und kann sich im Datenstrom vorwärts und rückwärts bewegen, einen Zeitoffset auswählen und eine Sequenz in seinem eigenen Tempo wiedergeben.
Datenstromprozessoren sind Abonnenten, die Daten zum Zweck der Transformation und statistischen Analyse bei Event Hubs abrufen. Verwenden Sie für komplexe Verarbeitung, wie etwa Aggregation über Zeitfenster oder Anomalieerkennung Azure Stream Analytics und Apache Spark.
Wenn Sie partitionsweise zu jedem Ereignis aktiv werden möchten, können Sie die Daten mithilfe von Event Processor Host oder eines integrierten Connectors wie Azure Logic Apps abrufen, um die Transformationslogik bereitzustellen. Eine weitere Möglichkeit besteht in der Verwendung von Azure Functions.
Partitionierung
Eine Partition ist ein Teil des Ereignisdatenstroms. Die Ereignisse werden mithilfe eines Partitionsschlüssels aufgeteilt. Beispielsweise senden mehrere IoT-Geräte Gerätedaten an einen Event Hub. Der Partitionsschlüssel ist die Geräte-ID. Während die Ereignisse erfasst werden, verschiebt Event Hubs sie in separate Partitionen. Innerhalb der einzelnen Partitionen sind alle Ereignisse der Zeit nach geordnet.
Ein Consumer ist eine Codeinstanz, die die Ereignisdaten verarbeitet. Event Hubs folgt dem Muster „Partitionierter Consumer“. Jeder Consumer liest nur eine bestimmte Partition. Das Arbeiten mit mehreren Partitionen führt zu einer schnelleren Verarbeitung, da der Datenstrom gleichzeitig von mehreren Consumern gelesen werden kann.
Instanzen des gleichen Consumers bilden eine einzelne Consumergruppe. Mehrere Consumergruppen können den gleichen Datenstrom mit unterschiedlichen Absichten lesen. Angenommen, ein Ereignisdatenstrom weist Daten von einem Temperatursensor auf. Eine Consumergruppe kann den Datenstrom lesen, um Anomalien wie eine Temperaturspitze zu erkennen. Eine andere kann den gleichen Stream lesen, um eine gleitende Durchschnittstemperatur in einem Zeitfenster zu berechnen.
Event Hubs unterstützt das Herausgeber-Abonnent-Muster, indem es mehrere Consumergruppen zulässt. Jede Consumergruppe ist ein Abonnent.
Weitere Informationen zur Event Hubs-Partitionierung finden Sie unter Partitionen.
Event Hubs Capture
Mithilfe der Capture-Funktion können Sie den Ereignisdatenstrom in einer Azure Blob Storage- oder Data Lake Storage-Instanz speichern. Dieses Verfahren zum Speichern von Ereignissen ist zuverlässig, denn selbst wenn das Speicherkonto nicht verfügbar ist, hebt Capture Ihre Daten eine Zeit lang auf und schreibt sie dann in den Speicher, wenn er verfügbar ist.
Speicherdienste können außerdem zusätzliche Funktionen zum Analysieren von Ereignissen bieten. Wenn Sie beispielsweise die Zugriffsebenen eines Blob-Speicherkontos nutzen, können Sie Ereignisse in einer heißen Speicherebene speichern, wenn auf die betreffenden Daten häufig zugegriffen werden muss. Sie können diese Daten beispielsweise zur Visualisierung verwenden. Alternativ können Sie Daten in der Archivebene speichern und sie gelegentlich zu Überprüfungszwecken abrufen.
Capture speichert alle Ereignisse, die von Event Hubs erfasst werden, und ist für Batchverarbeitung nützlich. Sie können Berichte zu den Daten mithilfe einer MapReduce-Funktion generieren. Erfasste Daten können auch als Quelle der Wahrheit dienen. Wenn beim Aggregieren der Daten bestimmte Fakten ausgelassen wurden, können Sie sich auf die erfassten Daten beziehen.
Details zu dieser Funktion finden Sie unter Erfassen von Ereignissen über Azure Event Hubs in Azure Blob Storage oder Azure Data Lake Storage.
Unterstützung für Apache Kafka-Clients
Event Hubs stellt einen Endpunkt für Apache Kafka-Clients bereit. Vorhandene Clients können ihre Konfiguration so aktualisieren, das sie auf den Endpunkt verweist und mit dem Senden von Ereignissen an Event Hubs beginnen. Sie müssen keine Änderungen am Code vornehmen.
Weitere Informationen finden Sie unter Event Hubs für Apache Kafka.
Crossoverszenarien
In manchen Fällen ist es vorteilhaft, zwei Messagingdienste zu kombinieren.
Durch Kombinieren von Diensten kann die Effizienz Ihres Messagingsystems gesteigert werden. Beispielsweise verwenden Sie in Ihrer Geschäftstransaktion Azure Service Bus-Warteschlangen zum Verarbeiten von Nachrichten. Warteschlangen, die sich größtenteils im Leerlauf befinden und nur gelegentlich Nachrichten empfangen, sind ineffizient, da der Consumer die Warteschlange ständig nach neuen Nachrichten abfragt. Sie können ein Event Grid-Abonnement mit einer Azure-Funktion als Ereignishandler einrichten. Jedes Mal, wenn die Warteschlange eine Nachricht empfängt und keine Consumer lauschen, sendet Event Grid eine Benachrichtigung, die die Azure-Funktion aufruft, die die Warteschlange leert.
Details zum Verbinden von Service Bus mit Event Grid finden Sie in der Übersicht über die Integration von Azure Service Bus in Event Grid.
Die Referenzarchitektur unter Unternehmensintegration mithilfe von Nachrichtenbrokern und Ereignissen veranschaulicht eine Implementierung der Integration von Service Bus in Event Grid.
Weiteres Beispiel: Event Grid empfängt eine Reihe von Ereignissen, von denen einige einen Workflow erfordern, während andere der Benachrichtigung dienen. Die Nachrichtenmetadaten geben den Ereignistyp an. Eine Möglichkeit zur Unterscheidung besteht darin, die Metadaten unter Verwendung der Filterfunktion im Ereignisabonnement zu überprüfen. Wenn ein Workflow erforderlich ist, sendet Event Grid das Ereignis an die Azure Service Bus-Warteschlange. Die Empfänger dieser Warteschlange können die erforderlichen Aktionen einleiten. Die Benachrichtigungsereignisse werden an Logic Apps gesendet, um E-Mails zu senden.
Verwandte Muster
Ziehen Sie beim Implementieren von asynchronem Messaging diese Muster in Betracht:
- Muster „Konkurrierende Consumer“: Möglicherweise müssen mehrere Consumer um das Lesen von Nachrichten aus einer Warteschlange konkurrieren. Dieses Muster veranschaulicht, wie mehrere Nachrichten parallel verarbeitet werden, um den Durchsatz zu optimieren, um Skalierbarkeit und Verfügbarkeit zu verbessern und die Workload auszugleichen.
- Muster „Prioritätswarteschlange“: In Fällen, in denen die Geschäftslogik die Verarbeitung mancher Nachrichten vor anderen erfordert, beschreibt dieses Muster, wie von einem Producer veröffentlichte Nachrichten mit einer höheren Priorität von einem Consumer schneller empfangen und verarbeitet werden können als Nachrichten mit geringerer Priorität.
- Muster „Warteschlangenbasierter Lastenausgleich“: Dieses Muster verwendet einen Nachrichtenbroker, um als Puffer zwischen einem Erzeuger und einem Consumer zu fungieren, um für beide Entitäten den Einfluss auf Verfügbarkeit und Reaktionsfähigkeit bei zeitweilig hoher Auslastung zu minimieren.
- Wiederholungsmuster: Ein Producer oder Consumer kann möglicherweise keine Verbindung mit einer Warteschlange herstellen, die Gründe für diesen Fehler können jedoch vorübergehend sein und schnell überwunden werden. Das Muster beschreibt, wie Sie diese Situation behandeln, um die Resilienz einer Anwendung zu erhöhen.
- Scheduler Agent Supervisor-Muster. Messaging wird oftmals als Teil einer Workflowimplementierung verwendet. Dieses Muster zeigt, wie Messaging zur übergreifenden Koordination einer Reihe von Aktionen über eine verteilte Menge von Diensten und anderen Remoteressourcen verwendet werden und einem System das Wiederherstellen und Wiederholen von fehlgeschlagenen Aktionen ermöglichen kann.
- Choreographiemuster. Dieses Muster zeigt, wie-Dienste Messaging verwenden können, um den Workflow einer Geschäftstransaktion zu steuern.
- Claim Check-Muster: Dieses Muster zeigt, wie eine große Nachricht in eine Anspruchsprüfung und eine Nutzlast aufgeteilt wird.
Communityressourcen
Blogbeitrag von Jonathon Oliver: Idempotecy (Idempotenz)
Blogbeitrag von Martin Fowler: What do you mean by "Event-Driven"?