Görev açısından kritik iş yükleri için uygulama tasarımında dikkat edilmesi gerekenler

Temel görev açısından kritik başvuru mimarisi, basit bir çevrimiçi katalog uygulaması aracılığıyla son derece güvenilir bir iş yükünü gösterir. Son kullanıcılar bir öğe kataloğuna göz atabilir, öğenin ayrıntılarını görebilir ve öğeler için derecelendirmeler ve açıklamalar gönderebilir. Bu makale, isteklerin zaman uyumsuz olarak işlenmesi ve bir çözüm içinde yüksek aktarım hızı elde etme gibi görev açısından kritik bir uygulamanın güvenilirlik ve dayanıklılık özelliklerine odaklanır.

Önemli

Bu kılavuz, Azure'da görev açısından kritik uygulama geliştirmeyi gösteren üretim sınıfı başvuru uygulaması tarafından desteklenir. Bu uygulama, üretime yönelik ilk adımınızda daha fazla çözüm geliştirme için temel olarak kullanılabilir.

Uygulama yapısı

Yüksek ölçekli görev açısından kritik uygulamalar için mimariyi uçtan uca ölçeklenebilirlik ve dayanıklılık için iyileştirmek önemlidir. Bu durum, bileşenlerin bağımsız olarak çalışabilen işlevsel birimlere ayrılmasıyla elde edilebilir. Bu ayrımı uygulama yığınındaki tüm düzeylerde uygulayarak sistemin her bir bölümünün bağımsız olarak ölçeklendirilmesine ve talepteki değişiklikleri karşılamasına olanak tanıyın.

Bu yaklaşımın bir örneği uygulamada gösterilmiştir. Uygulama, uzun süre çalışan yazma isteklerini bir mesajlaşma aracısı aracılığıyla zaman uyumsuz olarak ayıran durum bilgisi olmayan API uç noktalarını kullanır. İş yükü, tüm AKS kümesinin ve damgadaki diğer bağımlılıkların herhangi bir zamanda silinip yeniden oluşturulabileceği şekilde oluşturulur. Ana bileşenler şunlardır:

• Kullanıcı arabirimi (UI): Son kullanıcılar tarafından erişilen tek sayfalı web uygulaması, Azure Depolama Hesabının statik web sitesi barındırmasında barındırılır.
• API (CatalogService): UI uygulaması tarafından çağrılan ancak diğer olası istemci uygulamaları için kullanılabilen REST API.
• Çalışan (BackgroundProcessor): ileti veri yolu üzerindeki yeni olayları dinleyerek veritabanına yazma isteklerini işleyen arka plan çalışanı. Bu bileşen api'leri kullanıma sunmaz.
• Sistem sağlığı hizmeti API'si (): kritik bileşenlerin (HealthServiceveritabanı, mesajlaşma veri yolu) çalışıp çalışmadığı denetlenerek uygulamanın sistem durumunu bildirmek için kullanılır.

API, çalışan ve sistem durumu denetimi uygulamaları iş yükü olarak adlandırılır ve ayrılmış bir AKS ad alanında (olarak adlandırılır) workloadkapsayıcılar olarak barındırılır. Podlar arasında doğrudan iletişim yoktur . Podlar durum bilgisizdir ve bağımsız olarak ölçeklendirilebilir.

Kümede çalışan başka destekleyici bileşenler de vardır:

1. Giriş denetleyicisi: Nginx Giriş Denetleyicisi gelen istekleri iş yüküne yönlendirmek ve podlar arasında yük dengelemesi yapmak için kullanılır. Genel IP adresiyle (ancak yalnızca Azure Front Door üzerinden erişilir) Azure Load Balancer aracılığıyla kullanıma sunulur.
2. Sertifika yöneticisi: Jetstack'ler cert-manager , giriş kuralları için SSL/TLS sertifikalarını (Let's Encrypt kullanarak) otomatik olarak sağlamak için kullanılır.
3. CSI gizli dizi sürücüsü: Gizli Dizi deposu için Azure Key Vault Sağlayıcısı CSI, Azure Key Vault bağlantı dizeleri gibi gizli dizileri güvenli bir şekilde okumak için kullanılır.
4. İzleme aracısı: Log Analytics çalışma alanına gönderilen izleme verilerinin miktarını azaltmak için varsayılan OMSAgent yapılandırması ayarlanır.

Veritabanı bağlantısı

Dağıtım damgalarının kısa ömürlü yapısı nedeniyle, damga pulu içinde durumu mümkün olduğunca kalıcı hale getirmekten kaçının. Durum, dışlaştırılmış bir veri deposunda kalıcı olmalıdır. Güvenilirlik SLO'sunu desteklemek için bu veri deposunun dayanıklı olması gerekir. Zaman aşımlarını, bağlantı kesilmelerini ve diğer hata durumlarını otomatik olarak işleyen yerel SDK kitaplıklarıyla birlikte yönetilen (PaaS) hizmetleri kullanmanız önerilir.

Başvuru uygulamasında Azure Cosmos DB , uygulama için ana veri deposu görevi görür. Azure Cosmos DB, çok bölgeli yazma işlemleri sağladığından seçildi. Her damga pulu, Azure Cosmos DB'nin bölgeler arasında veri çoğaltmasını ve eşitlemesini dahili olarak işlemesiyle aynı bölgedeki Azure Cosmos DB çoğaltmasına yazabilir. NoSQL için Azure Cosmos DB , veritabanı altyapısının tüm özelliklerini desteklediğinden kullanılır.

Daha fazla bilgi için bkz. Görev açısından kritik iş yükleri için veri platformu.

Not

Yeni uygulamalar NoSQL için Azure Cosmos DB kullanmalıdır. Başka bir NoSQL protokolü kullanan eski uygulamalar için Azure Cosmos DB'ye geçiş yolunu değerlendirin.

İpucu

Performansa göre kullanılabilirliğe öncelik veren görev açısından kritik uygulamalar için güçlü tutarlılık düzeyiyle tek bölgeli yazma ve çok bölgeli okuma önerilir.

Bu mimaride, Event Hubs denetim noktası oluşturma damgasında durumu geçici olarak depolamanız gerekir. Azure Depolama bu amaçla kullanılır.

Tüm iş yükü bileşenleri veritabanıyla iletişim kurmak için Azure Cosmos DB .NET Core SDK'sını kullanır. SDK, veritabanı bağlantıları korumak ve hataları işlemek için sağlam bir mantık içerir. Bazı önemli yapılandırma ayarları şunlardır:

• Doğrudan bağlantı modunu kullanır. Bu, daha iyi performans sunduğundan .NET SDK v3 için varsayılan ayardır. HTTP kullanan Ağ Geçidi moduna kıyasla daha az ağ atlaması vardır.
• Azure Cosmos DB istemcisinin ağ trafiğini azaltmak için Oluşturma, Upsert, Patch ve Replace işlemlerinden belgeyi döndürmesini önlemek için yazma işlemiyle içerik döndürme yanıtı devre dışı bırakılır. Ayrıca, istemcide daha fazla işlem yapmak için bu gerekli değildir.
• JSON özellik adlandırma ilkesini çevrilecek şekilde ayarlamak için JsonNamingPolicy.CamelCaseözel serileştirme kullanılır. NET stili özellikleri standart JSON stilinde ve tam tersidir. Varsayılan yoksay koşulu, serileştirme (JsonIgnoreCondition.WhenWritingNull) sırasında null değerlerle özellikleri yoksayar.
• Uygulama bölgesi , SDK'nın en yakın bağlantı uç noktasını (tercihen aynı bölge içinde) bulmasını sağlayan damganın bölgesine ayarlanır.

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

Zaman uyumsuz mesajlaşma

Gevşek birleşim, hizmetlerin bir hizmetin diğer hizmetlere bağımlılığı olmayacak şekilde tasarlanmasına olanak tanır. Gevşek yönü, bir hizmetin bağımsız olarak çalışmasına olanak tanır. Bağlantı yönü, iyi tanımlanmış arabirimler aracılığıyla hizmetler arası iletişime olanak tanır. Görev açısından kritik bir uygulama bağlamında, aşağı akış hatalarının ön uçlara veya farklı dağıtım damgalarına basamaklı olmasını önleyerek yüksek kullanılabilirliği kolaylaştırır.

Temel özellikler:

• Hizmetler aynı işlem platformunu, programlama dilini veya işletim sistemini kullanacak şekilde kısıtlanmamıştır.
• Hizmetler bağımsız olarak ölçeklendirilir.
• Aşağı akış hataları istemci işlemlerini etkilemez.
• Veri oluşturma ve kalıcılık ayrı hizmetlerde gerçekleştiği için işlem bütünlüğünü korumak daha zordur. Bu, aynı zamanda bir kez etkili ileti işlemeye ilişkin bu kılavuzda açıklandığı gibi mesajlaşma ve kalıcılık hizmetlerinde de bir zorluk oluşturur.
• Uçtan uca izleme daha karmaşık düzenleme gerektirir.

Kuyruk Tabanlı Yük dengeleme düzeni ve Rakip Tüketiciler deseni gibi iyi bilinen tasarım desenlerinin kullanılması kesinlikle önerilir. Bu desenler, üreticiden tüketicilere yük dağıtımına ve tüketiciler tarafından zaman uyumsuz işlemeye yardımcı olur. Örneğin, çalışan API'nin isteği kabul etmesine ve bir veritabanı yazma işlemini ayrı olarak işlerken çağrıyı yapana hızlı bir şekilde dönmesine izin verir.

Azure Event Hubs, API ile çalışan arasında ileti aracısı olarak kullanılır.

Önemli

İleti aracısı uzun süre kalıcı bir veri deposu olarak kullanılmak üzere tasarlanmamıştır. Event Hubs hizmeti, olay hub'ının iletilerin bir kopyasını bağlantılı Bir Azure Depolama hesabına otomatik olarak yazmasına olanak tanıyan yakalama özelliğini destekler. Bu, kullanımın denetimde kalmasını sağlar, ancak iletileri yedeklemek için bir mekanizma görevi de görür.

Yazma işlemleri için uygulama ayrıntıları

Gönderi derecelendirmesi ve gönderi açıklaması gibi yazma işlemleri zaman uyumsuz olarak işlenir. API önce eylem türü ve açıklama verileri gibi tüm ilgili bilgileri içeren bir iletiyi ileti kuyruğuna gönderir ve hemen oluşturulacak nesnenin ek Location üst bilgisini döndürürHTTP 202 (Accepted).

Kuyruktaki iletiler daha sonra yazma işlemleri için gerçek veritabanı iletişimini işleyen örnekler tarafından BackgroundProcessor işlenir. BackgroundProcessor kuyruktaki ileti hacmine göre dinamik olarak ölçeği daraltıp genişletebilir. İşlemci örneklerinin ölçeği genişletme sınırı, en fazla Event Hubs bölümü sayısıyla tanımlanır (Temel ve Standart katmanlar için 32, Premium katmanı için 100 ve Ayrılmış katman için 1024'tür).

içindeki BackgroundProcessor Azure EventHub İşlemci kitaplığı bölüm sahipliğini yönetmek, farklı çalışan örnekleri arasında yük dengelemesi yapmak ve denetim noktalarını kullanarak ilerleme durumunu izlemek için Azure Blob Depolama kullanır. Denetim noktalarını blob depolamaya yazmak her olaydan sonra gerçekleşmez çünkü bu durum her ileti için çok pahalı bir gecikmeye neden olur. Bunun yerine, denetim noktası yazma işlemi bir zamanlayıcı döngüsünde gerçekleşir (geçerli 10 saniye ayarıyla yapılandırılabilir süre):

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

İşlemci uygulaması bir hatayla karşılaşırsa veya iletiyi işlemeden önce durdurulursa:

• Depolama'da doğru şekilde denetlenemediğinden, başka bir örnek yeniden işleme için iletiyi alır.
• Önceki çalışan başarısız olmadan önce belgeyi veritabanında kalıcı hale getirebildiyse, bir çakışma oluşur (aynı kimlik ve bölüm anahtarı kullanıldığından) ve işlemci iletiyi zaten kalıcı hale getirildiği için güvenle yoksayabilir.
• Önceki çalışan veritabanına yazmadan önce sonlandırıldıysa, yeni örnek adımları yineler ve kalıcılığı son haline döndürür.

Okuma işlemleri için uygulama ayrıntıları

Okuma işlemleri doğrudan API tarafından işlenir ve verileri kullanıcıya hemen geri döndürür.

İşlem başarıyla tamamlanırsa istemciyle iletişim kuran bir arka kanal yoktur. İstemci uygulamasının, HTTP üst bilgisinde belirtilen öğenin güncelleştirmeleri için API'yi proaktif olarak yoklaması Location gerekir.

Ölçeklenebilirlik

Her biri farklı yük desenlerine sahip olduğundan tek tek iş yükü bileşenlerinin ölçeği bağımsız olarak genişletilmelidir. Ölçeklendirme gereksinimleri, hizmetin işlevselliğine bağlıdır. Bazı hizmetlerin son kullanıcı üzerinde doğrudan etkisi vardır ve herhangi bir zamanda olumlu bir kullanıcı deneyimi ve performansı için hızlı yanıt sağlamak üzere ölçeğin agresif bir şekilde genişletilmesi beklenir.

Uygulamada hizmetler Docker kapsayıcıları olarak paketlenir ve her damgaya Helm grafikleri kullanılarak dağıtılır. Bunlar beklenen Kubernetes isteklerine ve sınırlarına ve önceden yapılandırılmış bir otomatik ölçeklendirme kuralına sahip olacak şekilde yapılandırılır. CatalogService ve BackgroundProcessor iş yükü bileşeni tek tek ölçeği genişletebilir ve her iki hizmet de durum bilgisi içermez.

Son kullanıcılar ile CatalogServicedoğrudan etkileşim kurar, bu nedenle iş yükünün bu bölümü herhangi bir yük altında yanıt vermelidir. Bir Azure bölgesindeki üç Kullanılabilirlik Alanları yayılan küme başına en az 3 örnek vardır. AKS yatay pod otomatik ölçeklendiricisi (HPA), gerekirse otomatik olarak daha fazla pod eklemeyi üstlenir ve Azure Cosmos DB otomatik ölçeklendirmesi koleksiyon için kullanılabilir RU'ları dinamik olarak artırabilir ve azaltabilir. ve Azure Cosmos DB birlikte CatalogService damga pulu içinde bir ölçek birimi oluşturur.

HPA, yapılandırılabilir maksimum ve minimum çoğaltma sayısına sahip bir Helm grafiğiyle dağıtılır. Değerler şu şekilde yapılandırılır:

Yük testi sırasında her örneğin standart kullanım deseniyle yaklaşık 250 istek/saniye işlemesi beklendiği belirlendi.

Hizmetin BackgroundProcessor çok farklı gereksinimleri vardır ve kullanıcı deneyimi üzerinde sınırlı etkisi olan bir arka plan çalışanı olarak kabul edilir. Bu nedenle, BackgroundProcessor farklı bir otomatik ölçeklendirme yapılandırmasına CatalogService sahiptir ve 2 ile 32 örnek arasında ölçeklendirilebilir (bu sınır Event Hubs'ta kullanılan bölüm sayısına bağlı olmalıdır; bölümlerden daha fazla çalışana sahip olmanın bir avantajı yoktur).

Bileşen	minReplicas	maxReplicas
CatalogService	3	20
BackgroundProcessor	2	32

Buna ek olarak, gibi ingress-nginx bağımlılıklar da dahil olmak üzere iş yükünün her bileşeninde, kümelerde değişiklikler dağıtıldığında her zaman en az sayıda örneğin kullanılabilir olmasını sağlamak için yapılandırılmış Pod Kesinti Bütçeleri (PDB) vardır.

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

Not

Her bileşen için gerçek minimum ve maksimum pod sayısı, yük testi aracılığıyla belirlenmelidir ve iş yükü başına farklılık gösterebilir.

İzleme

İzleme, performans şişesi boyunlarını ve iş yükü bileşenlerinin sisteme sokabileceği sistem durumu sorunlarını değerlendirmede önemli bir mekanizmadır. Her bileşen, kararların miktarını belirlemeye yardımcı olmak için ölçümler ve izleme günlükleri aracılığıyla yeterli bilgileri yaymalıdır. Uygulamanızı izleme konusunda dikkat edilmesi gereken bazı önemli noktalar aşağıdadır.

• Günlükleri, ölçümleri ve ek telemetri verilerini damganın günlük sistemine gönderin.
• Bilgilerin sorgulanabilmesi için düz metin yerine yapılandırılmış günlük kullanın.
• Uçtan uca işlem görünümünden emin olmak için olay bağıntısını uygulayın. RI'de her API yanıtı, izlenebilirlik için http üst bilgisi olarak İşlem Kimliği içerir.
• Yalnızca stdout (konsol) günlüğüne güvenmeyin. Ancak, bu günlükler başarısız podun hemen sorunlarını gidermek için kullanılabilir.

Bu mimari, tüm uygulama izleme verileri için Log Analytics Çalışma Alanı tarafından yedeklenen Application Insights ile dağıtılmış izleme uygular. Azure Log Analytics, tüm iş yükü ve altyapı bileşenlerinin günlükleri ve ölçümleri için kullanılır. İş yükü, Api'den Event Hubs aracılığıyla Azure Cosmos DB'ye gelen isteklerin tam uçtan uca izlemesini uygular.

Önemli

Damga izleme kaynakları ayrı bir izleme kaynak grubuna dağıtılır ve damganın kendisinden farklı bir yaşam döngüsüne sahiptir. Daha fazla bilgi için bkz. Damga kaynakları için verileri izleme.

Uygulama izleme için uygulama ayrıntıları

Bileşen, BackgroundProcessor uygulamadan kullanıma alınan izlemeleri almak için NuGet paketini kullanır Microsoft.ApplicationInsights.WorkerService . Ayrıca Serilog, havuz olarak yapılandırılmış Azure Uygulaması İçgörüleri (konsol havuzu yanında) ile uygulama içindeki tüm günlükler için kullanılır. Yalnızca ek ölçümleri izlemek için gerektiğinde, TelemetryClient application insights örneği doğrudan kullanılır.

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

Pratik istek izlenebilirliğini göstermek için her API isteği (başarılı veya değil) çağırana Bağıntı Kimliği üst bilgisini döndürür. Bu tanımlayıcı ile uygulama destek ekibi Application Insights'ta arama yapabilir ve işlemin tamamının ayrıntılı bir görünümünü alabilir.

//
// /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("X-Server-Location", sysConfig.AzureRegion);
            context.Response.Headers.Add("X-Correlation-ID", Activity.Current?.RootId);
            context.Response.Headers.Add("X-Requested-Api-Version", ctx.GetRequestedApiVersion()?.ToString());
        }
        return Task.CompletedTask;
    }, context);
    await next();
});

Not

Application Insights SDK'sı, uyarlamalı örneklemeyi varsayılan olarak etkinleştirmiştir. Bu, her isteğin buluta gönderilmediği ve kimliğe göre arandığı anlamına gelir. Görev açısından kritik uygulama ekiplerinin her isteği güvenilir bir şekilde izleyebilebilmesi gerektiğinden başvuru uygulamasında uyarlamalı örnekleme üretim ortamında devre dışı bırakılmıştır.

Kubernetes izleme uygulama ayrıntıları

AKS günlüklerini ve ölçümlerini Log Analytics'e göndermek için tanılama ayarlarının kullanılmasının yanı sıra AKS, Container Insights'ı kullanacak şekilde de yapılandırılır. Container Insights'ın etkinleştirilmesi, AKS kümelerindeki düğümlerin her birine kubernetes DaemonSet aracılığıyla OMSAgentForLinux dağıtır. OMSAgentForLinux, Kubernetes kümesi içinden ek günlükleri ve ölçümleri toplayabilir ve bunları ilgili Log Analytics çalışma alanına gönderir. Bu, podlar, dağıtımlar, hizmetler ve genel küme durumu hakkında daha ayrıntılı veriler içerir.

Kapsamlı günlük kaydı, hiçbir fayda sağlamazken maliyeti olumsuz etkileyebilir. Bu nedenle, tüm izlemeler Application Insights aracılığıyla yakalandığından ve yinelenen kayıtlar oluşturarak Container Insights yapılandırmasındaki iş yükü podları için stdout günlük koleksiyonu ve Prometheus kazıma devre dışı bırakılır .

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

Başvuru için yapılandırma dosyasının tamamına bakın.

Sistem durumu izleme

Uygulama izleme ve gözlemlenebilirlik yaygın olarak bir sistemle ilgili sorunları hızla belirlemek ve sistem durumu modelini geçerli uygulama durumu hakkında bilgilendirmek için kullanılır. Sistem durumu uç noktaları aracılığıyla ortaya çıkan ve sistem durumu yoklamaları tarafından kullanılan sistem durumu izleme, hemen eyleme dönüştürülebilen bilgiler sağlar ve genellikle ana yük dengeleyiciye iyi durumda olmayan bileşeni döndürmenin dışına çıkarma talimatı verir.

Mimaride sistem durumu izleme şu düzeylerde uygulanır:

• AKS üzerinde çalışan iş yükü podları. Bu podların sistem durumu ve canlılık yoklamaları olduğundan AKS yaşam döngülerini yönetebilir.
• Sistem sağlığı hizmeti , kümedeki ayrılmış bir bileşendir. Azure Front Door, her damga pulundaki sistem durumu hizmetlerini yoklayıp iyi durumda olmayan damgaları yük dengelemeden otomatik olarak kaldıracak şekilde yapılandırılır.

Sistem sağlığı hizmeti uygulama ayrıntıları

HealthService , işlem kümesindeki diğer bileşenler (CatalogService ve BackgroundProcessor) üzerinde çalışan bir iş yükü bileşenidir. Bir damganın kullanılabilirliğini belirlemek için Azure Front Door sistem durumu denetimi tarafından çağrılan bir REST API sağlar. Temel canlılık yoklamalarından farklı olarak, sistem sağlığı hizmeti kendi bağımlılıklarına ek olarak bağımlılıkların durumunu ekleyen daha karmaşık bir bileşendir.

AKS kümesi çalışmıyorsa sistem durumu hizmeti yanıt vermez ve iş yükünün iyi durumda olmadığını gösterir. Hizmet çalışırken, çözümün kritik bileşenlerine karşı düzenli aralıklarla denetimler gerçekleştirir. Tüm denetimler zaman uyumsuz ve paralel olarak yapılır. Bunlardan herhangi biri başarısız olursa tüm damga pulu kullanılamaz olarak kabul edilir.

Uyarı

İstekler birden çok PoP konumundan geldiğinden Azure Front Door sistem durumu yoklamaları sistem durumu hizmetinde önemli yük oluşturabilir. Aşağı akış bileşenlerinin aşırı yüklenmesini önlemek için uygun önbelleğe alma işleminin yapılması gerekir.

Sistem durumu hizmeti, her damganın Application Insights kaynağıyla açıkça yapılandırılmış URL ping testleri için de kullanılır.

Uygulama hakkında daha fazla ayrıntı için HealthService bkz. Uygulama Sistem Durumu Hizmeti.