Durable Functions – bewährte Methoden und Diagnosetools
In diesem Artikel werden einige bewährte Methoden für die Verwendung von Durable Functions beschrieben. Außerdem werden verschiedene Tools vorgestellt, mit denen Probleme bei Entwicklung, Tests und Produktion diagnostiziert werden können.
Bewährte Methoden
Verwenden der neuesten Version der Durable Functions-Erweiterung und des -SDK
Eine Funktions-App verwendet zwei Komponenten, um Durable Functions auszuführen. Die eine ist das Durable Functions-SDK, mit dessen Hilfe Sie Orchestrator-, Aktivitäts- und Entitätsfunktionen in der gewünschten Programmiersprache schreiben können. Die andere ist die Durable-Erweiterung, eine Laufzeitkomponente, die den Code ausführt. Mit Ausnahme von .NET-In-Process-Anwendungen werden das SDK und die Erweiterung unabhängig voneinander versioniert.
Indem Sie mit der Erweiterung und dem SDK auf dem neuesten Stand bleiben, stellen Sie sicher, dass Ihre Anwendung von den neuesten Leistungsverbesserungen, Features und Fehlerbehebungen profitiert. Upgrades auf die neuesten Versionen stellen außerdem sicher, dass Microsoft die aktuellsten Telemetriedaten für die Diagnose erfassen kann, um den Untersuchungsprozess zu beschleunigen, wenn Sie eine Anfrage an den Azure-Support stellen.
- Weiter Anweisungen zum Abrufen der neuesten Erweiterungsversion finden Sie unter Upgrade der Durable Functions-Erweiterungsversion.
- Um sicherzustellen, dass Sie die neueste Version des SDK verwenden, überprüfen Sie den Paket-Manager der Programmiersprache, die Sie verwenden.
Einhalten von Codeeinschränkungen im Rahmen von Durable Functions
Mit dem Wiedergabeverhalten von Orchestratorcode sind Einschränkungen des Codetyps verbunden, der in einer Orchestratorfunktion geschrieben werden kann. Ein Beispiel für eine Einschränkung : Ihre Orchestratorfunktion muss deterministische APIs verwenden, damit jedes Mal, wenn sie wiedergegeben wird, das gleiche Ergebnis erzeugt wird.
Hinweis
Der Durable Functions Roslyn Analyzer ist ein Livecodeanalysetool, das C#-Benutzer anleitet, spezifische Codeeinschränkungen für Durable Functions einzuhalten. Anweisungen zum Aktivieren in Visual Studio und Visual Studio Code finden Sie unter Durable Functions Roslyn Analyzer.
Machen Sie sich mit den Leistungseinstellungen von Azure Functions in Ihrer Programmiersprache vertraut
Beim Verwenden von Standardeinstellungen erzwingt die von Ihnen ausgewählte Sprachlaufzeit möglicherweise strenge Parallelitätseinschränkungen für Ihre Funktionen. Ein Beispiel: Es wird auf einer bestimmten VM nur das Ausführen jeweils einer Funktion zugelassen. Diese Einschränkungen können in der Regel gelockert werden, indem Sie die Parallelitäts- und Leistungseinstellungen Ihrer Sprache optimieren. Wenn Sie die Leistung Ihrer Durable Functions-Anwendung optimieren möchten, müssen Sie sich mit diesen Einstellungen vertraut machen.
Im Folgenden finden Sie eine nicht abschließende Liste einiger Sprachen, die häufig von der Optimierung ihrer Einstellungen für Leistung und Parallelität profitieren, sowie die entsprechenden Richtlinien.
Garantieren eindeutiger Aufgabenhubnamen pro Anwendung
Mehrere Durable Function-Anwendungen können dasselbe Speicherkonto gemeinsam nutzen. Standardmäßig wird der Name der Anwendung als Aufgabenhubname verwendet, wodurch sichergestellt wird, dass kein versehentliches Teilen von Aufgabenhubs erfolgt. Wenn Sie Aufgabenhubnamen für Ihre Apps in host.json explizit konfigurieren müssen, stellen Sie sicher, dass die Namen eindeutig sind. Andernfalls konkurrieren die verschiedenen Anwendungen um Nachrichten, was zu einem undefinierten Verhalten führen kann, einschließlich Orchestrierungen, die unerwartet im ausstehenden oder ausgeführten Zustand „stecken bleiben“.
Die einzige Ausnahme ist, wenn Sie Kopien derselben Anwendung in mehreren Regionen bereitstellen. In diesem Fall können Sie für die Kopien denselben Aufgabenhub verwenden.
Dem Leitfaden beim Bereitstellen von Codeänderungen für ausgeführte Orchestratoren folgen
Es ist unvermeidbar, dass Funktionen im Verlauf der Lebensdauer einer Anwendung hinzugefügt, entfernt und geändert werden. Beispiele für übliche Breaking Changes sind das Ändern von Aktivitäts- oder Entitätsfunktionssignaturen und der Orchestratorlogik. Diese Änderungen stellen ein Problem dar, wenn sie sich auf Orchestrierungen auswirken, die noch ausgeführt werden. Bei einer fehlerhaften Bereitstellung können Codeänderungen dazu führen, dass Orchestrierungen mit einem nicht deterministischen Fehler fehlschlagen, dauerhaft hängen bleiben, die Leistung beeinträchtigt wird usw. Folgen Sie den empfohlenen Lösungsstrategien, wenn Sie Codeänderungen vornehmen, die sich auf ausgeführte Orchestrierungen auswirken können.
Funktionseingaben und -ausgaben so klein wie möglich halten
Wenn Sie umfangreiche Eingaben und Ausgaben für und von Durable Functions-APIs bereitstellen, können Speicherprobleme auftreten.
Eingaben und Ausgaben für Durable Functions-APIs werden in den Orchestrierungsverlauf serialisiert. Das bedeutet, dass umfangreiche Ein- und Ausgaben im Laufe der Zeit erheblich dazu beitragen können, dass der Orchestrierungsverlauf immer weiter wächst, was zu Speicherausnahmen während der Wiedergabe führen kann.
Um die Auswirkungen umfangreicher Ein- und Ausgaben an APIs zu minimieren, können Sie einige Aufgaben an Sub-Orchestratoren delegieren. Dies trägt dazu bei, die hinsichtlich der Speicherlast des Verlaufs einen Lastausgleich von einem einzelnen Orchestrator auf mehrere vorzunehmen, sodass der Speicherbedarf einzelner Verläufe klein bleibt.
Die bewährte Methode für den Umgang mit umfangreichen Datenbeständen besteht allerdings darin, sie extern zu speichern und nur bei Bedarf innerhalb von Aktivitäten zu materialisieren. Bei diesem Ansatz können Sie, anstatt die Daten selbst als Ein- und/oder Ausgaben von Durable Functions-APIs zu kommunizieren, lediglich einen Bezeichner übergeben, mit dessen Hilfe Sie diese Daten bei Bedarf aus dem externen Speicher in Ihre Aktivitäten abrufen können.
Entitätsdaten klein halten
Genau wie bei Eingaben und Ausgaben an durable Functions-APIs können Speicherprobleme auftreten, wenn der explizite Zustand einer Entität zu groß ist. Insbesondere muss ein Entitätsstatus serialisiert und vom Speicher auf jeder Anforderung de serialisiert werden, sodass große Zustände die Serialisierungslatenz zu jedem Aufruf hinzufügen. Wenn eine Entität große Daten nachverfolgen muss, empfiehlt es sich daher, die Daten in den externen Speicher zu entladen und einen einfachen Bezeichner in der Entität nachzuverfolgen, mit dem Sie die Daten bei Bedarf aus dem Speicher materialisieren können.
Optimieren der Durable Functions-Parallelitätseinstellungen
Eine einzelne Workerinstanz kann mehrere Arbeitselemente gleichzeitig ausführen, um die Effizienz zu erhöhen. Die gleichzeitige Verarbeitung von zu vielen Arbeitselementen birgt jedoch die Gefahr, dass Ressourcen wie CPU-Kapazität, Netzwerkverbindungen usw. ausgereizt werden. In vielen Fällen sollte dies kein Problem darstellen, da das Skalieren und Einschränke von Arbeitselementen automatisch für Sie erledigt werden. Wenn Sie dennoch mit Leistungsproblemen zu kämpfen haben (z. B. mit Orchestratoren, die zu lange benötigen, dauerhaft ausstehend sind usw.) oder Leistungstests durchführen, können Sie in der host.json-Datei Parallelitätslimits konfigurieren.
Hinweis
Dies stellt allerdings keinen Ersatz für das Optimieren der Leistungs- und Parallelitätseinstellungen der Runtime Ihrer Programmiersprache in Azure Functions dar. Die Durable Functions-Parallelitätseinstellungen bestimmen nur, wie viel Last einer bestimmten VM zu einem bestimmten Zeitpunkt zugewiesen werden kann, nicht aber den Grad der Parallelität bei der Verarbeitung innerhalb der VM. Letzteres erfordert eine Optimierung der Leistungseinstellungen der Runtime der Programmiersprache.
Verwenden eindeutiger Namen für externe Ereignisse
Wie bei Aktivitätsfunktionen weisen externe Ereignisse eine Garantie von mindestens einer Zustellung auf. Ihre Anwendung kann somit unter bestimmten seltenen Bedingungen (die während Neustarts, Skalierung, Abstürzen usw. auftreten können), Duplikate desselben externen Ereignisses empfangen. Daher wird empfohlen, dass externe Ereignisse eine ID enthalten, über die sie in Orchestratoren manuell dedupliziert werden können.
Hinweis
Der MSSQL-Speicheranbieter verwendet externe Ereignisse und aktualisiert den Orchestratorstatus transaktional, sodass kein Back-End-Risiko doppelter Ereignisse bestehen sollte, anders als beim standardmäßigen Azure Storage-Speicheranbieter. Es wird allerdings weiterhin empfohlen, externen Ereignisse eindeutige Namen zuzuweisen, sodass Code über Back-End-Geräte hinweg portierbar ist.
Investieren Sie in Stresstests
Wie bei allen Leistungsfragen hängt die ideale Parallelitätseinstellungen und die Architechtur Ihrer App letztendlich von der Arbeitsauslastung Ihrer Anwendung ab. Daher wird empfohlen, dass Benutzer in eine Leistungstestnutzung investieren, die ihre erwartete Arbeitsauslastung simuliert und sie zum Ausführen von Leistungs- und Zuverlässigkeitsversuchen für ihre App verwendet.
Vermeiden vertraulicher Daten in Eingaben, Ausgaben und Ausnahmen
Eingaben und Ausgaben (einschließlich Ausnahmen) an und von Durable Functions-APIs werden im Speicheranbieter Ihrer Wahl dauerhaft gespeichert. Wenn diese Eingaben, Ausgaben oder Ausnahmen vertrauliche Daten (z. B. Geheimnisse, Verbindungszeichenfolgen oder personenbezogene Informationen) enthalten, können alle Benutzer mit Lesezugriff für die Ressourcen Ihres Speicheranbieters diese Informationen abrufen. Um vertrauliche Daten sicher zu behandeln, empfiehlt es sich, dass Benutzer diese Daten innerhalb von Aktivitätsfunktionen über Azure Key Vault oder Umgebungsvariablen abrufen und diese Daten niemals direkt an Orchestratoren oder Entitäten kommunizieren. Auf diese Weise sollte verhindert werden, dass vertrauliche Daten in Ihre Speicherressourcen gelangen.
Hinweis
Diese Anleitung gilt auch für die CallHttp-Orchestrator-API, die auch ihre Anforderungs- und Antwortnutzdaten im Speicher speichert. Wenn Ihre HTTP-Zielendpunkte eine Authentifizierung erfordern, die möglicherweise vertraulich ist, wird empfohlen, dass Benutzer den HTTP-Aufruf selbst in einer Aktivität implementieren oder die von CallHttp angebotene integrierte Unterstützung für verwaltete Identitäten verwenden, die keine Anmeldeinformationen im Speicher speichert.
Tipp
Vermeiden Sie ebenso die Protokollierung von Daten, die Geheimnisse enthalten, da alle Personen mit Lesezugriff für Ihre Protokolle (z. B. in Application Insights) diese Geheimnisse abrufen können.
Diagnosetools
Es stehen mehrere Tools zur Verfügung, mit denen Sie Probleme diagnostizieren können.
Durable Functions und Durable Task Framework-Protokolle
Durable Functions-Erweiterung
Die Durable Functions-Erweiterung gibt auch Nachverfolgungsereignisse aus, mit denen Sie die End-to-End-Ausführung einer Orchestrierung verfolgen können. Diese Nachverfolgungsereignisse können Sie ermitteln und abfragen, indem Sie im Azure-Portal das Tool Application Insights Analytics verwenden. Der Ausführlichkeitsgrad der ausgegebenen Nachverfolgungsdaten kann im Abschnitt logger (Functions 1.x) oder logging (Functions 2.0) der host.json-Datei konfiguriert werden. Weiter Informationen finden Sie unter Konfigurationsdetails.
Durable Task Framework
Ab v2.3.0 der Durable-Erweiterung stehen auch Protokolle, die vom zugrunde liegenden Durable Task Framework (DTFx) ausgegeben werden, zur Erfassung bereit. Weitere Informationen finden Sie unter Details zum Aktivieren dieser Protokolle.
Azure-Portal
Diagnose und Problembehandlung
Die App-Diagnose von Azure Functions ist eine nützliche Ressource für das Azure-Portal, um Ihre Anwendung zu überwachen und potenzielle Probleme zu identifizieren. Sie bietet außerdem Vorschläge, um Probleme basierend auf der Diagnose zu lösen. Weitere Informationen finden Sie unter App-Diagnose von Azure Functions.
Überwachen der Orchestrierung von Durable Functions
Das Azure-Portal bietet Details zur Orchestrierungsablaufverfolgung, die Ihnen helfen, den Status jeder einzelnen Orchestrierungsinstanz zu verstehen und die End-to-End-Ausführung nachzuverfolgen. Wenn Sie sich die Liste der Funktionen in Ihrer Azure Functions-Anwendung ansehen, sehen Sie eine Spalte namens Ablaufverfolgung, die Links zu den Ablaufverfolgungen enthält. Sie müssen Application Insights aktiviert haben, damit Ihre Anwendung diese Informationen abrufen kann.
Durable Functions Monitor-Erweiterung
Dies ist eine Visual Studio Code-Erweiterung, die eine Benutzeroberfläche zum Überwachen, Verwalten und Debuggen Ihrer Orchestrierungsinstanzen bereitstellt.
Roslyn Analyzer
Der Durable Functions Roslyn Analyzer ist ein Livecodeanalysetool, das C#-Benutzer anleitet, spezifische Codeeinschränkungen für Durable Functions einzuhalten. Anweisungen zum Aktivieren in Visual Studio und Visual Studio Code finden Sie unter Durable Functions Roslyn Analyzer.
Support
Wenn Sie Fragen haben oder Support benötigen, können Sie ein Ticket in einem der folgenden GitHub-Repositorys öffnen. Wenn Sie einen Fehler in Azure melden, können Sie die Untersuchung erheblich beschleunigen, indem Sie Informationen wie betroffene Instanzen-IDs, Zeiträume (UTC), in denen das Problem angezeigt wird, den Anwendungsname (falls möglich) und die Bereitstellungsregion übermitteln.