Freigeben über

Zuverlässige Ereignisverarbeitung mit Azure-Funktionen und Event Hubs

Erfahren Sie, wie Sie robuste, zuverlässige serverlose Lösungen mit Azure Functions mit Azure Event Hubs-Triggern erstellen. In diesem Artikel werden bewährte Methoden für Prüfpunkte, Fehlerbehandlung und Implementierung von Schaltkreistrennmustern behandelt, um sicherzustellen, dass keine Ereignisse verloren gehen und Ihre ereignisgesteuerten Anwendungen stabil und robust bleiben.

Herausforderungen von Ereignisdatenströmen in verteilten Systemen

Berücksichtigen Sie ein System, das Ereignisse mit einer konstanten Rate von 100 Ereignissen pro Sekunde sendet. Bei dieser Rate können in wenigen Minuten mehrere parallele Instanzen die eingehenden 100 Ereignisse pro Sekunde verarbeiten.

Berücksichtigen Sie jedoch diese Herausforderungen bei der Verarbeitung eines Ereignisdatenstroms:

  • Ein Ereignisherausgeber sendet ein beschädigtes Ereignis.
  • Der Funktionscode trifft auf eine unbehandelte Ausnahme.
  • Ein nachgeschaltetes System wechselt offline und blockiert die Ereignisverarbeitung.

Im Gegensatz zu einem Azure Queue-Speichertrigger, der Nachrichten während der Verarbeitung sperrt, liest Azure Event Hubs pro Partition von einem bestimmten Punkt im Datenstrom. Dieses Leseverhalten, das eher wie ein Videoplayer ist, bietet die gewünschten Vorteile von hohem Durchsatz, mehreren Consumergruppen und Wiedergabefähigkeiten. Ereignisse werden von einem Prüfpunkt vor- oder rückwärts gelesen, aber Sie müssen den Zeiger verschieben, um neue Ereignisse zu verarbeiten. Weitere Informationen finden Sie im Prüfpunkt in der Dokumentation zu Event Hubs.

Wenn Fehler in einem Datenstrom auftreten und Sie den Zeiger nicht voranbringen möchten, wird die weitere Ereignisverarbeitung blockiert. Anders ausgedrückt, wenn Sie den Zeiger anhalten, um Probleme bei der Verarbeitung eines einzelnen Ereignisses zu behandeln, stauen sich die nicht verarbeiteten Ereignisse.

Funktionen vermeiden Deadlocks, indem der Zeiger des Datenstroms unabhängig vom Erfolg oder Fehler immer voranschreitet. Da der Zeiger weiter voranschreitet, müssen Ihre Funktionen ordnungsgemäß mit Fehlern umgehen.

Wie der Event Hubs-Trigger Ereignisse konsumiert

Azure Functions nutzt Ereignisse von einem Event Hub, indem es die folgenden Schritte durchläuft:

  1. Für jede Partition des Event Hubs wird ein Zeiger erstellt und in Azure Storage beibehalten.
  2. Neue Ereignisse werden in einem Batch empfangen (standardmäßig), und der Host versucht, die Funktion auszulösen, die einen Batch von Ereignissen für die Verarbeitung angibt.
  3. Wenn die Funktion die Ausführung abgeschlossen hat, mit oder ohne Ausnahmen, wird der Zeiger erweitert, und ein Prüfpunkt wird im Standardhostspeicherkonto gespeichert.
  4. Wenn Bedingungen verhindern, dass die Funktionsausführung abgeschlossen wird, kann der Host den Zeiger nicht voranstellen. Wenn der Zeiger nicht voranschreiten kann, verarbeiten nachfolgende Ausführungen dieselben Ereignisse erneut.

Dieses Verhalten zeigt einige wichtige Punkte an:

  • Unbehandelte Ausnahmen können dazu führen, dass Ereignisse verloren gehen:

    Funktionsausführungen, bei denen eine Ausnahme ausgelöst wird, führen dazu, dass der Zeiger weiterhin fortschreitet. Das Festlegen einer Wiederholungsrichtlinie oder einer anderen Wiederholungslogik verzögert das Weiterkommen des Zeigers, bis der gesamte Wiederholungsvorgang abgeschlossen ist.

  • Funktionen garantieren eine mindestens einmalige Lieferung.

    Ihr Code und abhängige Systeme müssen möglicherweise berücksichtigen, dass dasselbe Ereignis zweimal verarbeitet werden kann. Weitere Informationen finden Sie unter Entwerfen von Azure-Funktionen für identische Eingaben.

Behandeln von Ausnahmen

Während der gesamte Funktionscode einen Try/Catch-Block auf der höchsten Codeebene enthalten sollte, ist das Vorhandensein eines catch Blocks für Funktionen, die Event Hubs-Ereignisse nutzen, noch wichtiger. Auf diese Weise verarbeitet der catch-Block bei Auftreten einer Ausnahme den Fehler, bevor der Zeiger vorwärtsbewegt wird.

Wiederholungsmechanismen und -richtlinien

Da viele Ausnahmen in der Cloud vorübergehend sind, besteht der erste Schritt bei der Fehlerbehandlung darin, den Vorgang immer erneut zu wiederholen. Sie können integrierte Wiederholungsrichtlinien anwenden oder Ihre eigene Wiederholungslogik definieren.

Wiederholungsrichtlinien

Funktionen stellen integrierte Wiederholungsrichtlinien für Event Hubs bereit. Wenn Sie Wiederholungsrichtlinien verwenden, lösen Sie einfach eine neue Ausnahme aus, und der Host versucht, das Ereignis basierend auf der definierten Richtlinie erneut zu verarbeiten. Für dieses Wiederholungsverhalten ist Version 5.x oder höher der Event Hubs-Erweiterung erforderlich. Weitere Informationen finden Sie unter Wiederholungsrichtlinien.

Benutzerdefinierte Wiederholungslogik

Sie können auch ihre eigene Wiederholungslogik in der Funktion selbst definieren. Sie können beispielsweise eine Richtlinie implementieren, die einem Workflow folgt, der durch die folgenden Regeln veranschaulicht wird:

  • Versuchen Sie, ein Ereignis dreimal zu verarbeiten (möglicherweise mit einer Verzögerung zwischen Wiederholungen).
  • Wenn das Endergebnis aller Wiederholungen ein Fehler ist, fügen Sie ein Ereignis zu einer Warteschlange hinzu, damit die Verarbeitung im Datenstrom fortgesetzt werden kann.
  • Fehlerhafte oder nicht verarbeitete Ereignisse werden später behandelt.

Hinweis

Polly ist ein Beispiel für eine Resilienz- und vorübergehende Fehlerbehandlungsbibliothek für C#-Anwendungen.

Fehler ausserhalb von Ausnahmen

Einige Probleme können auftreten, ohne dass eine Ausnahme ausgelöst wird. Ziehen Sie beispielsweise einen Fall in Betracht, in dem eine Anforderung ausgeht oder die Instanz, in der die Funktion ausgeführt wird, abstürzt. Wenn eine Funktion fehlschlägt, ohne dass eine Ausnahme auftritt, wird der Offsetzeiger nie weiterbewegt. Wenn der Zeiger nicht vorwärtsbewegt wird, liest jede Instanz, die nach einer fehlgeschlagenen Ausführung ausgeführt wird, weiterhin dieselben Ereignisse. Diese Situation stellt eine mindestens einmal Garantie bereit.

Die Sicherheit, dass jedes Ereignis mindestens einmal verarbeitet wird, impliziert, dass einige Ereignisse mehrmals verarbeitet werden können. Ihre Funktions-Apps müssen sich dieser Möglichkeit bewusst sein und müssen auf den Prinzipien der Idempotenz basieren.

Behandeln von Fehlerzuständen

Ihre App kann möglicherweise ein paar Fehler bei der Ereignisverarbeitung akzeptabel bewältigen. Sie sollten jedoch auch darauf vorbereitet sein, beständigen Fehlerzustand zu behandeln, der aufgrund von Fehlern bei der nachgelagerten Verarbeitung auftreten kann. In einem solchen Fehlerzustand, z. B. einem nachgeschalteten Datenspeicher, der offline ist, sollte Ihre Funktion das Auslösen von Ereignissen beenden, bis das System einen fehlerfreien Zustand erreicht.

Muster „Trennschalter“

Wenn Sie das Schaltkreistrennmuster implementieren, kann Ihre App die Ereignisverarbeitung effektiv anhalten und sie zu einem späteren Zeitpunkt fortsetzen, nachdem Probleme behoben wurden.

Es sind zwei Komponenten erforderlich, um einen Schaltkreistrennschalter in einem Ereignisstreamprozess zu implementieren:

  • Ein über alle Instanzen geteilter Zustand, um die Integrität des Zyklus nachzuverfolgen und zu überwachen.
  • Ein primärer Prozess, der den Schaltungszustand entweder open oder closed verwalten kann.

Implementierungsdetails können variieren, aber um den Status zwischen Instanzen freizugeben, benötigen Sie einen Speichermechanismus. Sie können den Zustand in Azure Storage, einem Redis-Cache oder einem anderen beständigen Dienst speichern, auf den von Ihren Funktions-App-Instanzen zugegriffen werden kann.

Sowohl dauerhafte Funktionen als auch Azure Logic Apps bieten Infrastruktur zum Verwalten von Workflows und Schaltkreiszuständen. In diesem Artikel wird beschrieben, wie Sie Logik-Apps verwenden können, um Funktionsausführungen anzuhalten und neu zu starten, sodass Sie die erforderliche Kontrolle zum Implementieren des Circuit Breaker Patterns erhalten.

Definieren eines Fehlerschwellenwerts über Instanzen hinweg

Ein persistierter geteilter externer Zustand ist erforderlich, um die Integrität des Systems zu überwachen, wenn mehrere Instanzen Ereignisse gleichzeitig verarbeiten. Sie können diesen permanenten Zustand dann basierend auf Regeln überwachen, die auf einen Fehlerstatus hinweisen, z. B.:

Wenn mehr als 100 Ereignisfehler innerhalb einer 30-Sekunden-Periode in allen Instanzen auftreten, unterbrechen Sie den Schaltkreis, um das Auslösen neuer Ereignisse zu beenden.

Die Implementierungsdetails für diese Überwachungslogik variieren je nach Ihren spezifischen App-Anforderungen, aber im Allgemeinen müssen Sie ein System erstellen, das:

  1. Protokolliert Fehler in den persistenten Speicher.
  2. Überprüfen Sie die Rollanzahl, wenn neue Fehler protokolliert werden, um festzustellen, ob der Schwellenwert für Ereignisfehler erfüllt ist.
  3. Wenn dieser Schwellenwert erreicht ist, wird ein Ereignis ausgelöst, das dem System mitteilt, den Schaltkreis zu unterbrechen.

Verwalten des Schaltkreiszustands mit Azure Logic Apps

Azure Logic Apps verfügt über integrierte Connectors für verschiedene Dienste, Features und zustandsbehaftete Orchestrierungen, und es ist eine natürliche Wahl, den Schaltkreiszustand zu verwalten. Nachdem Sie erkannt haben, wann ein Schaltkreis unterbrechen muss, können Sie eine Logik-App erstellen, um diesen Workflow zu implementieren:

  1. Auslösen eines Ereignisrasterworkflows, der die Funktionsverarbeitung beendet.
  2. Senden Sie eine Benachrichtigungs-E-Mail, die eine Option zum Neustarten des Workflows enthält.

Informationen zum Deaktivieren und Erneutes Aktivieren bestimmter Funktionen mithilfe von App-Einstellungen finden Sie unter "Deaktivieren von Funktionen in Azure Functions".

Der E-Mail-Empfänger kann die Integrität des Schaltkreises untersuchen und gegebenenfalls den Schaltkreis über einen Link in der Benachrichtigungs-E-Mail neu starten. Wenn der Workflow die Funktion neu startet, werden Ereignisse ab dem letzten Event-Hub-Checkpoint verarbeitet.

Wenn Sie diesen Ansatz verwenden, gehen keine Ereignisse verloren, Ereignisse werden in der Reihenfolge verarbeitet, und Sie können den Schaltkreis so lange wie nötig unterbrechen.

Migrationsstrategien für Event Grid-Trigger

Wenn Sie eine vorhandene Funktions-App zwischen Regionen oder zwischen einigen Plänen migrieren, müssen Sie die App während des Migrationsprozesses neu erstellen. In diesem Fall haben Sie während des Migrationsprozesses möglicherweise zwei Apps, die beide denselben Ereignisdatenstrom verarbeiten und in dasselbe Ausgabeziel schreiben können.

Sie sollten die Verwendung von Consumergruppen in Betracht ziehen, um Ereignisdatenverluste oder Duplizierungen während des Migrationsprozesses zu vermeiden:

  1. Erstellen Sie eine neue Consumergruppe für die neue Ziel-App.

  2. Konfigurieren Sie den Trigger in der neuen App so, dass er diese neue Verbrauchergruppe verwendet.

    Auf diese Weise können beide Apps Ereignisse während der Überprüfung unabhängig voneinander verarbeiten.

  3. Überprüfen Sie, ob die neue App Ereignisse ordnungsgemäß verarbeitet.

  4. Beenden Sie die ursprüngliche App, oder entfernen Sie die Abonnement-/Verbrauchergruppe.

  • Last updated on