Zuverlässige Ereignisverarbeitung mit Azure Functions und Event Hubs

Lernen Sie, wie Sie robuste, zuverlässige serverlose Lösungen bauen, indem Sie Azure Functions mit Azure Event Hubs-Triggern verwenden. Dieser Artikel behandelt bewährte Methoden für Checkpoints, Fehlerbehandlung und die Implementierung von Circuit-Breaker-Mustern, um sicherzustellen, dass Sie keine Ereignisse verlieren und Ihre ereignisgesteuerten Anwendungen stabil und widerstandsfähig 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 Geschwindigkeit können mehrere parallele Instanzen die eingehenden 100 Ereignisse pro Sekunde verbrauchen.

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-Warteschlangenspeicherauslöser, der Nachrichten während der Verarbeitung sperrt, liest Azure Event Hubs pro Partition von einem einzigen Punkt im Datenstrom aus. 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. Mit anderen Worten: Wenn du den Zeiger stoppst, um ein Problem zu bearbeiten, das ein einzelnes Ereignis verarbeitet, beginnen sich die unverarbeiteten Ereignisse anzuhäufen.

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 verarbeitet Ereignisse von einem Ereignis-Hub, indem es die folgenden Schritte durchläuft:

  1. Der Trigger erstellt und speichert einen Zeiger in Azure Storage für jede Partition des Event Hubs.
  2. Der Trigger erhält standardmäßig neue Ereignisse in einem Batch, und der Host versucht, die Funktion auszulösen, wodurch der Batch der Ereignisse zur Verarbeitung bereitgestellt wird.
  3. Wenn die Funktion die Ausführung abgeschlossen hat, mit oder ohne Ausnahmen, schiebt der Trigger den Zeiger weiter und speichert einen Checkpoint im Standard-Host-Speicherkonto.
  4. Wenn Bedingungen verhindern, dass die Funktionsausführung abgeschlossen wird, kann der Host den Zeiger nicht weiterentwickeln. 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 Functions für identische Eingaben.

  • Checkpoint State wird in Azure Storage gespeichert:

    Der Trigger hält den Checkpoint (Verarbeitungszeiger) im Speicherkonto gespeichert, das durch die Einstellung AzureWebJobsStorage der Funktions-App konfiguriert ist. Diese gespeicherte Kontrollpunktreferenz bedeutet:

    • Wenn Sie AzureWebJobsStorage so ändern, dass auf ein anderes Speicherkonto verwiesen wird, beginnt die Funktion die Verarbeitung an einer neuen Position, was dazu führen kann, dass Ereignisse erneut verarbeitet werden.
    • Wenn ein Event Hub gelöscht und neu erstellt wird, wird die Position des Event-Streams (z. B. Sequenznummern und Offsets) zurückgesetzt, während gespeicherte Checkpoint-Referenzen unverändert bleiben. In diesem Szenario verarbeitet die Funktion möglicherweise keine neuen Ereignisse, bis der Checkpoint manuell gelöscht wird.

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. Bei der Verwendung von Retry-Richtlinien eröffnen Sie einfach eine neue Ausnahme 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ärprozess, der den Schaltkreiszustand als 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 Durable Functions 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 enthält integrierte Konnektoren für verschiedene Dienste, Funktionen und zustandsbehaftete Orchestrierungen. Es ist eine naheliegende 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.

Um zu lernen, wie man bestimmte Funktionen mit App-Einstellungen deaktiviert und wieder aktiviert, siehe Wie man Funktionen in Azure Functions deaktiviert.

Der E-Mail-Empfänger kann den Zustand des Stromkreises überprüfen und, wenn angebracht, den Stromkreis über einen Link in der Benachrichtigungs-E-Mail neu starten. Wenn der Workflow die Funktion neu startet, verarbeitet er Ereignisse vom letzten Ereignis-Hub-Checkpoint.

Wenn du diesen Ansatz anwendest, verlierst du keine Ereignisse, bearbeitest die Ereignisse der Reihe nach und kannst den Kreis so lange unterbrechen, wie es nötig ist.

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 vom selben Ereignisstrom konsumieren und zum selben Ausgabeziel schreiben können.

Um Verlust oder Doppelung von Ereignisdaten während des Migrationsprozesses zu vermeiden, sollten Sie die Nutzung von Consumer-Gruppen in Betracht ziehen:

  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.

    Mit diesem Ansatz können beide Apps während der Validierung unabhängig voneinander Ereignisse verarbeiten.

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

  4. Stoppe die Original-App oder entferne ihr Abonnement oder die Nutzergruppe.

  • Last updated on