Circuit Breaker للخدمات الخارجية: كيف تمنع عطل مزود واحد من إسقاط تطبيقك؟

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

افهم الحالات الثلاث

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

افصل الفشل المتوقع عن العطل الحقيقي

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

صمم بديلًا لا يخدع المستخدم

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

امنع موجة التعافي

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

اختبر الفشل المتسلسل

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