اعتبارات تصميم التطبيقات لأحمال العمل الحرجة للمهام

تستخدم البنية المرجعية المهمة الأساسية تطبيق كتالوج بسيط عبر الإنترنت لتوضيح حمل عمل موثوق به للغاية. يمكن للمستخدمين الاستعراض عبر كتالوج العناصر ومراجعة تفاصيل العنصر ونشر التصنيفات والتعليقات للعناصر. تركز هذه المقالة على جوانب الموثوقية والمرونة للتطبيق الحرج للمهمة، مثل معالجة الطلبات غير المتزامنة وكيفية تحقيق معدل نقل عال داخل الحل.

هام

يدعم التنفيذ المرجعي لدرجة الإنتاج الذي يعرض تطوير التطبيقات ذات المهام الحرجة على Azure الإرشادات الواردة في هذه المقالة. يمكنك استخدام هذا التنفيذ كأساس لمزيد من تطوير الحلول في خطوتك الأولى نحو الإنتاج.

إنشاء التطبيق

بالنسبة للتطبيقات ذات المهام الحرجة على نطاق واسع، يجب تحسين البنية لقابلية التوسع والمرونة من طرف إلى طرف. يمكنك فصل المكونات إلى وحدات وظيفية يمكن أن تعمل بشكل مستقل. تطبيق هذا الفصل على جميع المستويات على مكدس التطبيق بحيث يمكن تغيير حجم كل جزء من النظام بشكل مستقل وتلبية التغييرات في الطلب. ويبين التنفيذ هذا النهج.

يستخدم التطبيق نقاط نهاية واجهة برمجة التطبيقات عديمة الحالة التي تقوم بفصل طلبات الكتابة طويلة الأمد بشكل غير متزامن من خلال وسيط مراسلة. يمكنك تكوين حمل العمل من حذف وإعادة إنشاء مجموعات Azure Kubernetes Service (AKS) بالكامل والتبعيات الأخرى في الطابع في أي وقت. المكونات الرئيسية للتطبيق هي:

• واجهة المستخدم (UI): تطبيق ويب من صفحة واحدة يمكن للمستخدمين الوصول إليه. تتم استضافة واجهة المستخدم في استضافة موقع ويب ثابت لحساب Azure Storage.

• API (CatalogService): واجهة برمجة تطبيقات REST التي يتم استدعاؤها بواسطة تطبيق واجهة المستخدم ولكنها لا تزال متاحة لتطبيقات العميل المحتملة الأخرى.

• العامل (BackgroundProcessor): عامل خلفية يستمع إلى أحداث جديدة على ناقل الرسالة ويعالج طلبات الكتابة إلى قاعدة البيانات. لا يعرض هذا المكون أي واجهات برمجة تطبيقات.

• Health service API (HealthService): واجهة برمجة تطبيقات تقوم بالإبلاغ عن صحة التطبيق عن طريق التحقق مما إذا كانت المكونات الهامة تعمل، مثل قاعدة البيانات أو ناقل المراسلة.

  

يتكون حمل العمل من تطبيقات API والعامل والتحقق من الصحة. تستضيف مساحة اسم AKS المخصصة التي تسمى workload حمل العمل كحاويات. لا يحدث أي اتصال مباشر بين القرون. الحجيرات عديمة الحالة ويمكن أن تتوسع بشكل مستقل.

تتضمن المكونات الداعمة الأخرى التي يتم تشغيلها في نظام المجموعة ما يلي:

• وحدة تحكم دخول NGINX: توجيه الطلبات الواردة إلى حمل العمل وموازنة التحميل بين القرون. يتم كشف وحدة تحكم دخول NGINX من خلال موازن تحميل Azure بعنوان IP عام ولكن لا يمكن الوصول إليها إلا من خلال Azure Front Door.

• مدير الشهادة: تقوم Jetstack cert-manager بالتزويد التلقائي لشهادات أمان طبقة النقل (TLS) باستخدام Let's Encrypt لقواعد الدخول.

• Secrets Store CSI Driver: يقرأ موفر Azure Key Vault لبرنامج تشغيل Secrets Store CSI البيانات السرية بأمان، مثل سلسلة الاتصال من Key Vault.

• عامل المراقبة: يتم ضبط تكوين OMSAgentForLinux الافتراضي لتقليل كمية بيانات المراقبة التي يتم إرسالها إلى مساحة عمل Azure Monitor Logs.

اتصال قاعدة البيانات

نظرا للطبيعة المؤقتة لطوابع النشر، تجنب استمرار الحالة داخل الطابع قدر الإمكان. يجب أن تستمر في الحالة في مخزن بيانات خارجي. لدعم هدف مستوى خدمة الموثوقية (SLO)، قم بإنشاء مخزن بيانات مرن. نوصي باستخدام حلول مدارة أو نظام أساسي كخدمة (PaaS) مع مكتبات SDK الأصلية التي تتعامل تلقائيا مع المهلات وقطع الاتصال وحالات الفشل الأخرى.

في التنفيذ المرجعي، يعمل Azure Cosmos DB كمخزن بيانات رئيسي للتطبيق. يوفر Azure Cosmos DB عمليات كتابة متعددة المناطق. يمكن لكل طابع الكتابة إلى النسخة المتماثلة Azure Cosmos DB في نفس المنطقة، ويتعامل Azure Cosmos DB داخليا مع النسخ المتماثل للبيانات والمزامنة بين المناطق. يدعم Azure Cosmos DB ل NoSQL جميع قدرات محرك قاعدة البيانات.

لمزيد من المعلومات، راجع النظام الأساسي للبيانات لأحمال العمل الحرجة للمهام.

إشعار

استخدم Azure Cosmos DB ل NoSQL للتطبيقات الجديدة. بالنسبة للتطبيقات القديمة التي تستخدم بروتوكول NoSQL آخر، قم بتقييم مسار الترحيل إلى Azure Cosmos DB.

بالنسبة للتطبيقات ذات المهام الحرجة التي تعطي الأولوية للتوفر على الأداء، نوصي بالكتابة في منطقة واحدة والقراءة متعددة المناطق بمستوى تناسق قوي.

تستخدم هذه البنية التخزين لتخزين الحالة مؤقتا في الطابع الخاص بنقاط تفتيش مراكز الأحداث Azure.

تستخدم جميع مكونات حمل العمل Azure Cosmos DB .NET Core SDK للاتصال بقاعدة البيانات. يتضمن SDK منطقا قويا للحفاظ على اتصالات قاعدة البيانات ومعالجة حالات الفشل. تتضمن إعدادات التكوين الرئيسية ما يلي:

• وضع الاتصال المباشر: هذا الإعداد هو الإعداد الافتراضي ل .NET SDK v3 لأنه يوفر أداء أفضل. يحتوي وضع الاتصال المباشر على قفزات شبكة أقل مقارنة بوضع البوابة، والذي يستخدم HTTP.

• إرجاع استجابة المحتوى عند الكتابة: تم تعطيل هذا الأسلوب بحيث لا يمكن لعميل Azure Cosmos DB إرجاع المستند من عمليات الإنشاء والتصحيح والتصحيح والاستبدال، مما يقلل من نسبة استخدام الشبكة. لا تتطلب المعالجة الإضافية على العميل هذا الإعداد.

• التسلسل المخصص: تعين هذه العملية نهج تسمية خاصية JSON لترجمة JsonNamingPolicy.CamelCase خصائص .NET إلى خصائص JSON القياسية. يمكن أيضا ترجمة خصائص JSON إلى خصائص .NET. يتجاهل شرط التجاهل الافتراضي الخصائص ذات القيم الخالية، مثل JsonIgnoreCondition.WhenWritingNull، أثناء التسلسل.

• ApplicationRegion: يتم تعيين هذه الخاصية إلى منطقة الطابع، والتي تمكن SDK من العثور على أقرب نقطة نهاية اتصال. يفضل أن تكون نقطة النهاية في نفس المنطقة.

تظهر كتلة التعليمات البرمجية التالية في التنفيذ المرجعي:

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

الرسائل الغير متزامنة

عند تنفيذ اقتران فضفاض، لا يكون للخدمات تبعيات على الخدمات الأخرى. يتيح الجانب غير المحكم للخدمة العمل بشكل مستقل. يتيح جانب الاقتران الاتصال بين الخدمات من خلال واجهات محددة جيدا. بالنسبة للتطبيق الحرج للمهمة، يمنع الاقتران الفضفاض حالات فشل انتقال البيانات من المراحل النهائية من التتالي إلى الواجهات الأمامية أو طوابع النشر الأخرى، ما يوفر توفرا عاليا.

تتضمن الخصائص الرئيسية للمراسلة غير المتزامنة ما يلي:

• لا يتعين على الخدمات استخدام نفس النظام الأساسي للحساب أو لغة البرمجة أو نظام التشغيل.

• تتوسع الخدمات بشكل مستقل.

• لا تؤثر حالات فشل انتقال البيانات من الخادم على معاملات العميل.

• من الصعب الحفاظ على تكامل المعاملات لأن إنشاء البيانات واستمرارها يحدثان في خدمات منفصلة. تعد تكامل المعاملات تحديا عبر خدمات المراسلة والمثابرة. لمزيد من المعلومات، راجع معالجة الرسائل المتكررة.

• يتطلب التتبع الشامل تنسيقا معقدا.

نوصي باستخدام أنماط تصميم معروفة، مثل نمط تسوية التحميل المستند إلى قائمة الانتظار ونمط المستهلكين المتنافسين. توزع هذه الأنماط الحمل من المنتج على المستهلكين وتمكن المعالجة غير المتزامنة من قبل المستهلكين. على سبيل المثال، يسمح العامل لواجهة برمجة التطبيقات بقبول الطلب والعودة بسرعة إلى المتصل، ويعالج العامل عملية كتابة قاعدة بيانات بشكل منفصل.

وسطاء مراكز الأحداث رسائل بين واجهة برمجة التطبيقات والعامل.

هام

لا تستخدم وسيط الرسائل كمخزن بيانات دائم لفترات طويلة من الوقت. تدعم خدمة مراكز الأحداث ميزة الالتقاط. تمكن ميزة الالتقاط مركز الأحداث من كتابة نسخة من الرسائل تلقائيا إلى حساب تخزين مرتبط. تتحكم هذه العملية في الاستخدام وتعمل كآلية لنسخ الرسائل احتياطيا.

تفاصيل تنفيذ عمليات الكتابة

تتم معالجة عمليات الكتابة، مثل تصنيف النشر والتعليق المنشور، بشكل غير متزامن. ترسل واجهة برمجة التطبيقات أولا رسالة تحتوي على جميع المعلومات ذات الصلة، مثل نوع الإجراء وبيانات التعليق، إلى قائمة انتظار الرسائل وترجع HTTP 202 (Accepted) على الفور مع Location رأس الكائن الذي سيتم إنشاؤه.

BackgroundProcessor تعالج المثيلات الرسائل في قائمة الانتظار وتعالج اتصال قاعدة البيانات الفعلي لعمليات الكتابة. BackgroundProcessor يتدرج ويتوسع بشكل ديناميكي استنادا إلى حجم رسالة قائمة الانتظار. يتم تحديد حد توسيع نطاق مثيلات المعالج من خلال الحد الأقصى لعدد أقسام مراكز الأحداث، وهو 32 للمستويات الأساسية والمستواني القياسية، و100 لطبقة Premium، و1024 للطبقة المخصصة.

تستخدم مكتبة Azure Event Hubs Processor في BackgroundProcessor Azure Blob Storage لإدارة ملكية القسم، وموازنة التحميل بين مثيلات العاملين المختلفة، واستخدام نقاط التحقق لتتبع التقدم. لا تتم كتابة نقاط التحقق إلى تخزين كائن ثنائي كبير الحجم بعد كل حدث لأنه يضيف تأخيرا مكلفا لكل رسالة. بدلا من ذلك، تتم كتابة نقاط التحقق على حلقة مؤقت، ويمكنك تكوين المدة. الإعداد الافتراضي هو 10 ثوان.

تظهر كتلة التعليمات البرمجية التالية في التنفيذ المرجعي:

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

إذا واجه تطبيق المعالج خطأ أو تم إيقافه قبل أن يتمكن من معالجة الرسالة:

• يلتقط مثيل آخر الرسالة لإعادة المعالجة لأنه لم يتم فحصها بشكل صحيح في التخزين.

• يحدث تعارض إذا استمر العامل السابق في الاحتفاظ بالمستند في قاعدة البيانات قبل فشل العامل. يحدث هذا الخطأ بسبب استخدام نفس المعرف ومفتاح القسم. يمكن للمعالج تجاهل الرسالة بأمان لأن المستند موجود بالفعل.

• يكرر مثيل جديد الخطوات وينهي الاستمرار إذا تم إنهاء العامل السابق قبل كتابته إلى قاعدة البيانات.

قراءة تفاصيل تنفيذ العمليات

تقوم واجهة برمجة التطبيقات بمعالجة عمليات القراءة مباشرة وإرجاع البيانات مرة أخرى إلى المستخدم على الفور.

لم يتم إنشاء أسلوب قناة خلفية للاتصال بالعميل إذا اكتملت العملية بنجاح. يجب أن يقوم تطبيق العميل باستطلاع واجهة برمجة التطبيقات بشكل استباقي للحصول على تحديثات حول العنصر المحدد في Location رأس HTTP.

قابلية التوسع

يجب توسيع مكونات حمل العمل الفردية بشكل مستقل لأن كل مكون له أنماط تحميل مختلفة. تعتمد متطلبات التحجيم على وظائف الخدمة. تؤثر بعض الخدمات بشكل مباشر على المستخدمين ويجب توسيع نطاقها بقوة لضمان استجابات سريعة وتجربة مستخدم إيجابية.

يحزم التنفيذ الخدمات كصور حاوية ويستخدم مخططات Helm لنشر الخدمات على كل طابع. يتم تكوين الخدمات ليكون لها طلبات وحدود Kubernetes المتوقعة وقاعدة تحجيم تلقائي تم تكوينها مسبقا في مكانها. CatalogService BackgroundProcessor يمكن توسيع ومكونات حمل العمل وتوسيع نطاقها بشكل فردي لأن كلتا الخدمتين عديمتي الجنسية.

يتفاعل المستخدمون مباشرة مع CatalogService، لذلك يجب أن يستجيب هذا الجزء من حمل العمل تحت أي تحميل. هناك ما لا يقل عن ثلاثة مثيلات لكل مجموعة للانتشار عبر ثلاث مناطق توفر في منطقة Azure. يضيف التحجيم التلقائي للجراب الأفقي (HPA) في AKS تلقائيا المزيد من الجرابات حسب الحاجة. يمكن لميزة التحجيم التلقائي ل Azure Cosmos DB زيادة وحدات الطلب (RUs) المتاحة للمجموعة وتقليلها ديناميكيا. يتم CatalogService دمج و Azure Cosmos DB لتشكيل وحدة مقياس داخل طابع.

يتم نشر HPA مع مخطط Helm يحتوي على الحد الأقصى لعدد قابل للتكوين والحد الأدنى لعدد النسخ المتماثلة. حدد اختبار التحميل أن كل مثيل يمكنه التعامل مع حوالي 250 طلبا في الثانية بنمط استخدام قياسي.

BackgroundProcessor الخدمة لها متطلبات مختلفة وتعتبر عامل خلفية له تأثير محدود على تجربة المستخدم. لذلك BackgroundProcessor لديه تكوين تحجيم تلقائي مختلف مقارنة ب CatalogService، ويمكن أن يتدرج بين مثيلين و32 مثيلا. حدد هذا الحد استنادا إلى عدد الأقسام التي تستخدمها في مراكز الأحداث. لا تحتاج إلى عدد من العمال أكثر من الأقسام.

المكون	minReplicas	maxReplicas
خدمة الكتالوج	3	20
معالج الخلفية	2	32

يحتوي كل مكون من مكونات حمل العمل الذي يتضمن تبعيات مثل ingress-nginx على إعداد ميزانيات تعطيل الجراب (PDBs) الذي تم تكوينه لضمان بقاء الحد الأدنى لعدد المثيلات متاحا عند تغيير المجموعات.

تظهر كتلة التعليمات البرمجية التالية في التنفيذ المرجعي:

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

إشعار

حدد الحد الأدنى الفعلي للعدد والحد الأقصى لعدد pods لكل مكون من خلال اختبار التحميل. يمكن أن يختلف عدد pods لكل حمل عمل.

تقرير عن حالة النظام

استخدم الأجهزة لتقييم رقبة زجاجة الأداء والمشاكل الصحية التي يمكن أن تدخلها مكونات حمل العمل في النظام. لمساعدتك في تحديد القرارات كميا، يجب أن يصدر كل مكون معلومات كافية من خلال المقاييس وسجلات التتبع. ضع في اعتبارك الاعتبارات الرئيسية التالية عند وضع علامة على التطبيق الخاص بك:

• إرسال السجلات والمقاييس وبيانات تتبع الاستخدام الأخرى إلى نظام سجل الطابع.
• استخدم التسجيل المنظم بدلا من النص العادي بحيث يمكنك الاستعلام عن المعلومات.
• تنفيذ ارتباط الحدث للحصول على طريقة عرض معاملة شاملة. في التنفيذ المرجعي، تحتوي كل استجابة لواجهة برمجة التطبيقات على معرف عملية كعنوان HTTP لقابلية التتبع.
• لا تعتمد فقط على تسجيل stdout أو تسجيل وحدة التحكم. ولكن يمكنك استخدام هذه السجلات لاستكشاف أخطاء جراب فاشلة على الفور.

تنفذ هذه البنية التتبع الموزع باستخدام Application Insights ومساحة عمل Azure Monitor Logs لبيانات مراقبة التطبيق. استخدم سجلات Azure Monitor لسجلات ومقاييس مكونات حمل العمل والبنية الأساسية. تنفذ هذه البنية التتبع الكامل من طرف إلى طرف للطلبات التي تأتي من واجهة برمجة التطبيقات، وتنتقل من خلال مراكز الأحداث، ثم إلى Azure Cosmos DB.

هام

نشر موارد مراقبة الطوابع إلى مجموعة موارد مراقبة منفصلة. الموارد لها دورة حياة مختلفة عن الطابع نفسه. لمزيد من المعلومات، راجع مراقبة البيانات لموارد الطابع.

تفاصيل تنفيذ مراقبة التطبيق

BackgroundProcessor يستخدم المكون حزمة Microsoft.ApplicationInsights.WorkerService NuGet للحصول على الأجهزة الجاهزة من التطبيق. يستخدم Serilog أيضا لجميع عمليات التسجيل داخل التطبيق. يتم تكوين Application Insights كمتلقي بالإضافة إلى متلقي وحدة التحكم. TelemetryClient يتم استخدام مثيل Application Insights مباشرة فقط عندما يكون من الضروري تتبع المقاييس الأخرى.

تظهر كتلة التعليمات البرمجية التالية في التنفيذ المرجعي:

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

لإثبات إمكانية تتبع الطلبات العملية، يقوم كل طلب API ناجح وغير ناجح بإرجاع عنوان معرف الارتباط إلى المتصل. يمكن لفريق دعم التطبيق البحث في Application Insights باستخدام هذا المعرف والحصول على عرض مفصل للمعاملة الكاملة، وهو موضح في الرسم التخطيطي السابق.

تظهر كتلة التعليمات البرمجية التالية في التنفيذ المرجعي:

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

إشعار

يتم تمكين أخذ العينات التكيفية بشكل افتراضي في Application Insights SDK. يعني أخذ العينات التكيفية أنه لا يتم إرسال كل طلب إلى السحابة ويمكن البحث فيه بواسطة المعرف. تحتاج فرق التطبيقات ذات المهام الحرجة إلى تتبع كل طلب بشكل موثوق، وهذا هو السبب في تعطيل أخذ العينات التكيفية في بيئة الإنتاج في التنفيذ المرجعي.

تفاصيل تنفيذ مراقبة Kubernetes

يمكنك استخدام إعدادات التشخيص لإرسال سجلات ومقاييس AKS إلى سجلات Azure Monitor. يمكنك أيضا استخدام ميزة نتائج تحليلات الحاوية مع AKS. تمكين نتائج تحليلات الحاوية لنشر OMSAgentForLinux من خلال Kubernetes DaemonSet على كل عقدة في مجموعات AKS. يمكن ل OMSAgentForLinux جمع المزيد من السجلات والمقاييس من داخل مجموعة Kubernetes وإرسالها إلى مساحة عمل Azure Monitor Logs المقابلة لها. تحتوي مساحة العمل هذه على بيانات دقيقة حول الحجيرات والنشرات والخدمات والصحة العامة للمجموعة.

يمكن أن يؤثر التسجيل الشامل سلبا على التكلفة ولا يوفر فوائد. لهذا السبب، يتم تعطيل جمع سجل stdout واستخراج Prometheus لقرون حمل العمل في تكوين نتائج تحليلات الحاوية لأن جميع التتبعات تم التقاطها بالفعل من خلال Application Insights، الذي ينشئ سجلات مكررة.

تظهر كتلة التعليمات البرمجية التالية في التنفيذ المرجعي:

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

لمزيد من المعلومات، راجع ملف التكوين الكامل.

مراقبة صحة التطبيق

يمكنك استخدام مراقبة التطبيق ومراقبته لتحديد مشكلات النظام بسرعة وإعلام النموذج الصحي بحالة التطبيق الحالية. يمكنك عرض مراقبة الصحة من خلال نقاط النهاية الصحية. تستخدم فحوصات السلامة بيانات مراقبة السلامة لتوفير المعلومات. يستخدم موازن التحميل الرئيسي هذه المعلومات لأخذ المكون غير السليم على الفور من التدوير.

تطبق هذه البنية مراقبة الصحة على المستويات التالية:

• جرابات حمل العمل التي تعمل على AKS. تحتوي هذه القرون على فحوصات الصحة والحيوية، حتى تتمكن AKS من إدارة دورة حياتها.

• Health Service، وهي مكون مخصص على نظام المجموعة. تم تكوين Azure Front Door لفحص Health Service في كل طابع وإزالة الطوابع غير السليمة من موازنة التحميل تلقائيا.

تفاصيل تنفيذ الخدمة الصحية

HealthService هو مكون حمل العمل الذي يعمل جنبا إلى جنب مع مكونات أخرى، مثل CatalogService و BackgroundProcessor، على نظام مجموعة الحوسبة. HealthService يوفر واجهة برمجة تطبيقات REST التي تستدعيها ميزة التحقق من صحة Azure Front Door لتحديد توفر طابع. على عكس تحقيقات الحياة الأساسية، تعد Health Service مكونا أكثر تعقيدا يوفر حالة التبعيات بالإضافة إلى حالتها الخاصة.

لا تستجيب Health Service إذا كانت مجموعة AKS معطلة، مما يجعل حمل العمل غير صحي. عند تشغيل الخدمة، تقوم بإجراء عمليات فحص دورية مقابل المكونات الهامة للحل. يتم إجراء جميع الفحوصات بشكل غير متزامن وبالتوازي. إذا فشل أي من عمليات التحقق، فلن يتوفر الطابع بأكمله.

تحذير

يمكن أن تفرض تحقيقات صحة Azure Front Door حملا كبيرا على Health Service لأن الطلبات تأتي من مواقع متعددة لنقطة الحضور (PoP). لمنع التحميل الزائد لمكونات انتقال البيانات من الخادم، قم بتنفيذ التخزين المؤقت الفعال.

يتم استخدام Health Service أيضا لاختبارات اتصال URL المكونة بشكل صريح مع مورد Application Insights لكل طابع.

لمزيد من المعلومات حول HealthService التنفيذ، راجع خدمة صحة التطبيق.

الخطوة التالية

الشبكات والاتصال لأحمال العمل الحرجة للمهام