Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Die Durable Functions-Laufzeit speichert automatisch die Funktionsparameter, Rückgabewerte und den Status im task hub, um eine zuverlässige Ausführung zu ermöglichen. Umfang und Häufigkeit der im dauerhaftem Speicher aufbewahrten Daten können sich jedoch auf die Leistung der Anwendung und die Kosten für Speichertransaktion auswirken. Abhängig von dem Datentyp, der von Ihrer Anwendung gespeichert wird, müssen auch die Richtlinien für die Datenaufbewahrung und den Datenschutz berücksichtigt werden.
Inhalt des Aufgabenhubs
Aufgabenhubs speichern den aktuellen Status von Instanzen und alle ausstehenden Nachrichten:
- Instanzzustände speichern den aktuellen Status und den Verlauf einer Instanz. Für Orchestrierungsinstanzen umfasst dieser Status den Runtimezustand, den Orchestrierungsverlauf, Eingaben, Ausgaben und den benutzerdefinierten Status. Für Entitätsinstanzen enthält sie den Entitätsstatus.
- Nachrichten speichern Funktionseingaben oder -ausgaben, Ereignisnutzdaten und Metadaten, die für interne Zwecke verwendet werden, z. B. für Routing und End-to-End-Korrelation.
Nachrichten werden nach der Verarbeitung gelöscht, aber Instanzenzustände bleiben erhalten, es sei denn, sie werden explizit von der Anwendung oder einem Operator gelöscht. Insbesondere verbleibt eine Orchestrierungsgeschichte auch nach Abschluss der Orchestrierung im Speicher.
Ein Beispiel dafür, wie Zustände und Nachrichten den Fortschritt einer Orchestrierung darstellen, finden Sie im Ausführungsbeispiel des Aufgabenhubs.
Wo und wie Zustände und Nachrichten im Speicher dargestellt werden, hängt vom Speicheranbieter ab. Durable Functions Standardanbieter ist Azure Storage, der Daten in Warteschlangen, Tabellen und Blobs in einem von Ihnen angegebenen Azure Storage Konto speichert.
Typen von Daten, die serialisiert und persistent gespeichert werden
In der folgenden Liste sind die verschiedenen Datentypen aufgeführt, die serialisiert und beibehalten werden, wenn Features von Durable Functions verwendet werden:
- Alle Ein- und Ausgaben von Orchestrator-, Aktivitäts- und Entitätsfunktionen, einschließlich aller IDs und nicht behandelten Ausnahmen
- Namen der Orchestrator-, Aktivitäts- und Entitätsfunktionen
- Namen und Nutzdaten externer Ereignisse
- Statusnutzdaten der benutzerdefinierten Orchestrierung
- Nachrichten zur Beendigung der Orchestrierung
- Dauerhafte Timernutzdaten
- Dauerhafte HTTP-Anforderungen und Antwort-URLs, Header und Nutzdaten
- Nutzdaten zu Entitätsaufrufen und Signalen
- Nutzdaten zum Entitätszustand
Halten Sie Eingaben und Ausgaben klein
Wenn Sie große Eingaben und Ausgaben für Durable Functions-APIs bereitstellen, können Speicherprobleme auftreten. Eingaben und Ausgaben werden in die Orchestrierungshistorie serialisiert, was bedeutet, dass große Nutzlasten im Laufe der Zeit erheblich zu einem unkontrollierten Wachstum der Historie beitragen können. Dieses Wachstum birgt das Risiko, während der Wiedergabe Speicherfehler zu verursachen.
Um die Auswirkungen großer Eingaben und Ausgaben zu verringern, können Sie:
- Delegieren Sie Arbeit an Unter-Orchestratoren, um die Speicherbelastung des Verlaufs über mehrere Orchestratoren hinweg auszugleichen, so dass der Speicherbedarf einzelner Verläufe gering bleibt.
- Speichern Sie große Daten im externen Speicher (z. B. Azure Blob Storage), und übergeben Sie einfache Bezeichner, mit denen Sie diese Daten bei Bedarf innerhalb von Aktivitätsfunktionen abrufen können.
Wenn Sie "Durable Task Scheduler" verwenden, können Sie auch große Nutzlastunterstützung verwenden, um größere Nutzlasten in Azure Blob Storage zu entladen.
Tipp
Die bewährte Methode für den Umgang mit großen Daten besteht darin, sie bei Bedarf im externen Speicher zu halten und diese Daten nur innerhalb von Aktivitäten zu materialisieren.
Arbeiten mit vertraulichen Daten
Eingaben und Ausgaben (einschließlich Ausnahmen) an und von Durable Functions-APIs werden in Ihrem Storageanbieter der Wahl dauerhaft beibehalten. Wenn diese Eingaben, Ausgaben oder Ausnahmen vertrauliche Daten enthalten (z. B. geheime Daten, Verbindungszeichenfolgen oder persönlich identifizierbare Informationen), kann jeder Benutzer mit Lesezugriff auf die Ressourcen Ihres Speicheranbieters diese abrufen.
Um vertrauliche Daten sicher zu verarbeiten, rufen Sie diese Daten innerhalb von Aktivitätsfunktionen aus Azure Key Vault oder Umgebungsvariablen ab, und kommunizieren Sie diese Daten niemals direkt an Orchestratoren oder Entitäten. Dieser Ansatz verhindert, dass vertrauliche Daten in Ihre Speicherressourcen fließen.
Tipp
Diese Anleitung gilt auch für die CallHttp Orchestrator-API, die ihre Anforderungs- und Antwortnutzlasten im Speicher speichert. Wenn für Ihre Ziel-HTTP-Endpunkte eine Authentifizierung erforderlich ist, implementieren Sie den HTTP-Aufruf innerhalb einer Aktivität, oder verwenden Sie die integrierte Unterstützung für verwaltete Identitäten, die von CallHttp angeboten wird, wodurch Anmeldeinformationen nicht im Speicher abgelegt werden.
Hinweis
Vermeiden Sie das Protokollieren von Daten, die geheime Schlüssel enthalten, da jeder mit Lesezugriff auf Ihre Protokolle (z. B. in Application Insights) diese geheimen Schlüssel abrufen kann.
Bei Verwendung des Azure Storage-Dienstes werden alle Daten im Ruhezustand automatisch verschlüsselt. Jeder Benutzer, der Zugriff auf das Speicherkonto hat, kann die Daten jedoch in unverschlüsselter Form lesen. Wenn Sie vertrauliche Daten stärker schützen möchten, sollten Sie in Erwägung ziehen, die Daten zunächst mit Ihren eigenen Verschlüsselungsschlüsseln zu verschlüsseln, damit die Daten in einer vorverschlüsselten Form gespeichert werden.
Alternativ können .NET Benutzer benutzerdefinierte Serialisierungsanbieter implementieren, die die automatische Verschlüsselung bereitstellen. Ein Beispiel für eine benutzerdefinierte Serialisierung mit Verschlüsselung finden Sie in dieses GitHub Beispiel.
Hinweis
Wenn Sie sich für die Implementierung der Verschlüsselung auf Anwendungsebene entscheiden, beachten Sie, dass Orchestrierungen und Entitäten für eine unbegrenzte Zeit vorhanden sein können. Dies ist wichtig, wenn Sie Ihre Verschlüsselungsschlüssel rotieren müssen, da eine Orchestrierung oder Entitäten länger ausgeführt werden können, als Ihre Richtlinie für die Schlüsselrotation gilt. Bei einer Schlüsselrotation ist der Schlüssel zum Verschlüsseln der Daten möglicherweise nicht mehr für die Entschlüsselung verfügbar, wenn die Orchestrierung oder Entität das nächste Mal ausgeführt wird. Daher wird die kundenseitige Verschlüsselung nur empfohlen, wenn davon ausgegangen werden kann, dass Orchestrierungen und Entitäten nur für relativ kurze Zeitabschnitte ausgeführt werden.
Anpassen von Serialisierung und Deserialisierung
Standardserialisierungslogik
Durable Functions für .NET verwendet im Prozess Json.NET zum Serialisieren von Orchestrierungs- und Entitätsdaten in JSON. Die standardmäßigen Json.NET einstellungen sind:
Eingaben, Ausgaben und Zustand:
JsonSerializerSettings
{
TypeNameHandling = TypeNameHandling.None,
DateParseHandling = DateParseHandling.None,
}
Ausnahmen:
JsonSerializerSettings
{
ContractResolver = new ExceptionResolver(),
TypeNameHandling = TypeNameHandling.Objects,
ReferenceLoopHandling = ReferenceLoopHandling.Ignore,
}
Eine ausführlichere Dokumentation zu JsonSerializerSettings finden Sie hier.
Anpassen der Serialisierung mit .NET Attributen
Während der Serialisierung sucht Json.NET nach verschiedenen Attributen an Klassen und Eigenschaften, die steuern, wie die Daten serialisiert und aus JSON deserialisiert werden. Wenn Sie den Quellcode für den an Durable Functions APIs übergebenen Datentyp besitzen, sollten Sie diese Attribute dem Typ hinzufügen, um die Serialisierung und Deserialisierung anzupassen.
Anpassen der Serialisierung per Abhängigkeitsinjektion
Funktions-Apps, die auf .NET abzielen und auf der Funktions-V3-Laufzeit ausgeführt werden, können Dependency Injection (DI) verwenden, um anzupassen, wie Daten und Ausnahmen serialisiert werden. Im folgenden Beispielcode wird die Verwendung von DI zum Überschreiben der Standard-Json.NET Serialisierungseinstellungen mithilfe von benutzerdefinierten Implementierungen der IMessageSerializerSettingsFactory und IErrorSerializerSettingsFactory-Dienstschnittstellen veranschaulicht.
using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;
using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using System.Collections.Generic;
[assembly: FunctionsStartup(typeof(MyApplication.Startup))]
namespace MyApplication
{
public class Startup : FunctionsStartup
{
public override void Configure(IFunctionsHostBuilder builder)
{
builder.Services.AddSingleton<IMessageSerializerSettingsFactory, CustomMessageSerializerSettingsFactory>();
builder.Services.AddSingleton<IErrorSerializerSettingsFactory, CustomErrorSerializerSettingsFactory>();
}
/// <summary>
/// A factory that provides the serialization for all inputs and outputs for activities and
/// orchestrations, as well as entity state.
/// </summary>
internal class CustomMessageSerializerSettingsFactory : IMessageSerializerSettingsFactory
{
public JsonSerializerSettings CreateJsonSerializerSettings()
{
// Return your custom JsonSerializerSettings here
}
}
/// <summary>
/// A factory that provides the serialization for all exceptions thrown by activities
/// and orchestrations
/// </summary>
internal class CustomErrorSerializerSettingsFactory : IErrorSerializerSettingsFactory
{
public JsonSerializerSettings CreateJsonSerializerSettings()
{
// Return your custom JsonSerializerSettings here
}
}
}
}