Überlegungen zum Anwendungsentwurf für unternehmenskritische Workloads

Die unternehmenskritische Baseline-Referenzarchitektur verwendet eine einfache Onlinekatalog-Anwendung, um einen hoch zuverlässigen Workload zu demonstrieren. Benutzer können durch einen Katalog mit Artikeln blättern, Details zu Artikeln anzeigen sowie Bewertungen und Kommentare zu Artikeln veröffentlichen. Dieser Artikel befasst sich mit der Zuverlässigkeit und Resilienz unternehmenskritischer Anwendungen, z. B. der asynchronen Verarbeitung von Anforderungen und der Frage, wie innerhalb einer Lösung ein hoher Durchsatz erreicht werden kann.

Anwendungskomposition

Bei umfangreichen unternehmenskritischen Anwendungen müssen Sie die Architektur hinsichtlich End-to-End-Skalierbarkeit und -Resilienz optimieren. Sie können separate Komponenten in Funktionseinheiten unterteilen, die unabhängig voneinander ausgeführt werden können. Wenden Sie diese Unterteilung auf allen Ebenen des Anwendungsstapels an, sodass alle Teile des Systems unabhängig voneinander skaliert werden können und Änderungen bei der Nachfrage erfüllen können. Die Implementierung demonstriert diesen Ansatz.

Die Anwendung verwendet zustandslose API-Endpunkte, die zeitintensive Schreibanforderungen asynchron über einen Nachrichtenbroker entkoppeln. Die Zusammensetzung des Workloads ermöglicht Ihnen die jederzeitige Löschung und Neuerstellung vollständiger Azure Kubernetes Service (AKS)-Cluster und anderer Abhängigkeiten im Stempel. Die Hauptkomponenten der Anwendung sind:

• Benutzeroberfläche (UI): Eine Webanwendung mit einer einzelnen Seite, auf die Benutzer zugreifen können. Die UI wird als statische Website in einem Azure Storage-Konto gehostet.

• API (CatalogService): eine REST-API, die von der UI-Anwendung aufgerufen wird, jedoch für andere potenzielle Clientanwendungen weiter verfügbar ist.

• Worker (BackgroundProcessor): ein Hintergrundworker, der auf neue Ereignisse im Nachrichtenbus lauscht und die Schreibanforderungen für die Datenbank verarbeitet. Diese Komponente stellt keine APIs zur Verfügung.

• Integritätsdienst-API (HealthService): eine API, die die Integrität der Anwendung meldet, indem sie überprüft, ob kritische Komponenten funktionieren, z. B. die Datenbank oder der Nachrichtenbus.

  

Der Workload besteht aus der API, dem Worker und Anwendungen für die Integritätsprüfung. Ein dedizierter AKS-Namespace mit dem Namen workload hostet den Workload als Container. Es gibt keine direkte Kommunikation zwischen den Pods. Die Pods sind zustandslos und können unabhängig voneinander skaliert werden.

Weitere unterstützende Komponenten, die im Cluster ausgeführt werden:

• Ein NGINX-Eingangscontroller: leitet eingehende Anforderungen an den Workload weiter und sorgt für den Lastausgleich zwischen Pods. Der NGINX-Eingangscontroller wird über Azure Load Balancer mit einer öffentlichen IP-Adresse verfügbar gemacht. Der Zugriff ist jedoch nur über Azure Front Door möglich.

• Cert-Manager: Jetstack cert-manager stellt Transport Layer Security (TLS)-Zertifikate automatisch bereit, wobei Let's Encrypt für die Eingangsregeln verwendet wird.

• Secrets Store CSI-Treiber: Der Azure Key Vault-Anbieter für Secrets Store CSI Driver liest Geheimnisse auf sichere Weise, z. B. Verbindungszeichenfolgen aus Key Vault.

• Überwachungs-Agent: Die OMSAgentForLinux-Standardkonfiguration reduziert die Menge der Überwachungsdaten, die an den Azure Monitor-Protokollarbeitsbereich gesendet werden.

Datenbankverbindung

Aufgrund der kurzlebigen Natur von Bereitstellungsstempeln sollten Sie die Persistenz des Zustands innerhalb des Stempels so weit wie möglich vermeiden. Sie sollten den Zustand in einem externalisierten Datenspeicher aufbewahren. Um das Service-Level-Ziel (Service Level Objective, SLO) für die Zuverlässigkeit zu unterstützen, sollten Sie einen resilienten Datenspeicher erstellen. Wir empfehlen Ihnen die Verwendung verwalteter bzw. Platform-as-a-Service (PaaS)-Lösungen in Verbindung mit nativen SDK-Bibliotheken, die Zeitüberschreitungen, Verbindungsabbrüche und andere Fehlerzustände automatisch behandeln.

In der Referenzimplementierung dient Azure Cosmos DB als Hauptdatenspeicher für die Anwendung. Azure Cosmos DB unterstützt Schreibvorgänge in mehreren Regionen. Jeder Stempel kann zum Azure Cosmos DB-Replikat in derselben Region schreiben. Azure Cosmos DB verarbeitet die Datenreplikation und Synchronisierung zwischen Regionen. Azure Cosmos DB for NoSQL unterstützt die gesamte Funktionalität der Datenbank-Engine.

Weitere Informationen finden Sie unter Datenplattform für unternehmenskritische Workloads.

Für unternehmenskritische Anwendungen, bei denen die Verfügbarkeit Vorrang vor der Leistung hat, empfehlen wir Schreibvorgänge in einer einzelnen Region und Lesevorgänge in mehreren Regionen mit der Konsistenzebene „Stark“.

Diese Architektur verwendet Storage für die vorübergehende Speicherung des Zustands im Stempel, damit Azure Event Hubs Prüfpunkte setzen kann.

Alle Workloadkomponenten verwenden das .NET Core SDK für Azure Cosmos DB zur Kommunikation mit der Datenbank. Das SDK enthält eine robuste Logik zur Aufrechterhaltung von Datenbankverbindungen und zum Umgang mit Fehlern. Zu den wesentlichen Konfigurationseinstellungen gehören:

• Direkter Konnektivitätsmodus: Diese Einstellung ist eine Standardeinstellung für .NET SDK v3, da sie eine bessere Leistung bietet. Der Modus für die direkte Konnektivität verwendet weniger Netzwerkhops, verglichen mit dem Gatewaymodus, der HTTP verwendet.

• Rückgabe der Inhaltsantwort bei Schreibvorgängen: Dieser Ansatz ist deaktiviert, um zu verhindern, dass der Azure Cosmos DB-Client das Dokument aus Erstellungs-, Upsert-, Patch- und Ersetzungsvorgängen zurückgibt. Dies reduziert den Datenverkehr im Netzwerk. Für die weitere Verarbeitung auf dem Client ist diese Einstellung nicht erforderlich.

• Benutzerdefinierte Serialisierung: Mit diesem Prozess wird die Benennungsrichtlinie für JSON-Eigenschaften auf JsonNamingPolicy.CamelCase festgelegt, um .NET-Eigenschaften in JSON-Standardeigenschaften zu übersetzen. Sie kann auch JSON-Eigenschaften in .NET-Eigenschaften übersetzen. Die Standardbedingung „Ignore“ ignoriert während der Serialisierung Eigenschaften mit Nullwerten, z. B. JsonIgnoreCondition.WhenWritingNull.

• ApplicationRegion: Diese Eigenschaft ist auf die Region des Stempels festgelegt. So kann das SDK den nächstgelegenen Verbindungsendpunkt finden. Der Endpunkt sollte sich in derselben Region befinden.

Der folgende Codeblock wird in der Referenzimplementierung angezeigt:

//
// /src/app/AlwaysOn.Shared/Services/CosmosDbService.cs
//
CosmosClientBuilder clientBuilder = new CosmosClientBuilder(sysConfig.CosmosEndpointUri, sysConfig.CosmosApiKey)
    .WithConnectionModeDirect()
    .WithContentResponseOnWrite(false)
    .WithRequestTimeout(TimeSpan.FromSeconds(sysConfig.ComsosRequestTimeoutSeconds))
    .WithThrottlingRetryOptions(TimeSpan.FromSeconds(sysConfig.ComsosRetryWaitSeconds), sysConfig.ComsosMaxRetryCount)
    .WithCustomSerializer(new CosmosNetSerializer(Globals.JsonSerializerOptions));

if (sysConfig.AzureRegion != "unknown")
{
    clientBuilder = clientBuilder.WithApplicationRegion(sysConfig.AzureRegion);
}

_dbClient = clientBuilder.Build();

Asynchrones Messaging

Wenn Sie die lose Kopplung implementieren, besitzen Dienste keine Abhängigkeiten von anderen Diensten. Die lose Kopplung ermöglicht die unabhängige Ausführung von Diensten. Die Kopplung ermöglicht die Kommunikation zwischen den Diensten über gut definierte Schnittstellen. Bei einer unternehmenskritischen Anwendung verhindert die lose Kopplung die Kaskadierung nachgelagerter Fehler zu Front-Ends oder anderen Bereitstellungsstempeln, was eine hohe Verfügbarkeit bedeutet.

Zu den wesentlichen Merkmalen asynchroner Nachrichten gehören:

• Dienste müssen nicht dieselbe Computeplattform, dieselbe Programmiersprache oder dasselbe Betriebssystem verwenden.

• Die Dienste führen die Skalierung unabhängig voneinander durch.

• Downstreamfehler haben keine Auswirkungen auf die Transaktionen des Clients.

• Die Transaktionsintegrität ist schwierig zu wahren, da für Datenerstellung und Persistenz unterschiedliche Dienste verwendet werden. Die Transaktionsintegrität stellt eine Herausforderung für Nachrichten- und Persistenzdienste dar. Weitere Informationen finden Sie unter Idempotent-Nachrichtenverarbeitung.

• Die End-to-End-Ablaufverfolgung setzt eine komplexe Orchestrierung voraus.

Wir empfehlen Ihnen die Verwendung gut bekannter Entwurfsmuster, z. B. des Musters „Warteschlangenbasierter Lastenausgleich“ und des Musters „Konkurrierende Consumer“. Diese Muster unterstützen die Lastverteilung vom Producer zu den Consumern und die asynchrone Verarbeitung durch die Consumer. Der Worker ermöglicht der API beispielsweise die Annahme der Anforderung und die schnelle Rückkehr zum Aufrufer und verarbeitet getrennt einen Schreibvorgang in der Datenbank.

Event Hubs vermittelt Nachrichten zwischen API und Worker.

Details zur Implementierung von Schreibvorgängen

Schreibvorgänge, z. B. die Veröffentlichung von Bewertungen und Kommentaren, werden asynchron verarbeitet. Die API sendet zunächst eine Nachricht mit allen relevanten Informationen, z. B. Art der Aktion und Kommentardaten, an die Nachrichtenwarteschlange und gibt sofort HTTP 202 (Accepted) mit dem Location-Header des Objekts zurück, das erstellt wird.

BackgroundProcessor-Instanzen verarbeiten die Nachrichten in der Warteschlange sowie die Datenbankkommunikation für Schreibvorgänge. BackgroundProcessor führt eine Herunter- und Aufskalierung auf der Grundlage des Nachrichtenvolumens in der Warteschlange durch. Die Grenze für die horizontale Skalierung von Prozessorinstanzen wird durch die maximale Anzahl von Event Hubs-Partitionen definiert. Diese beträgt 32 für die Basic- und Standard-Tarife, 100 für den Premium-Tarif und 1024 für den Dedicated-Tarif.

Die Azure Event Hubs Processor-Bibliothek in BackgroundProcessor verwendet Azure Blob Storage für die Verwaltung des Partitionseigentums, den Lastausgleich zwischen verschiedenen Workerinstanzen und die Nachverfolgung des Fortschritts mithilfe von Prüfpunkten. Die Prüfpunkte werden nicht nach jedem Ereignis zum Blob Storage geschrieben, da dies jeder Nachricht eine teure Verzögerung hinzufügen würde. Stattdessen werden die Prüfpunkte in einer Zeitgeberschleife geschrieben, deren Dauer von Ihnen konfiguriert werden kann. Die Standardeinstellung ist 10 Sekunden.

Der folgende Codeblock wird in der Referenzimplementierung angezeigt:

while (!stoppingToken.IsCancellationRequested)
{
    await Task.Delay(TimeSpan.FromSeconds(_sysConfig.BackendCheckpointLoopSeconds), stoppingToken);
    if (!stoppingToken.IsCancellationRequested && !checkpointEvents.IsEmpty)
    {
        string lastPartition = null;
        try
        {
            foreach (var partition in checkpointEvents.Keys)
            {
                lastPartition = partition;
                if (checkpointEvents.TryRemove(partition, out ProcessEventArgs lastProcessEventArgs))
                {
                    if (lastProcessEventArgs.HasEvent)
                    {
                        _logger.LogDebug("Scheduled checkpointing for partition {partition}. Offset={offset}", partition, lastProcessEventArgs.Data.Offset);
                        await lastProcessEventArgs.UpdateCheckpointAsync();
                    }
                }
            }
        }
        catch (Exception e)
        {
            _logger.LogError(e, "Exception during checkpointing loop for partition={lastPartition}", lastPartition);
        }
    }
}

Wenn die Prozessoranwendung einen Fehler erkennt oder vor der Verarbeitung der Nachricht angehalten wird:

• Eine andere Instanz holt die Nachricht zur erneuten Verarbeitung ab, da die Prüfpunkte im Speicher nicht ordnungsgemäß gesetzt wurden.

• Es tritt ein Konflikt auf, wenn der vorherige Worker das Dokument in der Datenbank persistent gespeichert hat, bevor er fehlgeschlagen ist. Dieser Fehler tritt auf, da dieselbe ID und derselbe Partitionsschlüssel verwendet werden. Der Prozessor kann die Nachricht zuverlässig ignorieren, da das Dokument bereits persistent gespeichert ist.

• Eine neue Instanz wiederholt die Schritte und schließt die Persistenz ab, wenn der vorherige Worker vor dem Schreibvorgang zur Datenbank beendet wurde.

Details zur Implementierung von Lesevorgängen

Die API verarbeitet Lesevorgänge direkt und gibt die Daten sofort an den Benutzer zurück.

Es wird keine Rückkanalmethode eingerichtet, um dem Client mitzuteilen, ob der Vorgang erfolgreich abgeschlossen wurde. Die Clientanwendung muss die API proaktiv nach Aktualisierungen für das im Location-HTTP-Header angegebene Element abfragen.

Skalierbarkeit

Die einzelnen Workloadkomponenten sollten unabhängig voneinander aufskaliert werden, da jede Komponente ein anderes Auslastungsmuster besitzt. Die Skalierungsanforderungen hängen von der Funktionalität des Diensts ab. Bestimmte Dienste wirken sich direkt auf Benutzer aus und müssen aggressiv aufskaliert werden, um schnelle Antworten und eine positive Benutzererfahrung sicherzustellen.

Die Implementierung verpackt die Dienste als Containerimages und verwendet Helm-Diagramme, um die Dienste für die einzelnen Stempel bereitzustellen. Die Dienste sind für die erwarteten Anforderungen und Grenzen von Kubernetes konfiguriert und verfügen über eine vorkonfigurierte Regel für die automatische Skalierung. Die Workloadkomponenten CatalogService und BackgroundProcessor können einzeln auf- und abskaliert werden, da beide Dienste zustandslos sind.

Benutzer interagieren direkt mit dem CatalogService. Daher muss dieser Teil des Workloads bei jeder Last reagieren. Es gibt mindestens drei Instanzen für jeden Cluster, die sich auf drei Verfügbarkeitszonen in einer Azure-Region verteilen. Die automatische horizontale Podskalierung (Horizontal Pod Autoscaler, HPA) in AKS fügt automatisch weitere Pods hinzu wie erforderlich. Die Azure Cosmos DB-Autoskalierung kann die Anforderungseinheiten (Request Units, RUs), die für die Sammlung verfügbar sind, dynamisch erhöhen und reduzieren. CatalogService und Azure Cosmos DB bilden gemeinsam eine Skalierungseinheit innerhalb eines Stempels.

Die HPA wird mit einem Helm-Diagramm mit einer konfigurierbaren maximalen und Mindestanzahl von Replikaten bereitgestellt. Im Auslastungstest wurde festgestellt, dass jede Instanz ungefähr 250 Anforderungen pro Sekunde mit Standardnutzungsmuster verarbeiten kann.

Für den BackgroundProcessor-Dienst gelten andere Anforderungen. Es handelt sich um einen Hintergrundworker mit begrenzten Auswirkungen auf die Erfahrung der Benutzer. Daher besitzt BackgroundProcessor eine andere Konfiguration für die automatische Skalierung als CatalogService und kann zwischen 2 und 32 Instanzen skaliert werden. Sie legen diese Begrenzung basierend auf der Anzahl der Partitionen fest, die Sie in den Ereignishubs verwenden. Sie benötigen nicht mehr Worker, als es Partitionen gibt.

Für jede Komponente des Workloads mit Abhängigkeiten wie ingress-nginx ist die Einstellung für Budgets für die Podunterbrechung (Pod Disruption Budgets, PDBs) konfiguriert, um sicherzustellen, dass stets eine Mindestanzahl von Instanzen verfügbar ist, wenn Cluster geändert werden.

Der folgende Codeblock wird in der Referenzimplementierung angezeigt:

#
# /src/app/charts/healthservice/templates/pdb.yaml
# Example pod distribution budget configuration.
#
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: {{ .Chart.Name }}-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: {{ .Chart.Name }}

Instrumentation

Verwenden Sie die Instrumentierung, um Leistungsengpässe und Integritätsprobleme zu bewerten, die Workloadkomponenten in das System einführen können. Um Sie bei der Quantifizierung von Entscheidungen zu unterstützen, sollte jede Komponente ausreichend Informationen mittels Metriken und Ablaufverfolgungsprotokollen ausgeben. Sie sollten bei der Instrumentierung Ihrer Anwendung die folgenden wesentlichen Überlegungen berücksichtigen:

• Senden Sie Protokolle, Metriken und andere Telemetriedaten an das Protokollsystem des Stempels.
• Verwenden Sie eine strukturierte Protokollierung anstelle von Nur-Text, damit Sie die Informationen abfragen können.
• Implementieren Sie eine Ereigniskorrelation, um eine End-to-End-Transaktionsübersicht zu erhalten. In der Referenzimplementierung enthält jede API-Antwort eine Vorgangs-ID als HTTP-Header, um die Nachverfolgbarkeit sicherzustellen.
• Verlassen Sie sich nicht nur auf die stdout- bzw. Konsolenprotokollierung. Sie können diese Protokolle jedoch verwenden, um sofort eine Problembehandlung für fehlerhafte Pods durchzuführen.

Diese Architektur implementiert eine verteilte Ablaufverfolgung mit Application Insights sowie einen Azure Monitor-Protokollarbeitsbereich für Anwendungsüberwachungsdaten. Verwenden Sie Azure Monitor-Protokolle für Protokolle sowie Metriken von Workload- und Infrastrukturkomponenten. Diese Architektur implementiert eine vollständige End-to-End-Ablaufverfolgung für Anforderungen, die von der API über Event Hubs an Azure Cosmos DB geleitet werden.

Details zur Implementierung der Anwendungsüberwachung

Die BackgroundProcessor-Komponente verwendet das Microsoft.ApplicationInsights.WorkerService-NuGet-Paket, um eine sofort einsatzbereite Instrumentierung von der Anwendung zu erhalten. Für alle Protokollierungen innerhalb der Anwendung wird Serilog verwendet. Application Insights wird zusätzlich zur Konsolensenke als Senke konfiguriert. Eine TelemetryClient-Instanz für Application Insights wird nur dann direkt verwendet, wenn weitere Metriken überwacht werden müssen.

Der folgende Codeblock wird in der Referenzimplementierung angezeigt:

//
// /src/app/AlwaysOn.BackgroundProcessor/Program.cs
//
public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
    .ConfigureServices((hostContext, services) =>
    {
        Log.Logger = new LoggerConfiguration()
                            .ReadFrom.Configuration(hostContext.Configuration)
                            .Enrich.FromLogContext()
                            .WriteTo.Console(outputTemplate: "[{Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} {Level:u3}] {Message:lj} {Properties:j}{NewLine}{Exception}")
                            .WriteTo.ApplicationInsights(hostContext.Configuration[SysConfiguration.ApplicationInsightsConnStringKeyName], TelemetryConverter.Traces)
                            .CreateLogger();
    }

Um die praktische Nachverfolgbarkeit von Anforderungen zu demonstrieren, gibt jede erfolgreiche oder nicht erfolgreiche API-Anforderung den Header „Korrelations-ID“ an den Aufrufer zurück. Das Anwendungssupportteam kann Application Insights mithilfe dieser ID durchsuchen und so einen detaillierten Überblick über die gesamte Transaktion erhalten. Dies wird im vorangehenden Diagramm gezeigt.

Der folgende Codeblock wird in der Referenzimplementierung angezeigt:

//
// /src/app/AlwaysOn.CatalogService/Startup.cs
//
app.Use(async (context, next) =>
{
    context.Response.OnStarting(o =>
    {
        if (o is HttpContext ctx)
        {
            // ... code omitted for brevity
            context.Response.Headers.Add("Server-Location", sysConfig.AzureRegion);
            context.Response.Headers.Add("Correlation-ID", Activity.Current?.RootId);
            context.Response.Headers.Add("Requested-Api-Version", ctx.GetRequestedApiVersion()?.ToString());
        }
        return Task.CompletedTask;
    }, context);
    await next();
});

Details zur Implementierung der Kubernetes-Überwachung

Sie können Diagnoseeinstellungen verwenden, um AKS-Protokolle und -Metriken an Azure Monitor-Protokolle zu senden. Sie können auch die Container Insights-Funktion mit AKS verwenden. Aktivieren Sie Container Insights, um OMSAgentForLinux über ein Kubernetes DaemonSet auf jedem einzelnen Knoten in einem AKS-Cluster bereitzustellen. OMSAgentForLinux kann weitere Protokolle und Metriken aus dem Kubernetes-Cluster sammeln und an den entsprechenden Azure Monitor-Protokollarbeitsbereich senden. Dieser Workspace enthält granulare Daten zu Pods, Bereitstellungen und Diensten sowie zur allgemeinen Clusterintegrität.

Eine umfangreiche Protokollierung kann sich negativ auf die Kosten auswirken, ohne Vorteile zu bieten. Daher sind die stdout-Protokollsammlung und das Prometheus-Scraping für die Workloadpods in der Container Insights-Konfiguration deaktiviert, da alle Ablaufverfolgungen bereits über Application Insights erfasst werden und somit doppelte Datensätze generiert würden.

Der folgende Codeblock wird in der Referenzimplementierung angezeigt:

#
# /src/config/monitoring/container-azm-ms-agentconfig.yaml
# This is just a snippet showing the relevant part.
#
[log_collection_settings]
    [log_collection_settings.stdout]
        enabled = false

        exclude_namespaces = ["kube-system"]

Weitere Informationen finden Sie in der vollständigen Konfigurationsdatei.

Überwachen der Anwendungsintegrität

Mithilfe von Anwendungsüberwachung und Einblicken können Probleme schnell erkannt und das Gesundheitsmodell über den aktuellen Zustand der Anwendung informiert werden. Sie können die Integritätsüberwachung über Integritätsendpunkte anzeigen. Integritätstests verwenden Integritätsüberwachungsdaten, um Informationen bereitzustellen. Der primäre Load Balancer verwendet diese Informationen, um die fehlerhafte Komponente sofort zu entfernen.

Diese Architektur wendet die Integritätsüberwachung auf folgenden Ebenen an:

• Auf der Ebene der Workloadpods, die in AKS ausgeführt werden. Diese Pods verfügen über Integritäts- und Livetests, sodass AKS ihren Lebenszyklus verwalten kann.

• Auf der Ebene des Integritätsdiensts, der eine dedizierte Komponente im Cluster ist. Azure Front Door ist für Tests des Integritätsdiensts in jedem Stempel und die Entfernung fehlerhafter Stempel aus dem automatischen Lastausgleich konfiguriert.

Details zur Implementierung des Integritätsdiensts

HealthService ist eine Workloadkomponente, die zusammen mit anderen Komponenten auf dem Computecluster ausgeführt wird, z. B. CatalogService und BackgroundProcessor. HealthService stellt eine REST-API bereit, die während der Azure Front Door-Integritätsprüfung aufgerufen wird, um die Verfügbarkeit eines Stempels zu ermitteln. Im Gegensatz zu einfachen Livetests ist der Integritätsdienst eine komplexere Komponente, die zusätzlich zu Daten zum eigenen Zustand auch Daten zum Zustand von Abhängigkeiten bereitstellt.

Der Integritätsdienst reagiert nicht, wenn der AKS-Cluster ausgefallen ist. Damit wird der Workload fehlerhaft. Wenn der Dienst ausgeführt wird, überprüft er regelmäßig die kritischen Komponenten der Lösung. Alle Prüfungen werden asynchron und parallel durchgeführt. Wenn eine Überprüfung fehlschlägt, ist der gesamte Stempel nicht verfügbar.

Der Integritätsdienst wird auch für explizit konfigurierte URL-Pingtests mit der Application Insights-Ressource der einzelnen Stempel verwendet.

Weitere Informationen zur HealthService-Implementierung finden Sie unter Anwendungsintegritätsdienst.

Nächster Schritt