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, son derece güvenilir bir iş yükünü göstermek için basit bir çevrimiçi katalog uygulaması kullanır. Kullanıcılar bir öğe kataloğuna göz atabilir, öğe ayrıntılarını gözden geçirebilir ve öğeler için derecelendirmeler ve açıklamalar gönderebilir. Bu makale, görev açısından kritik bir uygulamanın zaman uyumsuz istek işleme ve bir çözüm içinde yüksek aktarım hızı elde etme gibi güvenilirlik ve dayanıklılık özelliklerine odaklanır.

Önemli

Bu makaledeki yönergeleri Azure desteği görev açısından kritik uygulama geliştirmeyi gösteren üretim sınıfı başvuru uygulaması. Bu uygulamayı, üretime yönelik ilk adımınızda daha fazla çözüm geliştirme için temel olarak kullanabilirsiniz.

Uygulama yapısı

Yüksek ölçekli görev açısından kritik uygulamalarda mimariyi uçtan uca ölçeklenebilirlik ve dayanıklılık için iyileştirmeniz gerekir. Bileşenleri bağımsız olarak çalışabilen işlevsel birimlere ayırabilirsiniz. Sistemin her parçasının bağımsız olarak ölçeklenebilmesi ve talepteki değişiklikleri karşılayabilmesi için bu ayrımı uygulama yığınındaki tüm düzeylerde uygulayın. Uygulama bu yaklaşımı gösterir.

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ünün bileşimi, istediğiniz zaman damgadaki tüm Azure Kubernetes Service (AKS) kümelerini ve diğer bağımlılıkları silmenize ve yeniden oluşturmanıza olanak tanır. Uygulamanın ana bileşenleri şunlardır:

• Kullanıcı arabirimi (UI):Kullanıcıların erişebileceği tek sayfalı bir web uygulaması. Kullanıcı arabirimi bir Azure Depolama hesabının statik web sitesi barındırmasında barındırılır.

• API (CatalogService): Kullanıcı arabirimi uygulaması tarafından çağrılan ancak diğer olası istemci uygulamaları için hala kullanılabilen bir REST API.

• Çalışan (BackgroundProcessor): İleti veri yolu üzerinde yeni olayları dinleyen ve veritabanına yazma isteklerini işleyen bir arka plan çalışanı. Bu bileşen api'leri kullanıma sunmaz.

• Sistem sağlığı hizmeti API'si (HealthService): Veritabanı veya mesajlaşma veri yolu gibi kritik bileşenlerin çalışıp çalışmadığını denetleyerek uygulamanın durumunu bildiren bir API.

  

İş yükü API, çalışan ve sistem durumu denetimi uygulamalarından oluşur. adlı workload ayrılmış AKS ad alanı, iş yükünü kapsayıcı olarak barındırır. Podlar arasında doğrudan iletişim gerçekleşmez. Podlar durum bilgisi yoktur ve bağımsız olarak ölçeklendirilebilir.

Kümede çalışan diğer destekleyici bileşenler şunlardır:

• NGINX giriş denetleyicisi: Gelen istekleri iş yüküne yönlendirir ve podlar arasındaki yük dengelerini sağlar. NGINX giriş denetleyicisi genel IP adresiyle Azure Load Balancer aracılığıyla kullanıma sunulur ancak yalnızca Azure Front Door üzerinden erişilebilir.

• Sertifika yöneticisi: Jetstack'in cert-manager otomatik sağlaması, giriş kuralları için Let's Encrypt kullanarak Aktarım Katmanı Güvenliği (TLS) sertifikalarını sağlar.

• Gizli Dizi Deposu CSI Sürücüsü: Gizli Dizi Deposu için Azure Key Vault sağlayıcısı CSI Sürücüsü, Key Vault'tan bağlantı dizesi gibi gizli dizileri güvenli bir şekilde okur.

• İzleme aracısı: Azure İzleyici Günlükleri çalışma alanına gönderilen izleme verilerinin miktarını azaltmak için varsayılan OMSAgentForLinux yapılandırması ayarlanır.

Veritabanı bağlantısı

Dağıtım damga 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. Dışlaştırılmış bir veri deposunda durumu kalıcı hale getirmelisiniz. Güvenilirlik hizmet düzeyi hedefini (SLO) desteklemek için dayanıklı bir veri deposu oluşturun. 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 veya hizmet olarak platform (PaaS) çözümleri kullanmanızı öneririz.

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ğlar. Her damga aynı bölgedeki Azure Cosmos DB çoğaltmasına yazabilir ve Azure Cosmos DB bölgeler arasında veri çoğaltmayı ve eşitlemeyi dahili olarak işler. NoSQL için Azure Cosmos DB, veritabanı altyapısının tüm özelliklerini destekler.

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

Not

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

Kullanılabilirliğe performansa göre öncelik veren görev açısından kritik uygulamalar için tek bölgeli yazma ve çok bölgeli okuma ile güçlü bir tutarlılık düzeyi kullanmanızı öneririz.

Bu mimaride Azure Event Hubs denetim noktası oluşturma damgasında durumu geçici olarak depolamak için Depolama 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ını korumak ve hataları işlemek için sağlam mantık içerir. Temel yapılandırma ayarları şunlardır:

• Doğrudan bağlantı modu: Daha iyi performans sunduğundan bu ayar .NET SDK v3 için varsayılan ayardır. Doğrudan bağlantı modu, HTTP kullanan Ağ Geçidi moduna kıyasla daha az ağ atlamasına sahiptir.

• Yazma işlemiyle içerik yanıtı döndür: Azure Cosmos DB istemcisinin oluşturma, yükseltme ve düzeltme eki uygulama ve değiştirme işlemlerinden belgeyi döndürememesini ve bu sayede ağ trafiğini azaltabilmesi için bu yaklaşım devre dışı bırakılır. İstemcide daha fazla işlem yapılması için bu ayar gerekmez.

• Özel serileştirme: Bu işlem, .NET özelliklerini standart JSON özelliklerine çevirmek için JsonNamingPolicy.CamelCase JSON özellik adlandırma ilkesini olarak ayarlar. Ayrıca JSON özelliklerini .NET özelliklerine de çevirebilir. Varsayılan yoksay koşulu, serileştirme sırasında gibi JsonIgnoreCondition.WhenWritingNullnull değerlere sahip özellikleri yoksayar.

• ApplicationRegion: Bu özellik, SDK'nın en yakın bağlantı uç noktasını bulmasını sağlayan damganın bölgesine ayarlanır. Uç nokta tercihen aynı bölgede olmalıdır.

Başvuru uygulamasında aşağıdaki kod bloğu görüntülenir:

//
// /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 bağlantı uyguladığınızda, hizmetlerin diğer hizmetlere bağımlılıkları yoktur. 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şim sağlar. Görev açısından kritik bir uygulama için gevşek bağlantı, aşağı akış hatalarının ön uçlara veya diğer dağıtım damgalarına basamaklanmasını önler ve bu da yüksek kullanılabilirlik sağlar.

Zaman uyumsuz mesajlaşmanın temel özellikleri şunlardır:

• Hizmetlerin aynı işlem platformunu, programlama dilini veya işletim sistemini kullanması gerekmez.

• 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 zordur. İşlem bütünlüğü, mesajlaşma ve kalıcılık hizmetleri arasında bir zorluktır. Daha fazla bilgi için bkz . Etkili ileti işleme.

• Uçtan uca izleme karmaşık düzenleme gerektirir.

Kuyruk Tabanlı Yük Dengeleme düzeni ve Rakip Tüketiciler deseni gibi iyi bilinen tasarım desenleri kullanmanızı öneririz. Bu desenler, yükü üreticiden tüketicilere dağıtır ve tüketiciler tarafından zaman uyumsuz işlemeyi etkinleştirir. Örneğin, çalışan API'nin isteği kabul edip çağrıyı yapana hızlı bir şekilde geri dönmesini sağlar ve çalışan bir veritabanı yazma işlemini ayrı olarak işler.

Event Hubs, API ile çalışan arasındaki iletileri aracılar.

Önemli

İleti aracısını uzun süreler boyunca kalıcı bir veri deposu olarak kullanmayın. Event Hubs hizmeti yakalama özelliğini destekler. Yakalama özelliği, bir olay hub'ının iletilerin bir kopyasını bağlı depolama hesabına otomatik olarak yazmasına olanak tanır. Bu işlem kullanımı denetler ve iletileri yedeklemek için bir mekanizma görevi görür.

Yazma işlemleri 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 üst bilgisini döndürür HTTP 202 (Accepted) Location .

BackgroundProcessor örnekler kuyruktaki iletileri işler ve yazma işlemleri için gerçek veritabanı iletişimini işler. BackgroundProcessor ölçeğini genişletebilir ve kuyruk ileti hacmine göre dinamik olarak ölçeği genişletebilir. İşlemci örneklerinin ölçeği genişletme sınırı, Temel katmanlar ve Standart katmanlar için 32, Premium katmanı için 100 ve Ayrılmış katman için 1.024 olan Event Hubs bölüm sayısı üst sınırıyla tanımlanır.

içindeki BackgroundProcessor Azure Event Hubs İşlemci kitaplığı bölüm sahipliğini yönetmek, farklı çalışan örnekleri arasında yük dengelemesi yapmak ve ilerleme durumunu izlemek için denetim noktalarını kullanmak için Azure Blob Depolama kullanır. Denetim noktaları her olaydan sonra blob depolamaya yazılamaz çünkü her ileti için pahalı bir gecikme ekler. Bunun yerine, denetim noktaları bir zamanlayıcı döngüsüne yazılır ve süreyi yapılandırabilirsiniz. Varsayılan ayar 10 saniyedir.

Başvuru uygulamasında aşağıdaki kod bloğu görüntülenir:

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 iletiyi yeniden işleme için alır.

• Önceki çalışan belgeyi çalışan başarısız olmadan önce veritabanında kalıcı hale getirdiyse çakışma oluşur. Aynı kimlik ve bölüm anahtarı kullanıldığından bu hata oluşur. Belge zaten kalıcı olduğundan işlemci iletiyi güvenle yoksayabilir.

• Yeni bir örnek, önceki çalışan veritabanına yazmadan önce sonlandırıldıysa adımları yineler ve kalıcılığı son haline döndürür.

Okuma işlemleri uygulama ayrıntıları

API doğrudan okuma işlemlerini işler ve verileri hemen kullanıcıya geri döndürür.

İşlem başarıyla tamamlanırsa istemciyle iletişim kurmak için bir arka kanal yöntemi oluşturulmaz. İstemci uygulamasının, HTTP üst bilgisinde belirtilen öğeyle ilgili güncelleştirmeler için API'yi proaktif olarak yoklaması Location gerekir.

Ölçeklenebilirlik

Her bileşenin farklı yük desenleri 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ı hizmetler kullanıcıları doğrudan etkiler ve hızlı yanıtlar ve olumlu bir kullanıcı deneyimi sağlamak için ölçeği agresif bir şekilde genişletmelidir.

Uygulama, hizmetleri kapsayıcı görüntüleri olarak paketler ve hizmetleri her damgaya dağıtmak için Helm grafiklerini kullanır. Hizmetler, 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 her iki hizmet de durum bilgisi olmadığından ve BackgroundProcessor iş yükü bileşenleri ölçeği daraltabilir ve ölçeği tek tek genişletebilir.

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. Her küme için bir Azure bölgesindeki üç kullanılabilirlik alanına yayılacak en az üç örnek vardır. AKS'deki yatay pod otomatik ölçeklendiricisi (HPA) gerektiğinde otomatik olarak daha fazla pod ekler. Azure Cosmos DB otomatik ölçeklendirme özelliği, koleksiyon için kullanılabilir istek birimlerini (RU) dinamik olarak artırabilir ve azaltabilir. CatalogService ve Azure Cosmos DB bir araya gelerek damga pulu içinde bir ölçek birimi oluşturur.

HPA, yapılandırılabilir en fazla sayıda ve en az çoğaltma sayısına sahip bir Helm grafiğiyle dağıtılır. Yük testi, her örneğin standart kullanım düzeniyle saniyede yaklaşık 250 istek işleyebildiğini belirledi.

Hizmetin BackgroundProcessor 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 , ile karşılaştırıldığında CatalogServicefarklı bir otomatik ölçeklendirme yapılandırmasına sahiptir ve 2 ile 32 örnek arasında ölçeklendirilebilir. Olay hub'larında kullandığınız bölüm sayısına göre bu sınırı belirleyin. Bölümlerden daha fazla çalışana ihtiyacınız yoktur.

Bileşen	minReplicas	maxReplicas
CatalogService	3	20
BackgroundProcessor	2	32

gibi ingress-nginx bağımlılıklar içeren iş yükünün her bileşeninde, kümeler değiştiğinde en az sayıda örneğin kullanılabilir kalmasını sağlamak için pod kesinti bütçeleri (PDB) ayarı yapılandırılmıştır.

Başvuru uygulamasında aşağıdaki kod bloğu görüntülenir:

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

Yük testi aracılığıyla her bileşen için gerçek minimum ve maksimum pod sayısını belirleyin. Pod sayısı her iş yükü için farklılık gösterebilir.

İzleme

performans şişesi boyunlarını ve iş yükü bileşenlerinin sisteme sokabileceği sistem durumu sorunlarını değerlendirmek için ölçüm aletini kullanın. Kararları ölçmenize yardımcı olmak için her bileşenin ölçümler ve izleme günlükleri aracılığıyla yeterli bilgi yayması gerekir. Uygulamanızı izlerken aşağıdaki önemli noktaları göz önünde bulundurun:

• Günlükleri, ölçümleri ve diğer telemetri verilerini damganın günlük sistemine gönderin.
• Bilgileri sorgulayabilmeniz için düz metin yerine yapılandırılmış günlüğe kaydetmeyi kullanın.
• Uçtan uca işlem görünümü elde etmek için olay bağıntısı uygulayın. Başvuru uygulamasında, her API yanıtı izlenebilirlik için HTTP üst bilgisi olarak bir İşlem Kimliği içerir.
• Yalnızca stdout günlüğüne veya konsol günlüğüne güvenmeyin. Ancak, başarısız olan pod sorunlarını hemen gidermek için bu günlükleri kullanabilirsiniz.

Bu mimari, Application Insights ile dağıtılmış izleme ve uygulama izleme verileri için bir Azure İzleyici Günlükleri çalışma alanı uygular. İş yükü ve altyapı bileşenlerinin günlükleri ve ölçümleri için Azure İzleyici Günlüklerini kullanın. Bu mimari API'den gelen, Event Hubs'dan geçen ve ardından Azure Cosmos DB'ye giden isteklerin tam uçtan uca izlemesini uygular.

Önemli

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

Uygulama izleme uygulama ayrıntıları

Bileşen, BackgroundProcessor uygulamadan kullanıma alınan izlemeleri almak için NuGet paketini kullanır Microsoft.ApplicationInsights.WorkerService . Serilog, uygulama içindeki tüm günlükler için de kullanılır. Application Insights, konsol havuzuna ek olarak havuz olarak yapılandırılır. TelemetryClient Application Insights örneği yalnızca diğer ölçümlerin izlenmesi gerektiğinde doğrudan kullanılır.

Başvuru uygulamasında aşağıdaki kod bloğu görüntülenir:

//
// /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, başarılı ve başarısız olan her API isteği, çağırana Bağıntı Kimliği üst bilgisini döndürür. Uygulama destek ekibi bu tanımlayıcıyla Application Insights'ta arama yapabilir ve önceki diyagramda gösterilen işlemin tamamının ayrıntılı bir görünümünü alabilir.

Başvuru uygulamasında aşağıdaki kod bloğu görüntülenir:

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

Uyarlamalı örnekleme, Application Insights SDK'sında varsayılan olarak etkinleştirilir. Uyarlamalı örnekleme, 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 izlemesi gerekir. Bu nedenle başvuru uygulaması, üretim ortamında uyarlamalı örneklemeyi devre dışı bırakmıştır.

Kubernetes izleme uygulama ayrıntıları

Azure İzleyici Günlüklerine AKS günlüklerini ve ölçümlerini göndermek için tanılama ayarlarını kullanabilirsiniz. Aks ile kapsayıcı içgörüleri özelliğini de kullanabilirsiniz. AKS kümelerindeki düğümlerin her birine kubernetes DaemonSet aracılığıyla OMSAgentForLinux dağıtmak için kapsayıcı içgörülerini etkinleştirin. OMSAgentForLinux, Kubernetes kümesi içinden daha fazla günlük ve ölçüm toplayabilir ve bunları ilgili Azure İzleyici Günlükleri çalışma alanına gönderebilir. Bu çalışma alanı podlar, dağıtımlar, hizmetler ve kümenin genel durumu hakkında ayrıntılı veriler içerir.

Kapsamlı günlük kaydı maliyeti olumsuz etkileyebilir ve avantaj sağlamaz. Bu nedenle, tüm izlemeler yinelenen kayıtlar oluşturan Application Insights aracılığıyla zaten yakalandığından, kapsayıcı içgörüleri 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.

Başvuru uygulamasında aşağıdaki kod bloğu görüntülenir:

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

Daha fazla bilgi için bkz . tam yapılandırma dosyası.

Uygulama durumu izleme

Sistem sorunlarını hızla belirlemek ve sistem durumu modelini geçerli uygulama durumu hakkında bilgilendirmek için uygulama izleme ve gözlemlenebilirliği kullanabilirsiniz. Sistem durumu izlemesini sistem durumu uç noktaları aracılığıyla ortaya çıkarabilirsiniz. Sistem durumu yoklamaları , bilgi sağlamak için sistem durumu izleme verilerini kullanır. Ana yük dengeleyici, iyi durumda olmayan bileşeni döndürmeden hemen çıkarmak için bu bilgileri kullanır.

Bu mimari aşağıdaki düzeylerde sistem durumu izlemeyi uygular:

• 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.

• kümedeki ayrılmış bir bileşen olan Sistem Sağlığı Hizmeti. Azure Front Door, her damga pulundaki Sistem Sağlığı Hizmeti yoklayıp otomatik olarak yük dengelemeden iyi durumda olmayan damgaları kaldıracak şekilde yapılandırılır.

uygulama ayrıntılarını Sistem Sağlığı Hizmeti

HealthService, işlem kümesinde ve BackgroundProcessorgibi CatalogService diğer bileşenlerle birlikte çalışan bir iş yükü bileşenidir. HealthService , damga pulu kullanılabilirliğini belirlemek için Azure Front Door sistem durumu denetimi çağrıları sağlayan bir REST API sağlar. Temel canlılık yoklamalarından farklı olarak, Sistem Sağlığı Hizmeti kendi durumuna ek olarak bağımlılıkların durumunu sağlayan daha karmaşık bir bileşendir.

Sistem Sağlığı Hizmeti AKS kümesi kapatılırsa yanıt vermez ve bu da iş yükünü iyi durumdan çıkartır. Hizmet çalıştırıldığında, çö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. Denetimlerden herhangi biri başarısız olursa, damganın tamamı kullanılamaz.

Uyarı

İstekler birden çok iletişim noktası (PoP) konumundan geldiğinden Azure Front Door sistem durumu yoklamaları Sistem Sağlığı Hizmeti önemli yük oluşturabilir. Aşağı akış bileşenlerinin aşırı yüklenmesini önlemek için etkili önbelleğe alma uygulayın.

Sistem Sağlığı 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 HealthService daha fazla bilgi için bkz. Uygulama Sistem Sağlığı Hizmeti.

Sonraki adım

Görev açısından kritik iş yükleri için ağ ve bağlantı