Zagadnienia dotyczące projektowania aplikacji dla obciążeń o znaczeniu krytycznym

Podstawowa architektura referencyjna o znaczeniu krytycznym używa prostej aplikacji katalogu online w celu zilustrowania wysoce niezawodnego obciążenia. Użytkownicy mogą przeglądać wykaz elementów, przeglądać szczegóły elementów oraz publikować oceny i komentarze dla elementów. Ten artykuł koncentruje się na aspektach niezawodności i odporności aplikacji o znaczeniu krytycznym, takich jak przetwarzanie żądań asynchronicznych i sposób osiągnięcia wysokiej przepływności w ramach rozwiązania.

Ważne

Implementacja referencyjna klasy produkcyjnej, która prezentuje programowanie aplikacji o znaczeniu krytycznym na pomoc techniczna platformy Azure wskazówki zawarte w tym artykule. Możesz użyć tej implementacji jako podstawy do dalszego opracowywania rozwiązań w pierwszym kroku w kierunku produkcji.

Skład aplikacji

W przypadku aplikacji o kluczowym znaczeniu na dużą skalę należy zoptymalizować architekturę pod kątem kompleksowej skalowalności i odporności. Składniki można rozdzielić na jednostki funkcjonalne, które mogą działać niezależnie. Zastosuj tę separację na wszystkich poziomach na stosie aplikacji, aby każda część systemu mogła być skalowana niezależnie i spełniać zmiany zapotrzebowania. Implementacja demonstruje to podejście.

Aplikacja używa bezstanowych punktów końcowych interfejsu API, które oddzielają długotrwałe żądania zapisu asynchronicznie za pośrednictwem brokera obsługi komunikatów. Kompozycja obciążenia umożliwia usunięcie i ponowne utworzenie całych klastrów usługi Azure Kubernetes Service (AKS) i innych zależności w sygnaturze w dowolnym momencie. Główne składniki aplikacji to:

• Interfejs użytkownika: jednostronicowa aplikacja internetowa, do którego użytkownicy mogą uzyskiwać dostęp. Interfejs użytkownika jest hostowany w statycznej witrynie internetowej konta usługi Azure Storage.

• Interfejs API (CatalogService): interfejs API REST wywoływany przez aplikację interfejsu użytkownika, ale nadal dostępny dla innych potencjalnych aplikacji klienckich.

• Proces roboczy (BackgroundProcessor): Proces roboczy w tle, który nasłuchuje nowych zdarzeń w magistrali komunikatów i przetwarza żądania zapisu w bazie danych. Ten składnik nie uwidacznia żadnych interfejsów API.

• Interfejs API usługi kondycji (HealthService): interfejs API, który raportuje kondycję aplikacji, sprawdzając, czy składniki krytyczne działają, takie jak baza danych lub magistrala komunikatów.

  

Obciążenie składa się z interfejsu API, procesu roboczego i aplikacji do sprawdzania kondycji. Dedykowana przestrzeń nazw usługi AKS o nazwie workload hostuje obciążenie jako kontenery. Żadna bezpośrednia komunikacja między zasobnikami nie występuje. Zasobniki są bezstanowe i mogą być skalowane niezależnie.

Inne składniki pomocnicze uruchamiane w klastrze obejmują:

• Kontroler ruchu przychodzącego NGINX: kieruje żądania przychodzące do obciążenia i równoważenia obciążenia między zasobnikami. Kontroler ruchu przychodzącego NGINX jest uwidaczniany za pośrednictwem usługi Azure Load Balancer z publicznym adresem IP, ale można uzyskać do tego dostępu tylko za pośrednictwem usługi Azure Front Door.

• Menedżer certyfikatów: automatyczne aprowizacja certyfikatów protokołu Transport Layer Security (TLS) firmy Jetstack cert-manager przy użyciu polecenia Let's Encrypt dla reguł ruchu przychodzącego.

• Sterownik CSI magazynu wpisów tajnych: dostawca usługi Azure Key Vault dla sterownika CSI magazynu wpisów tajnych bezpiecznie odczytuje wpisy tajne, takie jak parametry połączenia z usługi Key Vault.

• Agent monitorowania: domyślna konfiguracja OMSAgentForLinux jest dostosowywana w celu zmniejszenia ilości danych monitorowania wysyłanych do obszaru roboczego Dzienniki usługi Azure Monitor.

Połączenie z bazą danych

Ze względu na efemeryczny charakter sygnatur wdrażania należy unikać utrwalania stanu w sygnaturze tak bardzo, jak to możliwe. Stan należy zachować w zewnętrznym magazynie danych. Aby zapewnić obsługę celu poziomu usług niezawodności (SLO), utwórz odporny magazyn danych. Zalecamy używanie rozwiązań zarządzanych lub platform jako usługi (PaaS) w połączeniu z natywnymi bibliotekami zestawu SDK, które automatycznie obsługują przekroczenia limitu czasu, rozłączenia i inne stany awarii.

W implementacji referencyjnej usługa Azure Cosmos DB służy jako główny magazyn danych dla aplikacji. Usługa Azure Cosmos DB zapewnia zapisy w wielu regionach. Każda sygnatura może zapisywać w repliki usługi Azure Cosmos DB w tym samym regionie, a usługa Azure Cosmos DB wewnętrznie obsługuje replikację danych i synchronizację między regionami. Usługa Azure Cosmos DB for NoSQL obsługuje wszystkie możliwości aparatu bazy danych.

Aby uzyskać więcej informacji, zobacz Platforma danych dla obciążeń o znaczeniu krytycznym.

Uwaga

Użyj usługi Azure Cosmos DB for NoSQL dla nowych aplikacji. W przypadku starszych aplikacji korzystających z innego protokołu NoSQL oceń ścieżkę migracji do usługi Azure Cosmos DB.

W przypadku aplikacji o krytycznym znaczeniu, które priorytetują dostępność w zakresie wydajności, zalecamy zapis w jednym regionie i odczyt w wielu regionach z silnym poziomem spójności .

Ta architektura używa usługi Storage do tymczasowego przechowywania stanu w sygnaturze dla punktów kontrolnych usługi Azure Event Hubs.

Wszystkie składniki obciążenia używają zestawu .NET Core SDK usługi Azure Cosmos DB do komunikowania się z bazą danych. Zestaw SDK zawiera niezawodną logikę do obsługi połączeń bazy danych i obsługi błędów. Ustawienia konfiguracji klucza obejmują:

• Tryb łączności bezpośredniej: to ustawienie jest ustawieniem domyślnym dla zestawu .NET SDK w wersji 3, ponieważ zapewnia lepszą wydajność. Tryb bezpośredniej łączności ma mniej przeskoków sieciowych w porównaniu z trybem bramy, który używa protokołu HTTP.

• Zwracanie odpowiedzi na zawartość podczas zapisu: to podejście jest wyłączone, aby klient usługi Azure Cosmos DB nie mógł zwrócić dokumentu z operacji tworzenia, upsert i poprawek oraz zastępowania, co zmniejsza ruch sieciowy. Dalsze przetwarzanie na kliencie nie wymaga tego ustawienia.

• Serializacja niestandardowa: ten proces ustawia zasady nazewnictwa właściwości JSON, aby JsonNamingPolicy.CamelCase przetłumaczyć właściwości platformy .NET na standardowe właściwości JSON. Może również tłumaczyć właściwości JSON na właściwości platformy .NET. Domyślny warunek ignorowania ignoruje właściwości z wartościami null, takimi jak JsonIgnoreCondition.WhenWritingNull, podczas serializacji.

• ApplicationRegion: ta właściwość jest ustawiona na region sygnatury, co umożliwia zestawowi SDK znalezienie najbliższego punktu końcowego połączenia. Punkt końcowy powinien znajdować się w tym samym regionie.

W implementacji referencyjnej zostanie wyświetlony następujący blok kodu:

//
// /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();

Asynchroniczne komunikaty

Podczas implementowania luźnego sprzężenia usługi nie mają zależności od innych usług. Luźny aspekt umożliwia niezależne działanie usługi. Aspekt sprzężenia umożliwia komunikację między usługami za pośrednictwem dobrze zdefiniowanych interfejsów. W przypadku aplikacji o krytycznym znaczeniu luźne sprzęganie zapobiega awariom podrzędnym kaskadowym do frontonów lub innych sygnatur wdrożenia, co zapewnia wysoką dostępność.

Najważniejsze cechy asynchronicznej obsługi komunikatów obejmują:

• Usługi nie muszą używać tej samej platformy obliczeniowej, języka programowania ani systemu operacyjnego.

• Usługi są skalowane niezależnie.

• Błędy podrzędne nie wpływają na transakcje klienta.

• Integralność transakcyjna jest trudna do utrzymania, ponieważ tworzenie i trwałość danych występują w oddzielnych usługach. Integralność transakcyjna jest wyzwaniem dla usług obsługi komunikatów i trwałości. Aby uzyskać więcej informacji, zobacz Idempotentne przetwarzanie komunikatów.

• Kompleksowe śledzenie wymaga złożonej aranżacji.

Zalecamy używanie dobrze znanych wzorców projektowych, takich jak wzorzec bilansowania obciążenia opartego na kolejce i wzorzec konkurujących odbiorców. Te wzorce rozkładają obciążenie od producenta do odbiorców i umożliwiają asynchroniczne przetwarzanie przez konsumentów. Na przykład proces roboczy umożliwia interfejsowi API akceptowanie żądania i szybkie powrót do wywołującego, a proces roboczy przetwarza operację zapisu bazy danych oddzielnie.

Komunikaty brokerów usługi Event Hubs między interfejsem API i procesem roboczym.

Ważne

Nie używaj brokera komunikatów jako trwałego magazynu danych przez długi czas. Usługa Event Hubs obsługuje funkcję przechwytywania. Funkcja przechwytywania umożliwia centrum zdarzeń automatyczne zapisywanie kopii komunikatów na połączonym koncie usługi Storage. Ten proces kontroluje użycie i służy jako mechanizm tworzenia kopii zapasowych komunikatów.

Szczegóły implementacji operacji zapisu

Operacje zapisu, takie jak ocena postów i komentarz post, są przetwarzane asynchronicznie. Interfejs API najpierw wysyła komunikat ze wszystkimi odpowiednimi informacjami, takimi jak typ akcji i dane komentarza, do kolejki komunikatów i natychmiast zwraca HTTP 202 (Accepted) Location nagłówek obiektu, który zostanie utworzony.

BackgroundProcessor wystąpienia przetwarzają komunikaty w kolejce i obsługują rzeczywistą komunikację bazy danych na potrzeby operacji zapisu. BackgroundProcessor skaluje i skaluje w poziomie dynamicznie na podstawie woluminu komunikatów w kolejce. Limit skalowania w poziomie wystąpień procesora jest definiowany przez maksymalną liczbę partycji usługi Event Hubs, czyli 32 dla warstw Podstawowa i Warstwy Standardowa, 100 dla warstwy Premium i 1024 dla warstwy Dedykowanej.

Biblioteka procesora usługi Azure Event Hubs w programie BackgroundProcessor używa usługi Azure Blob Storage do zarządzania własnością partycji, równoważenia obciążenia między różnymi wystąpieniami procesów roboczych i używania punktów kontrolnych do śledzenia postępu. Punkty kontrolne nie są zapisywane w magazynie obiektów blob po każdym zdarzeniu, ponieważ dodaje kosztowne opóźnienie dla każdego komunikatu. Zamiast tego punkty kontrolne są zapisywane w pętli czasomierza i można skonfigurować czas trwania. Ustawienie domyślne to 10 sekund.

W implementacji referencyjnej zostanie wyświetlony następujący blok kodu:

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);
        }
    }
}

Jeśli aplikacja procesora napotka błąd lub zostanie zatrzymana, zanim będzie mogła przetworzyć komunikat:

• Inne wystąpienie pobiera komunikat do ponownego przetwarzania, ponieważ nie został prawidłowo ustawiony w usłudze Storage.

• Konflikt występuje, jeśli poprzedni proces roboczy utrwali dokument w bazie danych przed niepowodzeniem procesu roboczego. Ten błąd występuje, ponieważ używany jest ten sam identyfikator i klucz partycji. Procesor może bezpiecznie zignorować komunikat, ponieważ dokument jest już utrwalone.

• Nowe wystąpienie powtarza kroki i finalizuje trwałość, jeśli poprzedni proces roboczy został zakończony przed zapisem do bazy danych.

Szczegóły implementacji operacji odczytu

Interfejs API bezpośrednio przetwarza operacje odczytu i natychmiast zwraca dane z powrotem do użytkownika.

Metoda zaplecza nie jest ustanawiana w celu komunikowania się z klientem, jeśli operacja zakończy się pomyślnie. Aplikacja kliencka musi aktywnie sondować interfejs API pod kątem aktualizacji dotyczących elementu określonego w nagłówku Location HTTP.

Skalowalność

Poszczególne składniki obciążenia powinny być skalowane niezależnie, ponieważ każdy składnik ma różne wzorce obciążenia. Wymagania dotyczące skalowania zależą od funkcjonalności usługi. Niektóre usługi mają bezpośredni wpływ na użytkowników i muszą być skalowane w poziomie agresywnie, aby zapewnić szybkie odpowiedzi i pozytywne środowisko użytkownika.

Implementacja pakuje usługi jako obrazy kontenerów i używa wykresów Helm do wdrażania usług w każdej sygnaturze. Usługi są skonfigurowane pod kątem oczekiwanych żądań i limitów platformy Kubernetes oraz wstępnie skonfigurowanej reguły automatycznego skalowania. Składniki CatalogService obciążenia i BackgroundProcessor mogą być skalowane pojedynczo i skalowane w poziomie, ponieważ obie usługi są bezstanowe.

Użytkownicy komunikują się bezpośrednio z elementem CatalogService, więc ta część obciążenia musi odpowiadać pod każdym obciążeniem. Istnieje co najmniej trzy wystąpienia dla każdego klastra, które mają być rozmieszczone w trzech strefach dostępności w regionie świadczenia usługi Azure. Narzędzie do automatycznego skalowania zasobników w poziomie (HPA) w usłudze AKS automatycznie dodaje więcej zasobników zgodnie z potrzebami. Funkcja automatycznego skalowania usługi Azure Cosmos DB może dynamicznie zwiększać i zmniejszać liczbę jednostek żądań (RU) dostępnych dla kolekcji. Usługa CatalogService Azure Cosmos DB łączy się w celu utworzenia jednostki skalowania w ramach sygnatury.

Narzędzie HPA jest wdrażane przy użyciu pakietu Helm, który ma konfigurowalną maksymalną liczbę i minimalną liczbę replik. Test obciążeniowy ustalił, że każde wystąpienie może obsłużyć około 250 żądań na sekundę ze standardowym wzorcem użycia.

Usługa BackgroundProcessor ma inne wymagania i jest traktowana jako proces roboczy w tle, który ma ograniczony wpływ na środowisko użytkownika. W związku BackgroundProcessor z tym ma inną konfigurację automatycznego skalowania w porównaniu z CatalogServicewartością i może być skalowana między 2 i 32 wystąpieniami. Określ ten limit na podstawie liczby partycji używanych w centrach zdarzeń. Nie potrzebujesz więcej procesów roboczych niż partycji.

Składnik	minReplicas	maxReplicas
CatalogService	3	20
BackgroundProcessor	2	32

Każdy składnik obciążenia, który zawiera zależności, na przykład ingress-nginx ma ustawienie budżetów zakłóceń zasobników (PDB) skonfigurowane w celu zapewnienia minimalnej liczby wystąpień, gdy zmienią się klastry.

W implementacji referencyjnej zostanie wyświetlony następujący blok kodu:

#
# /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 }}

Uwaga

Określ rzeczywistą minimalną liczbę i maksymalną liczbę zasobników dla każdego składnika za pośrednictwem testowania obciążenia. Liczba zasobników może się różnić dla każdego obciążenia.

Oprzyrządowanie

Instrumentacja służy do oceny szyi butelek wydajności i problemów ze kondycją, które składniki obciążenia mogą wprowadzać do systemu. Aby ułatwić określenie ilościowych decyzji, każdy składnik powinien emitować wystarczające informacje za pośrednictwem metryk i dzienników śledzenia. Podczas instrumentacja aplikacji należy wziąć pod uwagę następujące kluczowe zagadnienia:

• Wysyłaj dzienniki, metryki i inne dane telemetryczne do systemu dziennika sygnatury.
• Użyj rejestrowania strukturalnego zamiast zwykłego tekstu, aby można było wykonywać zapytania dotyczące informacji.
• Zaimplementuj korelację zdarzeń, aby uzyskać widok kompleksowej transakcji. W implementacji referencyjnej każda odpowiedź interfejsu API zawiera identyfikator operacji jako nagłówek HTTP umożliwiający śledzenie.
• Nie polegaj tylko na rejestrowaniu stdout ani rejestrowaniu konsoli. Można jednak użyć tych dzienników do natychmiastowego rozwiązywania problemów z zasobnikiem, który kończy się niepowodzeniem.

Ta architektura implementuje śledzenie rozproszone za pomocą usługi Application Insights i obszaru roboczego dzienników usługi Azure Monitor na potrzeby danych monitorowania aplikacji. Użyj dzienników usługi Azure Monitor, aby uzyskać dzienniki i metryki składników obciążenia i infrastruktury. Ta architektura implementuje kompleksowe śledzenie żądań pochodzących z interfejsu API, przechodzenie przez usługę Event Hubs, a następnie do usługi Azure Cosmos DB.

Ważne

Wdrażanie zasobów monitorowania sygnatur w oddzielnej grupie zasobów monitorowania. Zasoby mają inny cykl życia niż sam sygnatura. Aby uzyskać więcej informacji, zobacz Monitorowanie danych dla zasobów sygnatury.

Szczegóły implementacji monitorowania aplikacji

Składnik BackgroundProcessor używa Microsoft.ApplicationInsights.WorkerService pakietu NuGet w celu uzyskania gotowej instrumentacji z aplikacji. Narzędzie Serilog jest również używane do wszystkich rejestrowania wewnątrz aplikacji. Usługa Application Insights jest skonfigurowana jako ujście oprócz ujścia konsoli. TelemetryClient Wystąpienie usługi Application Insights jest używane bezpośrednio tylko wtedy, gdy jest konieczne śledzenie innych metryk.

W implementacji referencyjnej zostanie wyświetlony następujący blok kodu:

//
// /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();
    }

Aby zademonstrować praktyczną możliwość śledzenia żądań, każde pomyślne i nieudane żądanie interfejsu API zwraca nagłówek Identyfikator korelacji do obiektu wywołującego. Zespół pomocy technicznej aplikacji może przeszukiwać usługę Application Insights za pomocą tego identyfikatora i uzyskać szczegółowy widok pełnej transakcji, która jest pokazana na powyższym diagramie.

W implementacji referencyjnej zostanie wyświetlony następujący blok kodu:

//
// /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();
});

Uwaga

Próbkowanie adaptacyjne jest domyślnie włączone w zestawie SDK usługi Application Insights. Próbkowanie adaptacyjne oznacza, że nie każde żądanie jest wysyłane do chmury i można wyszukiwać według identyfikatora. Zespoły ds. aplikacji o krytycznym znaczeniu muszą niezawodnie śledzić każde żądanie, dlatego implementacja referencyjna ma wyłączone adaptacyjne próbkowanie w środowisku produkcyjnym.

Szczegóły implementacji monitorowania platformy Kubernetes

Ustawienia diagnostyczne umożliwiają wysyłanie dzienników i metryk usługi AKS do dzienników usługi Azure Monitor. Możesz również użyć funkcji analizy kontenera z usługą AKS. Włącz szczegółowe informacje o kontenerze, aby wdrożyć zestaw OMSAgentForLinux za pomocą zestawu DaemonSet platformy Kubernetes w każdym z węzłów w klastrach usługi AKS. Narzędzie OMSAgentForLinux może zbierać więcej dzienników i metryk z klastra Kubernetes i wysyłać je do odpowiedniego obszaru roboczego dzienników usługi Azure Monitor. Ten obszar roboczy zawiera szczegółowe dane dotyczące zasobników, wdrożeń, usług i ogólnej kondycji klastra.

Obszerne rejestrowanie może negatywnie wpływać na koszty i nie zapewnia korzyści. Z tego powodu zbieranie dzienników stdout i złomowanie Rozwiązania Prometheus są wyłączone dla zasobników obciążenia w konfiguracji usługi Container Insights, ponieważ wszystkie ślady są już przechwytywane za pośrednictwem usługi Application Insights, która generuje zduplikowane rekordy.

W implementacji referencyjnej zostanie wyświetlony następujący blok kodu:

#
# /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"]

Aby uzyskać więcej informacji, zobacz pełny plik konfiguracji.

Monitorowanie kondycji aplikacji

Monitorowanie i obserwowanie aplikacji umożliwia szybkie identyfikowanie problemów systemowych i informowanie modelu kondycji o bieżącym stanie aplikacji. Monitorowanie kondycji można wyświetlić za pośrednictwem punktów końcowych kondycji. Sondy kondycji używają danych monitorowania kondycji do dostarczania informacji. Główny moduł równoważenia obciążenia używa tych informacji, aby natychmiast zabrać składnik w złej kondycji z rotacji.

Ta architektura stosuje monitorowanie kondycji na następujących poziomach:

• Zasobniki obciążeń uruchamiane w usłudze AKS. Te zasobniki mają sondy kondycji i aktualności, dzięki czemu usługa AKS może zarządzać ich cyklem życia.

• Usługa kondycji, który jest dedykowanym składnikiem w klastrze. Usługa Azure Front Door jest skonfigurowana do sondowania Usługa kondycji w każdej sygnaturze i usuwania sygnatur w złej kondycji z automatycznego równoważenia obciążenia.

szczegóły implementacji Usługa kondycji

HealthService to składnik obciążenia, który działa wraz z innymi składnikami, takimi jak CatalogService i BackgroundProcessor, w klastrze obliczeniowym. HealthService Udostępnia interfejs API REST, który wywołuje sprawdzanie kondycji usługi Azure Front Door w celu określenia dostępności sygnatury. W przeciwieństwie do podstawowych sond liveness, Usługa kondycji jest bardziej złożonym składnikiem, który zapewnia stan zależności oprócz własnego stanu.

Usługa kondycji nie odpowiada, jeśli klaster usługi AKS nie działa, co sprawia, że obciążenie jest w złej kondycji. Po uruchomieniu usługi przeprowadza okresowe kontrole pod kątem krytycznych składników rozwiązania. Wszystkie kontrole są wykonywane asynchronicznie i równolegle. Jeśli którykolwiek z testów nie powiedzie się, cała sygnatura jest niedostępna.

Ostrzeżenie

Sondy kondycji usługi Azure Front Door mogą nakładać znaczne obciążenie na Usługa kondycji, ponieważ żądania pochodzą z wielu lokalizacji obecności (PoP). Aby zapobiec przeciążeniu składników podrzędnych, zaimplementuj efektywne buforowanie.

Usługa kondycji jest również używany do jawnie skonfigurowanych testów ping adresu URL z zasobem usługi Application Insights każdej sygnatury.

Aby uzyskać więcej informacji na temat implementacjiHealthService, zobacz Application Usługa kondycji.

Następny krok

Sieć i łączność dla obciążeń o znaczeniu krytycznym