Integrieren von Event Hubs in serverlose Funktionen in Azure

Lösungen, die Azure Event Hubs zusammen mit Azure Functions verwenden, profitieren von einer serverlosen Architektur, die skalierbar, kostengünstig und in der Lage ist, große Datenmengen nahezu in Echtzeit zu verarbeiten. Zwar arbeiten diese Dienste maximal nahtlos zusammen, doch gibt es viele Features, Einstellungen und Komplexitäten, die ihre Beziehung miteinander komplexer machen. Dieser Artikel enthält Anleitungen dazu, wie Sie diese Integration effektiv nutzen können, indem wichtige Überlegungen und Methoden hinsichtlich Leistung, Resilienz, Sicherheit, Einblicken und Skalierung beleuchtet werden.

Kernkonzepte von Event Hubs

Azure Event Hubs ist ein hochskalierbarer Ereignisverarbeitungsdienst, der Millionen von Ereignissen pro Sekunde empfangen kann. Bevor Sie sich mit den Mustern und bewährten Methoden für die Azure Functions-Integration intensiver beschäftigen, sollten Sie zunächst die grundlegenden Komponenten von Event Hubs verstehen.

Das folgende Diagramm zeigt die Datenstromverarbeitungsarchitektur von Event Hubs:

Ereignisse

Ein Ereignis ist eine Benachrichtigung oder Zustandsänderung, die als in der Vergangenheit geschehener Fakt dargestellt wird. Ereignisse sind in einem Event Hub unveränderlich und persistent, was in Kafka auch als Thema bezeichnet wird. Ein Event Hub besteht aus mindestens einer Partition.

Partitionen

Wenn vom Absender keine Partition angegeben wird, werden empfangene Ereignisse auf Partitionen im Event Hub verteilt. Jedes Ereignis wird in genau eine Partition geschrieben, und es erfolgt kein partitionsübergreifendes Multicasting. Jede Partition funktioniert als Protokoll, in dem Datensätze in einem „Nur Anfügen“-Muster geschrieben werden. Die Analogie eines Commitprotokolls wird häufig verwendet, um zu beschreiben, wie Ereignisse am Ende einer Sequenz in einer Partition hinzugefügt werden.

Wenn mehr als eine Partition verwendet wird, können parallele Protokolle innerhalb desselben Event Hubs verwendet werden. Dieses Verhalten bietet mehrere Grade an Parallelität und erhöht den Durchsatz für Consumer.

Consumer und Consumergruppen

Eine Partition kann von mehr als einem Consumer genutzt werden, von dem jeder seine eigenen Offsets liest und verwaltet.

Bei Event Hubs gibt es das Konzept der Consumergruppen, das es ermöglicht, dass mehrere verarbeitende Anwendungen jeweils eine separate Ansicht des Ereignisdatenstroms aufweisen und den Datenstrom unabhängig voneinander in einem unabhängigen Tempo und mit eigenen Offsets lesen.

Weitere Informationen finden Sie unter Ausführliche Informationen zu Event Hubs-Konzepten und -Funktionen.

Nutzen von Ereignissen mit Azure Functions

Azure Functions unterstützt Trigger- und Ausgabebindungen für Event Hubs. In diesem Abschnitt wird beschrieben, Azure Functions auf Ereignisse reagiert, die mithilfe von Triggern an einen Event Hub-Ereignisstream gesendet werden.

Jede Instanz einer von Event Hubs ausgelösten Funktion wird durch eine einzelne EventProcessorHost-Instanz unterstützt. Der (auf Event Hubs basierende) Trigger stellt sicher, dass nur eine EventProcessorHost-Instanz eine Lease für eine bestimmte Partition erhalten kann.

Betrachten Sie beispielsweise einen Event Hub mit den folgenden Merkmalen:

• 10 Partitionen.
• 1\.000 gleichmäßig auf alle Partitionen verteilte Ereignisse mit einer schwankenden Anzahl von Nachrichten in jeder Partition.

Wenn Ihre Funktion zum ersten Mal aktiviert wird, gibt es nur eine Instanz der Funktion. Wir nennen die erste Funktionsinstanz Function_1. Function_1 umfasst eine einzelne Instanz von EventProcessorHost mit einer Lease auf allen zehn Partitionen. Diese Instanz liest Ereignisse von den Partitionen 1–10. Von diesem Punkt an wird eines der folgenden Ereignisse eintreten:

• Es sind keine neuen Funktionsinstanzen erforderlich: Function_1 kann alle 1.000 Ereignisse verarbeiten, bevor die Skalierungslogik von Functions einsetzt. In diesem Fall werden alle 1.000 Nachrichten von Function_1 verarbeitet.

  

• Eine zusätzliche Funktionsinstanz wird hinzugefügt: Die ereignisbasierte Skalierung oder eine andere automatisierte oder manuelle Logik bestimmt möglicherweise, dass Function_1 mehr Nachrichten enthält, als sie verarbeiten kann, und erstellt dann eine neue Funktions-App-Instanz (Function_2). Diese neue Funktion umfasst auch eine zugeordnete Instanz von EventProcessorHost. Wenn der zugrunde liegende Event Hub erkennt, dass eine neue Hostinstanz versucht, Nachrichten zu lesen, wird ein Lastenausgleich der Partitionen in den Hostinstanzen vorgenommen. Zum Beispiel können die Partitionen 1–5 zu Function_1 und die Partitionen 6–10 zu Function_2 zugewiesen werden.

  

• N weitere Funktionsinstanzen werden hinzufügt: Wenn die ereignisbasierte Skalierung oder eine andere automatisierte oder manuelle Logik ermittelt, dass sowohl Function_1 als auch Function_2 mehr Nachrichten aufweisen, als sie verarbeiten können, werden neue Function_N-Funktions-App-Instanzen erstellt. Instanzen werden bis zu dem Punkt erstellt, an dem N gleich oder größer als die Anzahl der Event Hub-Partitionen ist. In unserem Beispiel für Event Hubs erneut einen Lastenausgleich für die Partitionen aus, in diesem Fall für die Instanzen Function_1... Function_10.

  

Wenn skaliert wird, können N Instanzen einer Zahl entsprechen, die größer als die Anzahl der Event Hub-Partitionen ist. Diese Situation kann eintreten, während die ereignisgesteuerte Skalierung die Anzahl der Instanzen stabilisiert oder weil eine andere automatisierte oder manuelle Logik mehr Instanzen als Partitionen erstellt hat. In diesem Fall erlangen EventProcessorHost-Instanzen nur Sperren für Partitionen, wenn sie von anderen Instanzen verfügbar gemacht werden, da zu jeder Zeit nur eine Funktionsinstanz aus derselben Consumergruppe auf die Partitionen zugreifen bzw. diese lesen kann, die sie gesperrt hat.

Wenn alle Funktionsausführungen abgeschlossen sind (mit oder ohne Fehler), werden Prüfpunkte dem zugehörigen Speicherkonto hinzugefügt. Wenn die Prüfpunkte erfolgreich erstellt wurden, werden alle 1.000 Nachrichten nie wieder abgerufen.

Dynamische, ereignisbasierte Skalierung ist mit Verbrauchs- und Premium-Plänen von Azure möglich. In Kubernetes gehostete Funktions-Apps können auch den KEDA-Scaler für Event Hubs nutzen. Ereignisbasierte Skalierung ist derzeit nicht möglich, wenn die Funktions-App in einem Dedicated-Plan (App Service) gehostet wird, er es erforderlich macht, dass Sie die richtige Anzahl von Instanzen basierend auf Ihrer Workload bestimmen.

Weitere Informationen finden Sie unter Azure Event Hubs-Bindungen für Azure Functions und Azure Event Hubs-Trigger für Azure Functions.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautor:

• David Barkol | Principal Solution Specialist GBB

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Zugehörige Ressourcen

• Die Überwachung der serverlosen Ereignisverarbeitung bietet eine Anleitung zur Überwachung serverloser, ereignisgesteuerter Architekturen.
• Die serverlose Ereignisverarbeitung ist eine Referenzarchitektur, die eine typische Architektur dieses Typs mit Codebeispielen und einer Erläuterung wichtiger Überlegungen detailliert erläutert.
• Die Debatchierung und Filterung in der serverlosen Ereignisverarbeitung mit Event Hubs beschreibt ausführlicher, wie diese Teile der Referenzarchitektur funktionieren.