Dieser Artikel enthält Anleitungen zur Optimierung der Skalierbarkeit und Leistung, wenn Sie Azure Event Hubs und Azure Functions in Ihren Anwendungen zusammen verwenden.
Funktionsgruppierung
In der Regel kapselt eine Funktion eine Arbeitseinheit in einem Ereignisverarbeitungsstream. Beispielsweise kann eine Funktion ein Ereignis in eine neue Datenstruktur transformieren oder Daten für nachgeschaltete Anwendungen anreichern.
In Azure Functions wird mit einer Funktions-App der Ausführungskontext für die einzelnen Funktionen angegeben. Das Verhalten der Funktions-App gilt für alle von einer bestimmten Funktionen-App gehosteten Funktionen. Einzelne Funktionen in einer Funktions-App werden zusammen bereitgestellt und skaliert. Alle Funktionen in einer Funktions-App müssen in der gleichen Sprache geschrieben sein.
Wie Sie Funktionen in Funktions-Apps gruppieren, kann sich auf die Leistung und Skalierungsfunktionen Ihrer Funktions-Apps auswirken. Sie können nach den Zugriffsrechten, der Bereitstellung und den Nutzungsmustern gruppieren, die Ihren Code aufrufen.
Anleitungen zu bewährten Methoden für Funktionen für die Gruppierung und andere Aspekte finden Sie unter Bewährte Methoden für zuverlässigen Azure Functions-Code und Optimieren der Leistung und Zuverlässigkeit von Azure Functions.
Die folgende Liste enthält Anleitungen zum Gruppieren von Funktionen. In der Anleitung werden Aspekte der Speicher- und Consumergruppe berücksichtigt:
Hosten einer einzelnen Funktion in einer Funktions-App: Wenn Event Hubs eine Funktion auslöst, können Sie die Funktion in ihrer eigenen Funktions-App isolieren, um Konflikte zwischen dieser Funktion und anderen Funktionen zu verringern. Die Isolation ist besonders wichtig, wenn die anderen Funktionen CPU- oder arbeitsspeicherintensiv sind. Diese Technik hilft, da jede Funktion über einen eigenen Speicherbedarf und Nutzungsmuster verfügt, die sich direkt auf die Skalierung der Funktions-App auswirken können, die sie hostet.
Separate Speicherkonten für jede Funktions-App: Vermeiden Sie die Freigabe von Speicherkonten zwischen Funktions-Apps. Wenn eine Funktions-App ein Speicherkonto verwendet, verwenden Sie dieses Konto auch nicht für andere Speichervorgänge oder -anforderungen. Es kann besonders wichtig sein, die Freigabe von Speicherkonten für Funktionen zu vermeiden, die von Event Hubs ausgelöst werden, da solche Funktionen aufgrund von Prüfpunkten sehr viele Speichertransaktionen aufweisen können.
Erstellen einer dedizierten Consumergruppe für jede Funktions-App: Eine Consumergruppe ist eine Ansicht eines Event Hubs. Unterschiedliche Consumergruppen haben unterschiedliche Ansichten, was bedeutet, dass sich die Zustände, Positionen und Offsets unterscheiden können. Mithilfe von Consumergruppen können 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 zu Event Hubs finden Sie unter Features und Terminologie in Azure Event Hubs.
Einer Consumergruppe ist mindestens eine Consumeranwendung zugeordnet, und eine Consumeranwendung kann eine oder mehrere Consumergruppen verwenden. In einer Streamverarbeitungslösung entspricht jede Consumeranwendung einer Consumergruppe. Eine Funktions-App ist ein gutes Beispiel für eine Consumeranwendung. Das folgende Diagramm zeigt ein Beispiel für zwei Funktions-Apps, die aus einem Event Hub lesen, wobei jede App über eine eigene dedizierte Consumergruppe verfügt:
Verwenden Sie keine Consumergruppen gemeinsam mit mehreren Funktions-Apps und anderen Consumeranwendungen. Jede Funktions-App sollte eine eigene Anwendung mit einer eigenen zugewiesenen Consumergruppe sein, um die Offsetintegrität für jeden Consumer sicherzustellen und Abhängigkeiten in einer Ereignisstreamingarchitektur zu vereinfachen. Diese Konfiguration stellt nicht nur eine eigene Funktions-App und ein eigenes Speicherkonto für jede vom Event Hub ausgelöste Funktion bereit, sie hilft auch, die Grundlage für optimale Leistung und Skalierung zu legen.
Pläne für das Funktionshosting
Es gibt mehrere Hostingoptionen für Funktions-Apps und es ist wichtig, diese zu überprüfen. Weitere Informationen zu diesen Hostingoptionen finden Sie unter Hostingoptionen für Azure Functions. Notieren Sie sich, wie die Optionen skaliert werden.
Der Verbrauchsplan ist der Standard. Funktions-Apps im Verbrauchsplan werden unabhängig voneinander skaliert und sind am effektivsten, wenn sie zeitintensive Aufgaben vermeiden.
Die Pläne „Premium“ und „Dedicated“ werden häufig verwendet, um mehrere Funktions-Apps und Funktionen zu hosten, die CPU- und arbeitsspeicherintensiver sind. Mit dem Dedicated-Plan führen Sie Ihre Funktionen in einem Azure App Service-Plan zu regulären App Service-Plantarifen aus. Es ist wichtig zu beachten, dass alle Funktions-Apps in diesen Plänen dieselben Ressourcen gemeinsam nutzen, die dem Plan zugeordnet sind. Wenn Funktionen unterschiedliche Auslastungsprofile oder spezifische Anforderungen besitzen, werden diese am besten in verschiedenen Plänen gehostet, insbesondere bei Datenstromverarbeitungsanwendungen.
Azure Container Apps bietet integrierte Unterstützung für die Entwicklung, Bereitstellung und Verwaltung von containerisierten Funktions-Apps in Azure Functions. Auf diese Weise können Sie Ihre ereignisgesteuerten Funktionen in einer vollständig verwalteten, Kubernetes-basierten Umgebung mit integrierter Unterstützung für Open-Source-Überwachung, mTLS, Dapr und KEDA ausführen.
Event Hubs-Skalierung
Wenn Sie einen Event Hubs-Namespace bereitstellen, gibt es mehrere wichtige Einstellungen, die Sie ordnungsgemäß einrichten müssen, um Spitzenleistung und Skalierung sicherzustellen. Dieser Abschnitt konzentriert sich auf die Standardebene von Event Hubs und die einzigartigen Features dieser Ebene, die sich auf die Skalierung auswirken, wenn Sie auch Azure Functions verwenden. Weitere Informationen zu Event Hubs-Ebenen finden Sie unter Vergleich der Ebenen „Basic“, „Standard“, „Premium“ und „Dedicated“.
Ein Event Hubs-Namespace entspricht einem Kafka-Cluster. Informationen zur Beziehung zwischen Event Hubs und Kafka finden Sie unter Worum handelt es sich bei Azure Event Hubs für Apache Kafka.
Grundlegendes zu Durchsatzeinheiten (TUs)
In der Standardebene von Event Hubs wird der Durchsatz als das Datenvolumen klassifiziert, das innerhalb eines bestimmten Zeitraums im Namespace eingeht und daraus gelesen wird. TUs werden vorab als Durchsatzkapazität erworben.
Die Abrechnung von TUs erfolgt auf Stundenbasis.
Alle Event Hubs in einem Namespace teilen sich die TUs. Um den Kapazitätsbedarf ordnungsgemäß zu berechnen, müssen Sie alle Anwendungen und Dienste berücksichtigen, sowohl Herausgeber als auch Consumer. Functions wirken sich auf die Anzahl der Bytes und Ereignisse aus, die in einem Event Hub veröffentlicht und daraus gelesen werden.
Der Schwerpunkt bei der Bestimmung der Anzahl von TUs liegt auf dem Zeitpunkt des Dateneingangs. Das Aggregat für die Consumeranwendungen, einschließlich der Rate, mit der diese Ereignisse verarbeitet werden, muss jedoch ebenfalls in die Berechnung einbezogen werden.
Weitere Informationen zu Event Hubs-Durchsatzeinheiten finden Sie unter Durchsatzeinheiten.
Hochskalieren mit automatischer Vergrößerung
Die automatische Vergrößerung kann für einen Event Hubs-Namespace aktiviert werden, um Situationen zu berücksichtigen, in denen die Auslastung die konfigurierte Anzahl von TUs überschreitet. Die Verwendung der automatischen Vergrößerung verhindert die Drosselung Ihrer Anwendung und trägt dazu bei, dass die Verarbeitung, einschließlich der Erfassung von Ereignissen, ohne Unterbrechungen fortgesetzt wird. Da sich die TU-Einstellung auf die Kosten auswirkt, hilft die Verwendung der automatischen Vergrößerung, Bedenken hinsichtlich der Überbereitstellung auszuräumen.
Die automatische Vergrößerung ist eine einzigartige Funktion von Event Hubs, die häufig mit der Autoskalierung verwechselt wird, insbesondere im Kontext serverloser Lösungen. Im Gegensatz zur Autoskalierung wird bei der automatischen Vergrößerung jedoch nicht herunterskaliert, wenn keine zusätzliche Kapazität mehr benötigt wird.
Wenn die Anwendung Kapazität benötigt, die die maximal zulässige Anzahl TUs überschreitet, sollten Sie die Premium-Ebene oder die Dedicated-Ebene von Event Hubs in Erwägung ziehen.
Partitionen und gleichzeitige Funktionen
Nach der Erstellung eines Event Hubs müssen Sie die Anzahl der Partitionen angeben. Die Partitionsanzahl bleibt fest und kann nur in den Ebenen „Premium“ und „Dedicated“ geändert werden. Wenn Event Hubs Funktions-Apps auslöst, kann die Anzahl gleichzeitiger Instanzen der Anzahl von Partitionen entsprechen.
In Verbrauchs- und Premium-Hostingplänen werden die Funktions-App-Instanzen dynamisch so aufskaliert, dass sie bei Bedarf der Anzahl der Partitionen entsprechen. Der Dedicated-Hostingplan führt Funktionen in einem App Service-Plan aus und erfordert, dass Sie Ihre Instanzen manuell konfigurieren oder ein Schema für die Autoskalierung einrichten. Weitere Informationen finden Sie unter Dedizierte Hostingpläne für Azure Functions.
Letztendlich ist eine 1:1-Beziehung zwischen der Anzahl von Partitionen und den Funktionsinstanzen oder Consumern das ideale Ziel zum Erreichen des maximalen Durchsatzes in einer Streamverarbeitungslösung. Um eine optimale Parallelität zu erzielen, müssen mehrere Consumer in einer Consumergruppe vorhanden sein. Für Functions bedeutet dies viele Instanzen einer Funktion innerhalb des Plans. Das Ergebnis wird als Parallelität auf Partitionsebene oder als maximaler Grad an Parallelität bezeichnet, wie im folgenden Diagramm dargestellt:
Es kann zunächst sinnvoll erscheinen, so viele Partitionen wie möglich zu konfigurieren, um den maximalen Durchsatz zu erreichen und die Möglichkeit eines höheren Ereignisvolumens zu berücksichtigen. Beim Konfigurieren eine großen Anzahl Partitionen sind jedoch einige wichtige Faktoren zu berücksichtigen:
- Mehr Partitionen können zu höherem Durchsatz führen: Da der Grad der Parallelität der Anzahl der Consumer (Funktionsinstanzen) entspricht, gilt: Je mehr Partitionen vorhanden sind, desto höher kann der gleichzeitige Durchsatz sein. Diese Tatsache ist wichtig, wenn Sie eine bestimmte Anzahl TUs für einen Event Hub mit anderen Consumeranwendungen gemeinsam nutzen.
- Mehr Funktionen benötigen möglicherweise mehr Arbeitsspeicher: Mit Zunahme der Anzahl von Funktionsinstanzen erhöht sich auch der Arbeitsspeicherbedarf von Ressourcen innerhalb des Plans. Zu einem bestimmten Zeitpunkt könnten zu viele Partitionen die Leistung für die Consumer verschlechtern.
- Es besteht die Gefahr von Gegendruck durch nachgeschaltete Dienste: Wenn mehr Durchsatz generiert wird, laufen Sie Gefahr, nachgelagerte Dienste zu überfordern oder von ihnen Gegendruck zu erhalten. Das Auffächern von Consumern muss berücksichtigt werden, wenn die Konsequenzen erwogen werden, die dies für die umgebenden Ressourcen haben kann. Mögliche Folgen waren Drosselung durch andere Dienste, Netzwerksättigung und andere Formen von Ressourcenkonflikten.
- Partitionen können eine weit verteilte Belegung aufweisen: Die Kombination aus vielen Partitionen und einem niedrigen Ereignisvolumen kann zu Daten führen, die weit über Partitionen verteilt werden. Eine geringere Anzahl von Partitionen kann entsprechend eine bessere Leistung und Ressourcennutzung bieten.
Verfügbarkeit und Konsistenz
Wenn weder ein Partitionsschlüssel noch eine Partitions-ID angegeben wird, leiten die Event Hubs ein eingehendes Ereignis an die nächste verfügbare Partition weiter. Dieser Ansatz bietet Hochverfügbarkeit und hilft, den Durchsatz für Consumer zu erhöhen.
Wenn die Reihenfolge einer Gruppe von Ereignissen erforderlich ist, kann der Ereignisproduzent angeben, dass eine bestimmte Partition für alle Ereignisse der Gruppe verwendet werden soll. Eine Consumeranwendung, die aus derselben Partition liest, kann dann die Ereignisse in der richtigen Reihenfolge verarbeiten. Dieser Kompromiss sorgt für Konsistenz, gefährdet aber die Verfügbarkeit. Verwenden Sie diesen Ansatz nur, wenn die Reihenfolge der Ereignisse beibehalten werden muss.
Bei Functions wird die Sortierung erreicht, wenn Ereignisse in einer bestimmten Partition veröffentlicht werden und eine von Event Hubs ausgelöste Funktion eine Lease für dieselbe Partition erhält. Derzeit wird die Möglichkeit, eine Partition mit der Event Hubs-Ausgabebindung zu konfigurieren, nicht unterstützt. Stattdessen besteht der beste Ansatz darin, eines der Event Hubs SDKs zu verwenden, um in einer bestimmten Partition zu veröffentlichen.
Weitere Informationen darüber, wie Event Hubs Verfügbarkeit und Konsistenz unterstützt, finden Sie unter Verfügbarkeit und Konsistenz in Event Hubs.
Event Hubs-Trigger
Dieser Abschnitt konzentriert sich auf die Einstellungen und Überlegungen zur Optimierung von Funktionen, die von Event Hubs ausgelöst werden. Zu den Faktoren zählen die Batchverarbeitung, die Stichprobenentnahme sowie verwandte Features, die das Verhalten einer Event Hub-Triggerbindung beeinflussen.
Batchverarbeitung für ausgelöste Funktionen
Sie können Funktionen konfigurieren, die ein Event Hub auslöst, um einen Batch von Ereignissen oder jeweils ein Ereignis nacheinander zu verarbeiten. Die Verarbeitung eines Ereignisbatches kann effizienter sein, wenn dadurch bis zu einem gewissen Grad der Mehraufwand für Funktionsaufrufe entfällt. Sofern Sie nicht nur ein einzelnes Ereignis verarbeiten müssen, sollte Ihre Funktion so konfiguriert sein, dass sie bei Aufruf mehrere Ereignisse verarbeitet.
Die Aktivierung der Batchverarbeitung für die Event Hubs-Triggerbindung variiert je nach Sprache:
- JavaScript, Python und andere Sprachen ermöglichen die Batchverarbeitung, wenn die Kardinalitätseigenschaft in der Datei „function.json“ für die Funktion auf many (viele) festgelegt ist.
- In C# ist Kardinalität automatisch konfiguriert, wenn ein Array für den Typ im EventHubTrigger-Attribut festgelegt wird.
Weitere Informationen zur Aktivierung der Batchverarbeitung finden Sie unter Azure Event Hubs-Trigger für Azure Functions.
Triggereinstellungen
Mehrere Konfigurationseinstellungen in der Datei host.json spielen eine wesentliche Rolle für die Leistungsmerkmale der Event Hubs-Triggerbindung für Functions:
- maxEventBatchSize: Diese Einstellung stellt die maximale Anzahl der Ereignisse dar, die die Funktion beim Aufruf empfangen kann. Wenn die Anzahl der empfangenen Ereignisse diesen Wert unterschreitet, wird die Funktion weiterhin mit so vielen Ereignissen aufgerufen, wie verfügbar sind. Sie können keine Mindestbatchgröße festlegen.
- prefetchCount: Eine der wichtigsten Einstellungen bei der Leistungsoptimierung ist die Vorabrufanzahl (prefetch). Der zugrunde liegende AMQP-Kanal verweist auf diesen Wert, um zu bestimmen, wie viele Nachrichten für den Client abgerufen und zwischengespeichert werden sollen. Die Vorabrufanzahl sollte größer als oder gleich dem Wert von maxEventBatchSize sein und wird häufig auf ein Vielfaches dieses Betrags festgelegt. Wenn dieser Wert auf eine niedrigere Zahl als die Einstellung maxEventBatchSize festgelegt wird, kann sich dies nachteilig auf die Leistung auswirken.
- batchCheckpointFrequency: Wenn Ihre Funktion Batches verarbeitet, bestimmt dieser Wert die Rate, mit der Prüfpunkte erstellt werden. Der Standardwert ist 1. Dies bedeutet, dass es immer dann einen Prüfpunkt gibt, wenn eine Funktion einen einzelnen Batch erfolgreich verarbeitet. Für jeden Leser (Reader) in der Consumergruppe wird ein Prüfpunkt auf Partitionsebene erstellt. Informationen dazu, wie diese Einstellung Wiedergaben und Wiederholungen von Ereignissen beeinflusst, finden Sie im Blogbeitrag Event Hub triggered Azure function: Replays and retries.
Führen Sie mehrere Leistungstests durch, um die Werte zu ermitteln, die für die Triggerbindung festgelegt werden sollen. Es wird empfohlen, die Einstellungen inkrementell zu ändern und konsistent zu messen, um diese Optionen zu optimieren. Die Standardwerte sind ein sinnvoller Ausgangspunkt für die meisten Ereignisverarbeitungslösungen.
Setzen von Prüfpunkten
Prüfpunkte markieren oder committen Leserpositionen in einer Partitionsereignissequenz. Es liegt in der Verantwortung des Functions-Hosts, Prüfpunkte zu setzen, wenn Ereignisse verarbeitet werden und die Einstellung für die Häufigkeit von Batchprüfpunkten erfüllt ist. Weitere Informationen zu Prüfpunkten finden Sie unter Features und Terminologie in Azure Event Hubs.
Die folgenden Konzepte können Ihnen helfen, die Beziehung zwischen dem Setzen von Prüfpunkten und der Verarbeitungsweise von Ereignissen durch Ihre Funktion zu verstehen:
- Ausnahmen werden weiterhin als Erfolg gezählt: Wenn der Funktionsprozess während der Verarbeitung von Ereignissen nicht abstürzt, wird der Abschluss der Funktion als erfolgreich betrachtet, auch wenn Ausnahmen aufgetreten sind. Wenn die Funktion abgeschlossen ist, wertet der Funktionshost batchCheckpointFrequency aus. Wenn es Zeit für einen Prüfpunkt ist, wird ein Prüfpunkt erstellt, unabhängig davon, ob Ausnahmen aufgetreten sind. Die Tatsache, dass Ausnahmen sich nicht auf die Prüfpunkterstellung auswirken, sollte sich nicht auf die ordnungsgemäße Verwendung der Ausnahmeprüfung und -behandlung auswirken.
- Die Batchhäufigkeit ist wichtig: Bei Ereignisstreaminglösungen mit hohem Volumen kann es vorteilhaft sein, die batchCheckpointFrequency-Einstellung in einen Wert größer als 1 zu ändern. Das Erhöhen dieses Werts kann die Geschwindigkeit der Prüfpunkterstellung und damit die Anzahl von Speicher-E/A-Vorgängen verringern.
- Wiedergaben können auftreten: Jedes Mal, wenn eine Funktion mit der Event Hubs-Triggerbindung aufgerufen wird, verwendet sie den letzten Prüfpunkt, um zu bestimmen, ab wo die Verarbeitung fortgesetzt werden soll. Der Offset für jeden Consumer wird auf Partitionsebene für jede Consumergruppe gespeichert. Wiedergaben treten auf, wenn während des letzten Aufrufs der Funktion kein Prüfpunkt aufgetreten ist und die Funktion erneut aufgerufen wird. Weitere Informationen zu Duplikaten und Deduplizierungstechniken finden Sie unter Idempotenz.
Das Verständnis von Prüfpunkten hat entscheidende Bedeutung, wenn Sie bewährte Methoden für die Fehlerbehandlung und Wiederholungen in Betracht ziehen, ein Thema, das weiter unten in diesem Artikel erläutert wird.
Erstellen von Telemetriestichproben
Functions bietet integrierte Unterstützung für Application Insights, eine Erweiterung von Azure Monitor, die Funktionen zur Überwachung der Anwendungsleistung bereitstellt. Mit dieser Funktion können Sie Informationen zu Funktionsaktivitäten, Leistung, Laufzeitausnahmen und mehr protokollieren. Weitere Informationen finden Sie unter Übersicht über Application Insights.
Diese leistungsstarke Funktionalität bietet einige wesentliche Konfigurationsoptionen, die sich auf die Leistung auswirken. Einige der wichtigsten Einstellungen und Überlegungen zur Überwachung und Leistung sind:
- Aktivieren der Erstellung von Telemetriestichproben: Für Szenarien mit hohem Durchsatz sollten Sie die Menge an Telemetriedaten und Informationen bewerten, die Sie benötigen. Ziehen Sie in Erwägung, die Funktion für die Telemetrie-Stichprobenentnahme in Application Insights zu nutzen, um eine Verschlechterung der Leistung Ihrer Funktion durch unnötige Telemetriedaten und Metriken zu vermeiden.
- Konfigurieren von Aggregationseinstellungen: Untersuchen und konfigurieren Sie die Häufigkeit, mit der Daten aggregiert und an Application Insights gesendet werden. Diese Konfigurationseinstellung befindet sich in der Datei host.json zusammen mit vielen anderen Optionen für die Stichprobenentnahme und Protokollierung. Weitere Informationen finden Sie unter Konfigurieren des Aggregators.
- Deaktivieren von AzureWebJobDashboard: Bei Apps, die auf Version 1.x der Azure Functions Runtime abzielen, speichert diese Einstellung die Verbindungszeichenfolge für ein Speicherkonto, das vom Azure SDK verwendet wird, um Protokolle für das WebJobs-Dashboard aufzubewahren. Wenn Application Insights anstelle des WebJobs-Dashboards verwendet wird, sollte diese Einstellung entfernt werden. Weitere Informationen finden Sie unter AzureWebJobsDashboard.
Wenn Application Insights ohne Stichprobenentnahme aktiviert ist, werden alle Telemetriedaten gesendet. Das Senden von Daten zu allen Ereignissen kann sich negativ auf die Leistung der Funktion auswirken, insbesondere bei Ereignisstreamingszenarien mit hohem Durchsatz.
Die Nutzung der Stichprobenentnahme und die kontinuierliche Bewertung der angemessenen Menge von Telemetriedaten, die für die Überwachung erforderlich sind, ist wichtig für eine optimale Leistung. Telemetriedaten sollten für die allgemeine Bewertung der Plattformintegrität und für die gelegentliche Problembehandlung verwendet werden und nicht zum Erfassen von Kerngeschäftsmetriken. Weitere Informationen finden Sie unter Konfigurieren des Samplings.
Ausgabebindung
Verwenden Sie die Event Hubs-Ausgabebindung für Azure Functions, um die Veröffentlichung in einem Ereignisstream aus einer Funktion zu vereinfachen. Die Verwendung dieser Bindung bietet u. a. folgende Vorteile:
- Ressourcenverwaltung: Die Bindung verarbeitet sowohl den Client- als auch den Verbindungslebenszyklus für Sie und verringert das Potenzial für Probleme, die bei der Portauslastung und der Verwaltung von Verbindungspools auftreten können.
- Weniger Code: Die Bindung abstrahiert das zugrunde liegende SDK und verringert die Codemenge, die zum Veröffentlichen von Ereignissen erforderlich ist. Sie hilft Ihnen beim Schreiben von Code, der einfacher zu schreiben und zu verwalten ist.
- Batchverarbeitung: Die Batchverarbeitung wird für mehrere Sprachen unterstützt, um effizient in einem Ereignisstream zu veröffentlichen. Die Batchverarbeitung kann die Leistung verbessern und bei der Optimierung des Codes helfen, der die Ereignisse sendet.
Es wird dringend empfohlen, die Liste der von Functions unterstützten Sprachen und die Entwicklerhandbücher für diese Sprachen zu lesen. Im Abschnitt Bindungen der jeweiligen Sprache finden Sie ausführliche Beispiele und Dokumentationen.
Batchverarbeitung beim Veröffentlichen von Ereignissen
Wenn Ihre Funktion nur ein einzelnes Ereignis veröffentlicht, ist das Konfigurieren der Bindung für die Rückgabe eines Werts ein gängiger Ansatz, der hilfreich ist, wenn die Funktionsausführung immer mit einer Anweisung endet, die das Ereignis sendet. Diese Technik sollte nur für synchrone Funktionen verwendet werden, die nur ein Ereignis zurückgeben.
Batchverarbeitung wird empfohlen, um die Leistung beim Senden mehrerer Ereignisse an einen Stream zu verbessern. Die Batchverarbeitung ermöglicht es der Bindung, Ereignisse auf die effizienteste Weise zu veröffentlichen.
Unterstützung für die Verwendung der Ausgabebindung zum Senden mehrerer Ereignisse an Event Hubs ist in C#, Java, Python und JavaScript verfügbar.
Ausgeben mehrerer Ereignisse mit dem In-Process-Modell (C#)
Verwenden Sie die Typen ICollector und IAsyncCollector, wenn Sie mehrere Ereignisse von einer Funktion in C# senden.
- Die Methode ICollector<T>.Add() kann sowohl in synchronen als auch in asynchronen Funktionen verwendet werden. Sie führt den Hinzufügenvorgang (add) aus, sobald sie aufgerufen wird.
- Die Methode IAsyncCollector<T>.AddAsync() bereitet die Ereignisse vor, die im Ereignisstream veröffentlicht werden sollen. Wenn Sie eine asynchrone Funktion schreiben, sollten Sie IAsyncCollector verwenden, um die veröffentlichten Ereignisse besser verwalten zu können.
Beispiele für die Verwendung von C# zum Veröffentlichen einzelner und mehrerer Ereignisse finden Sie unter Azure Event Hubs-Ausgabebindung für Azure Functions.
Ausgeben mehrerer Ereignisse mit dem isolierten Workermodell (C#)
Abhängig von der Version der Functions-Laufzeit unterstützt das isolierte Workermodell unterschiedliche Typen für die Parameter, die an die Ausgabebindung übergeben werden. Bei mehreren Ereignissen wird ein Array verwendet, um den Satz zu kapseln. Es wird empfohlen, die Ausgabebindungsattribute und Nutzungsdetails für das isolierte Modell zu überprüfen und sich die Unterschiede zwischen den Erweiterungsversionen zu notieren.
Drosselung und Rückstau
Überlegungen zur Drosselung gelten für die Ausgabebindungen, nicht nur für Event Hubs, sondern auch für Azure-Dienste wie Azure Cosmos DB. Es ist wichtig, sich mit den Grenzwerten und Kontingenten vertraut zu machen, die für diese Dienste gelten, und entsprechend zu planen.
Um nachgeschaltete Fehler im Zusammenhang mit de In-Process-Modell zu behandeln, können Sie AddAsync und FlushAsync in einen Ausnahmehandler für .NET-Funktionen umschließen, um Ausnahmen von IAsyncCollector abzufangen. Eine weitere Option besteht darin, die Event Hubs SDKs direkt anstelle von Ausgabebindungen zu verwenden.
Wenn Sie für Funktionen das isolierte Modell verwenden, sollte die strukturierte Ausnahmebehandlung verwendet werden, um Ausnahmen beim Zurückgeben der Ausgabewerte verantwortungsbewusst abzufangen.
Funktionscode
In diesem Abschnitt werden die wichtigsten Bereiche behandelt, die beim Schreiben von Code zum Verarbeiten von Ereignissen aus einer von Event Hubs ausgelösten Funktion berücksichtigt werden müssen.
Asynchrone Programmierung
Es wird empfohlen, Ihre Funktion zu schreiben, um asynchronen Code zu verwenden und blockierende Aufrufe zu vermeiden, insbesondere wenn E/A-Aufrufe betroffen sind.
Die folgenden Richtlinien sollten Sie befolgen, wenn Sie eine Funktion schreiben, die asynchron verarbeitet werden soll:
- Vollständig asynchron oder vollständig synchron: Wenn eine Funktion für die asynchrone Ausführung konfiguriert ist, sollten alle E/A-Aufrufe asynchron sein. In den meisten Fällen kann teilweise asynchroner Code schlechter sein, als Code, der vollständig synchron ist. Wählen Sie entweder asynchron oder synchron aus, und bleiben Sie bei Ihrer Wahl.
- Blockierende Aufrufe vermeiden: Blockierende Aufrufe kehren erst nach Abschluss des Aufrufs an die aufrufende Funktion zurück, im Gegensatz zu asynchronen Aufrufen, die sofort zurückkehren. Ein Beispiel in C# wäre das Aufrufen von Task.Result oder Task.Wait für einen asynchronen Vorgang.
Weitere Aspekt blockierender Aufrufe
Wenn blockierende Aufrufe für asynchrone Vorgänge ausgeführt werden, kann dies zu einer Blockierung des Threadpools führen sowie dazu, dass der Funktionsprozess abstürzt. Zu dem Absturz kommt es, weil für einen blockierenden Aufruf ein anderer Thread erstellt werden muss, um den ursprünglichen Aufruf zu kompensieren, der jetzt wartet. Daraus folgt, dass jetzt doppelt so viele Threads erforderlich sind, um den Vorgang abzuschließen.
Die Vermeidung dieses Ansatzes von synchron vor asynchron ist besonders wichtig, wenn Event Hubs beteiligt ist, da ein Absturz der Funktion nicht den Prüfpunkt aktualisiert. Wenn die Funktion das nächste Mal aufgerufen wird, könnte sie in diesen Zyklus geraten und scheinbar hängen bleiben oder nur langsam fortschreiten, während es schließlich zum Timeout der Funktionsausführungen kommt.
Eine Behandlung dieses Problems beginnt in der Regel mit der Überprüfung der Auslösereinstellungen und der Ausführung von Experimenten, zu denen die Erhöhung der Partitionsanzahl gehören kann. Untersuchungen können auch dazu führen, dass mehrere der Batchverarbeitungsoptionen geändert werden, z. B. die maximale Batchgröße oder die Vorabrufanzahl. Der Eindruck entsteht, dass es sich um ein Durchsatzproblem oder eine Konfigurationseinstellung handelt, die nur entsprechend optimiert werden muss. Das Hauptproblem liegt jedoch im Code selbst und muss dort behandelt werden.
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
Bevor Sie fortfahren, sollten Sie die folgenden verwandten Artikel lesen:
- Überwachen von Ausführungen in Azure Functions
- Zuverlässige Ereignisverarbeitung in Azure Functions
- Entwerfen von Azure-Funktionen für identische Eingaben
- Leitfaden für asynchrone ASP.NET Core-Programmierung.
- Azure Event Hubs-Trigger für Azure Functions