تصميم للإصلاح الذاتي

صمم التطبيق الخاص بك بحيث يكون الشفاء الذاتي عند حدوث الفشل

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

لذلك، صمم تطبيقا يقوم بالشفاء الذاتي عند حدوث حالات الفشل. يتطلب هذا نهجًا ثلاثي الأبعاد:

• كشف الفشل.
• الاستجابة للفشل بلباقة.
• تسجيل ومراقبة حالات الفشل لإعطاء نتيجة تحليلات تشغيلية.

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

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

التوصيات

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

للحصول على نهج منظم لجعل تطبيقاتك قابلة للعلاج الذاتي، راجع تصميم تطبيقات موثوقة لـ Azure.