اعتبارات النظام الأساسي للتطبيق لأحمال العمل الحرجة للمهام

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

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

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

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

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

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

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

الموارد العمومية

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

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

في هذه البنية، تكون موارد الطبقة العمومية هي Azure Front Door وAzure Cosmos DB وAzure Container Registry وAzure Log Analytics لتخزين السجلات والمقاييس من موارد الطبقة العمومية الأخرى.

هناك موارد أساسية أخرى في هذا التصميم، مثل معرف Microsoft Entra وAzure DNS. تم حذفها في هذه الصورة للإيجاز.

موازن التحميل العمومي

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

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

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

يوفر Front Door العديد من القدرات الإضافية إلى جانب توجيه نسبة استخدام الشبكة العالمية. من الإمكانات المهمة جدار حماية تطبيق الويب (WAF)، لأن Front Door قادر على فحص نسبة استخدام الشبكة التي تمر عبرها. عند تكوينه في وضع الوقاية، فإنه سيمنع نسبة استخدام الشبكة المشبوهة قبل الوصول إلى أي من الخلفيات.

للحصول على معلومات حول قدرات Front Door، راجع الأسئلة المتداولة ل Azure Front Door.

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

Container Registry

يستخدم Azure Container Registry لتخزين البيانات الاصطناعية لمبادرة الحاوية المفتوحة (OCI)، وتحديدا مخططات helm وصور الحاوية. لا يشارك في تدفق الطلب ولا يتم الوصول إليه إلا بشكل دوري. يجب أن يكون سجل الحاوية موجودا قبل نشر موارد الطابع ولا يجب أن يكون له تبعية على موارد الطبقة الإقليمية.

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

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

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

لمزيد من التفاصيل، راجع أفضل الممارسات ل Azure Container Registry.

قاعدة بيانات

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

يوصى بشدة بالنسخ المتماثل للبيانات في تكوين نشط-نشط. يجب أن يكون التطبيق قادرا على الاتصال على الفور بمنطقة أخرى. يجب أن تكون جميع المثيلات قادرة على معالجة طلبات القراءة والكتابة .

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

المراقبة العالمية

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

اعتبارات الخدمات الأساسية

من المحتمل أن يستخدم النظام خدمات النظام الأساسي الهامة الأخرى التي يمكن أن تتسبب في تعرض النظام بأكمله للخطر، مثل Azure DNS ومعرف Microsoft Entra. يضمن Azure DNS توفر اتفاقية مستوى الخدمة بنسبة 100٪ لطلبات DNS الصالحة. يضمن Microsoft Entra ما لا يقل عن 99.99٪ من وقت التشغيل. ومع ذلك، يجب أن تكون على دراية بتأثير في حالة الفشل.

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

• يستخدم Azure Front Door Azure DNS للوصول إلى الواجهة الخلفية والخدمات العمومية الأخرى.
• يستخدم Azure Container Registry Azure DNS لتجاوز فشل الطلبات إلى منطقة أخرى.

في كلتا الحالتين، ستتأثر كلتا خدمات Azure إذا لم يكن Azure DNS متوفرا. سيفشل تحليل الاسم لطلبات المستخدم من Front Door؛ لن يتم سحب صور Docker من السجل. لن يؤدي استخدام خدمة DNS خارجية كنسخة احتياطية إلى التخفيف من المخاطر لأن العديد من خدمات Azure لا تسمح بمثل هذا التكوين وتعتمد على DNS الداخلي. توقع الانقطاع الكامل.

وبالمثل، يتم استخدام معرف Microsoft Entra لعمليات وحدة التحكم مثل إنشاء عقد AKS جديدة أو سحب الصور من Container Registry أو الوصول إلى Key Vault عند بدء تشغيل pod. إذا لم يكن معرف Microsoft Entra متوفرا، فلا يجب أن تتأثر المكونات الموجودة، ولكن قد ينخفض الأداء الكلي. لن تعمل وحدات الجراب الجديدة أو عقد AKS. لذلك، في حالة الحاجة إلى عمليات توسيع النطاق خلال هذا الوقت، توقع انخفاض تجربة المستخدم.

موارد طابع التوزيع الإقليمي

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

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

في هذه البنية، تكون موارد الطابع هي Azure Kubernetes Service وAzure Event Hubs وAzure Key Vault وAzure Blob Storage.

وحدة القياس

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

يتم نشر كل وحدة مقياس في منطقة Azure وبالتالي فهي تتعامل بشكل أساسي مع نسبة استخدام الشبكة من تلك المنطقة المحددة (على الرغم من أنها يمكن أن تأخذ نسبة استخدام الشبكة من مناطق أخرى عند الحاجة). من المحتمل أن يؤدي هذا الانتشار الجغرافي إلى أنماط تحميل وساعات عمل قد تختلف من منطقة إلى أخرى، وعلى هذا النحو، تم تصميم كل وحدة SU لتوسيع نطاقها/تقليصها عند الخمول.

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

فيما يلي بعض اعتبارات التحجيم والتوافر عند اختيار خدمات Azure في وحدة:

• تقييم علاقات السعة بين جميع الموارد في وحدة المقياس. على سبيل المثال، للتعامل مع 100 طلب وارد، ستكون هناك حاجة إلى 5 وحدات تحكم دخول و3 جراب خدمة كتالوج و1000 وحدة طلب في Azure Cosmos DB. لذلك، عند التحجيم التلقائي لقرون الدخول، توقع تحجيم خدمة الكتالوج ووحدات RUs Azure Cosmos DB نظرا لتلك النطاقات.

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

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

• اختر الخدمات التي تدعم مناطق التوفر لإنشاء التكرار. قد يحد هذا من اختياراتك التكنولوجية. راجع مناطق التوفر للحصول على التفاصيل.

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

نظام مجموعة الحساب

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

ترتبط مدة بقاء نظام مجموعة AKS بالطبيعة المؤقتة للطابع. نظام المجموعة عديم الحالة ولا يحتوي على وحدات تخزين ثابتة. ويستخدم أقراص نظام التشغيل المؤقتة بدلا من الأقراص المدارة لأنه لا يتوقع أن تتلقى صيانة على مستوى التطبيق أو النظام.

لزيادة الموثوقية، يتم تكوين نظام المجموعة لاستخدام جميع مناطق التوفر الثلاث في منطقة معينة. وهذا يجعل من الممكن لنظام المجموعة استخدام AKS Uptime SLA الذي يضمن توفر 99.95٪ من اتفاقية مستوى الخدمة لمستوى التحكم AKS.

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

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

على مستوى الجراب، يقوم التحجيم التلقائي للجراب الأفقي (HPA) بتحجيم الجرابات استنادا إلى وحدة المعالجة المركزية أو الذاكرة أو المقاييس المخصصة المكونة. اختبار التحميل لمكونات حمل العمل لإنشاء أساس لقيم التحجيم التلقائي وHPA.

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

تتطلب بعض المكونات مثل cert-manager وingress-nginx صور حاوية من سجلات الحاويات الخارجية. إذا كانت هذه المستودعات أو الصور غير متوفرة، فقد لا تتمكن المثيلات الجديدة على العقد الجديدة (حيث لا يتم تخزين الصورة مؤقتا) من البدء. يمكن تخفيف هذا الخطر عن طريق استيراد هذه الصور إلى Azure Container Registry الخاص بالبيئة.

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

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

المخزن الرئيسي

يتم استخدام Azure Key Vault لتخزين الأسرار العمومية مثل سلسلة الاتصال إلى قاعدة البيانات وأسرار الطابع مثل مراكز الأحداث سلسلة الاتصال.

تستخدم هذه البنية برنامج تشغيل Secrets Store CSI في مجموعة الحوسبة للحصول على أسرار من Key Vault. البيانات السرية مطلوبة عند إنتاج pods جديدة. إذا لم يكن Key Vault متوفرا، فقد لا تبدأ وحدات الجراب الجديدة. ونتيجة لذلك، قد يكون هناك تعطيل؛ يمكن أن تتأثر عمليات توسيع النطاق، ويمكن أن تفشل التحديثات، ولا يمكن تنفيذ عمليات نشر جديدة.

يحتوي Key Vault على حد لعدد العمليات. نظرا للتحديث التلقائي للبيانات السرية، يمكن الوصول إلى الحد إذا كان هناك العديد من pods. يمكنك اختيار تقليل تكرار التحديثات لتجنب هذا الموقف.

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

مراكز الأحداث

الخدمة الوحيدة ذات الحالة في الطابع هي وسيط الرسائل، Azure Event Hubs، الذي يخزن الطلبات لفترة قصيرة. الوسيط يخدم الحاجة إلى التخزين المؤقت والمراسلة الموثوق بها. تستمر الطلبات المعالجة في قاعدة البيانات العمومية.

في هذه البنية، يتم استخدام SKU القياسي ويتم تمكين تكرار المنطقة لقابلية الوصول العالية.

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

لقابلية التوسع، يوصى بتمكين التضخيم التلقائي.

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

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

حسابات التخزين⁧

في هذه البنية يتم توفير حسابي تخزين. يتم نشر كلا الحسابين في وضع المنطقة المكررة (ZRS).

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

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

لمزيد من المعلومات حول الاسترداد، راجع التعافي من الكوارث وتجاوز فشل حساب التخزين.

الموارد الإقليمية

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

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

مراقبة البيانات لموارد الطوابع

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

يتم استخدام Azure Log Analytics وAzure Application Insights لتخزين السجلات والمقاييس من النظام الأساسي. يوصى بتقييد الحصة النسبية اليومية على التخزين خاصة في البيئات المستخدمة لاختبار التحميل. أيضا، قم بتعيين نهج الاستبقاء لتخزين جميع البيانات. ستمنع هذه القيود أي نفقات زائدة يتم تكبدها عن طريق تخزين البيانات غير الضرورية بما يتجاوز الحد.

وبالمثل، يتم نشر Application Insights أيضا كمورد إقليمي لجمع جميع بيانات مراقبة التطبيق.

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

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

انشر التنفيذ المرجعي للحصول على فهم كامل للموارد وتكوينها المستخدم في هذه البنية.

التنفيذ: مهمة حرجة على الإنترنت