مشاركة عبر

توصيات للشفاء الذاتي والحفاظ على الذات

  • مقالة

ينطبق على توصية قائمة التحقق من موثوقية Azure Well-Architected Framework هذه:

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

الأدلة ذات الصلة:أخطاء عابرة فيوظائف | الخلفية

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

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

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

التعريفات

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

استراتيجيات التصميم الرئيسية

إرشادات الحفاظ على الذات

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

إرشادات وأنماط تصميم البنية الأساسية

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

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

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

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

إرشادات تصميم التطبيق وأنماطه

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

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

  • نمط Request-Reply غير متزامن: فصل المعالجة الخلفية عن مضيف الواجهة الأمامية إذا كانت المعالجة الخلفية بحاجة إلى أن تكون غير متزامنة، ولكن الواجهة الأمامية تحتاج إلى استجابة واضحة.

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

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

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

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

  • تكوين مهلات الطلب: تكوين مهلات الطلب للمكالمات إلى الخدمات أو قواعد البيانات. عادة ما يتم تعيين مهلات اتصال قاعدة البيانات إلى 30 ثانية.

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

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

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

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

وظائف الخلفية

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

الأمثلة الشائعة على وظائف الخلفية هي:

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

لمزيد من المعلومات، راجع توصيات وظائف الخلفية.

إرشادات الإصلاح الذاتي

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

إرشادات تصميم البنية الأساسية

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

  • موارد الحوسبة: يمكن تكوين مجموعات مقياس الجهاز الظاهري Azure ومعظم خدمات حساب النظام الأساسي كخدمة (PaaS) لتجاوز الفشل التلقائي.

  • قواعد البيانات: يمكن تكوين قواعد البيانات الارتباطية لتجاوز الفشل التلقائي باستخدام حلول مثل مجموعات تجاوز فشل Azure SQL أو مجموعات قابلية وصول عالية التوفر AlwaysOn أو الإمكانات المضمنة مع خدمات PaaS. تحتوي قواعد بيانات NoSQL على قدرات تجميع مماثلة وقدرات مضمنة لخدمات PaaS.

  • التخزين: استخدم خيارات التخزين المكررة مع تجاوز الفشل التلقائي.

إرشادات تصميم التطبيق وأنماطه

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

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

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

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

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

  • أنماط الاختبار: قم بتضمين اختبار الأنماط التي تنفذها كجزء من إجراءات الاختبار القياسية.

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

إجراءات الإصلاح الذاتي التلقائية

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

تسهيل Azure

تتضمن معظم خدمات Azure وSDKs للعميل آلية إعادة المحاولة. ولكنها تختلف لأن كل خدمة لها خصائص ومتطلبات مختلفة، لذلك يتم ضبط كل آلية إعادة محاولة لخدمة معينة. لمزيد من المعلومات، راجع توصيات لمعالجة الأخطاء العابرة.

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

الاعتبارات

تعرف على اعتبارات كل نمط. تأكد من أن النمط مناسب لحمل العمل ومتطلبات العمل قبل التنفيذ.

مثال

على سبيل المثال، حالات استخدام بعض الأنماط، راجع نمط تطبيق الويب الموثوق به ل .NET. اتبع هذه الخطوات لتوزيع تطبيق مرجعي.

قائمة التحقق من الموثوقية

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من الموثوقية