خطأ واحد أسقط النظام: كيف أنقذني نمط ‘قاطع الدائرة’ من كابوس الأعطال المتتالية؟

ليلة إطلاق المنتج الجديد… أو كابوس هدّ الحيل

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

في الدقائق الأولى، كانت الأمور تبدو وردية. لكن فجأة، بدأت التنبيهات تنهال علينا كالمطر. “النظام لا يستجيب!”، “استخدام المعالج 100%!”، “قاعدة البيانات عليها ضغط هائل!”. يا ساتر! شو القصة؟

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

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

في تلك الليلة، تعلمت درسًا قاسيًا: نظامك قوي بقدر أضعف حلقة فيه. لم يكن خطأنا في الكود الذي كتبناه، بل في الكود الذي لم نكتبه؛ الكود الذي يحمي نظامنا من أخطاء الآخرين. هنا، يا جماعة الخير، يأتي دور البطل الصامت: نمط قاطع الدائرة (Circuit Breaker).

ما هو نمط قاطع الدائرة (Circuit Breaker)؟

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

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

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

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

كيف يعمل قاطع الدائرة؟ الحالات الثلاث

يعمل قاطع الدائرة من خلال المرور بثلاث حالات رئيسية، تمامًا مثل القاطع الكهربائي الحقيقي:

1. الحالة المغلقة (Closed State) 🟢

هذه هي الحالة الطبيعية والافتراضية. يكون القاطع “مغلقًا”، مما يعني أن الدائرة متصلة، والطلبات من تطبيقك تمر بشكل طبيعي إلى الخدمة الخارجية. أثناء هذه الحالة، يقوم قاطع الدائرة بمراقبة عدد مرات فشل هذه الطلبات في الخفاء (مثل أخطاء Timeout، أو أخطاء HTTP 5xx). إذا تجاوز عدد مرات الفشل حدًا معينًا (مثلاً، 5 أخطاء متتالية، أو 50% من الطلبات في آخر دقيقة)، “يفصل” القاطع وينتقل إلى الحالة المفتوحة.

2. الحالة المفتوحة (Open State) 🔴

عندما “يفصل” القاطع، يدخل في الحالة المفتوحة. في هذه الحالة، يتم رفض أي طلب جديد لاستدعاء الخدمة الخارجية فورًا ودون محاولة إرساله. هذا هو جوهر الحماية! بدلاً من انتظار 30 ثانية للحصول على Timeout، يحصل تطبيقك على خطأ فوري. هذا يحرر موارد نظامك بسرعة ويمنعه من الانهيار.

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

3. الحالة نصف المفتوحة (Half-Open State) 🟡

بعد انتهاء فترة “الاستراحة” في الحالة المفتوحة، ينتقل القاطع إلى حالة “جس النبض” هذه. يسمح القاطع بمرور طلب واحد فقط (أو عدد قليل جدًا من الطلبات) إلى الخدمة الخارجية. هذا الطلب هو بمثابة “مسبار” أو “طُعم”.

• إذا نجح هذا الطلب: يعتبر قاطع الدائرة أن الخدمة قد تعافت. يعود فورًا إلى الحالة المغلقة (Closed)، وتعود الأمور إلى طبيعتها.
• إذا فشل هذا الطلب: فهذا يعني أن الخدمة لا تزال تعاني من مشاكل. يعود القاطع فورًا إلى الحالة المفتوحة (Open) ويبدأ فترة انتظار جديدة، مانعًا أي طلبات أخرى من المرور.

هذه الدورة (مغلق -> مفتوح -> نصف مفتوح -> مغلق) تحدث تلقائيًا وتحمي نظامك بشكل ديناميكي دون أي تدخل يدوي.

مثال عملي: لنطبق النمط بالكود (C# مع Polly)

الكلام النظري جميل، لكن “ورجيني الكود يا أبو عمر!”. لنرَ كيف يمكن تطبيق هذا النمط بسهولة باستخدام لغة C# ومكتبة رائعة اسمها Polly، وهي مكتبة متخصصة في سياسات الصمود (Resilience Policies).

تخيل أن لدينا الكود التالي الذي يستدعي خدمة خارجية للحصول على بيانات الطقس. هذا هو الكود “الساذج” الذي كان سيسبب لنا الكارثة:

// الكود قبل استخدام قاطع الدائرة - خطر!
public async Task<string> GetWeatherUnsafeAsync()
{
    var httpClient = new HttpClient();
    // هذا الاستدعاء قد يستغرق وقتًا طويلاً أو يفشل، مما يعلق الخيط
    var response = await httpClient.GetStringAsync("https://api.weather-service.com/data");
    return response;
}

الآن، لنقم بإعادة كتابته باستخدام سياسة قاطع الدائرة من مكتبة Polly:

using Polly;
using Polly.CircuitBreaker;

// ...

// تعريف سياسة قاطع الدائرة - عادةً ما يتم تعريفها مرة واحدة وإعادة استخدامها
private static readonly AsyncCircuitBreakerPolicy _circuitBreakerPolicy = Policy
    .Handle<Exception>() // حدد أنواع الأخطاء التي يجب أن تؤثر على القاطع
    .CircuitBreakerAsync(
        exceptionsAllowedBeforeBreaking: 3, // عدد الاستثناءات المسموح بها قبل فتح الدائرة
        durationOfBreak: TimeSpan.FromSeconds(30) // مدة بقاء الدائرة مفتوحة
    );

public async Task<string> GetWeatherSafeAsync()
{
    var httpClient = new HttpClient();
    
    try
    {
        // تنفيذ الاستدعاء من خلال سياسة قاطع الدائرة
        var response = await _circuitBreakerPolicy.ExecuteAsync(async () => 
        {
            Console.WriteLine("--> محاولة استدعاء الخدمة (الدائرة مغلقة أو نصف مفتوحة)...");
            return await httpClient.GetStringAsync("https://api.weather-service.com/data");
        });
        return response;
    }
    catch (BrokenCircuitException) // هذا الخطأ يُرمى عندما تكون الدائرة مفتوحة
    {
        // فشل سريع! الدائرة مفتوحة.
        Console.WriteLine("--> الدائرة مفتوحة! لن نحاول استدعاء الخدمة.");
        // هنا يمكننا تطبيق منطق بديل (Fallback)
        return "الطقس غير متاح حاليًا. حاول لاحقًا.";
    }
    catch (Exception ex)
    {
        // أي خطأ آخر يحدث أثناء محاولة الاستدعاء
        Console.WriteLine($"--> حدث خطأ آخر: {ex.Message}");
        throw;
    }
}

لاحظ الفرق! الآن، قمنا بلف الكود الخطير داخل _circuitBreakerPolicy.ExecuteAsync. إذا فشلت خدمة الطقس 3 مرات متتالية، ستفتح الدائرة. في المرة الرابعة، بدلاً من محاولة الاتصال بالخدمة، سترمي المكتبة استثناء BrokenCircuitException فورًا، والذي نلتقطه ونقدم من خلاله رسالة بديلة. بعد 30 ثانية، ستنتقل الدائرة للحالة نصف المفتوحة وتسمح بمحاولة واحدة جديدة. الأمر بهذه البساطة والقوة.

نصائح أبو عمر الذهبية لتطبيق النمط

بعد سنوات من العمل مع الأنظمة الموزعة، تعلمت بعض الدروس التي أود مشاركتها معكم يا جماعة الخير:

1. لا تطبق النمط على كل شيء: ليس كل استدعاء خدمة يحتاج لقاطع دائرة. استخدمه بحكمة مع الخدمات التي: (أ) ليست حيوية 100% لعملية معينة (مثل خدمة إرسال إيميل ترحيبي)، أو (ب) معروفة بأنها غير مستقرة، أو (ج) خدمات طرف ثالث لا تملك السيطرة عليها.
2. جهّز خطة بديلة (Fallback): السؤال الأهم ليس “ماذا لو فشلت الخدمة؟” بل “ماذا سنفعل عندما تفشل الخدمة؟”. عندما تكون الدائرة مفتوحة، لا تكتفِ بإرجاع خطأ. هل يمكنك إرجاع بيانات من الكاش؟ هل يمكنك إرجاع قيمة افتراضية؟ هل يمكنك تأجيل العملية لتنفيذها لاحقًا؟ تجربة المستخدم تعتمد على جودة خطتك البديلة.
3. المراقبة والتنبيهات أهم من الكود نفسه: يجب أن تعرف متى تُفتح قواطع الدائرة في نظامك. قم بتسجيل (Log) أحداث تغيير حالة القاطع (فتح، إغلاق، نصف فتح). الأهم من ذلك، قم بإعداد تنبيهات (Alerts) لفريق العمل عند فتح قاطع دائرة لخدمة حيوية. هذا يمنحك رؤية فورية لمشاكل النظام دون الحاجة للغوص في ملايين الأسطر من السجلات.
4. اضبط الإعدادات بحكمة (بدك تكون حكيم يا خال): الأرقام التي تختارها (عدد الأخطاء المسموح بها، مدة فتح الدائرة) مهمة جدًا. خدمة دفع إلكتروني قد تحتاج لقاطع حساس جدًا (يفصل بعد خطأين ويبقى مفتوحًا لدقائق). بينما خدمة تحليل بيانات غير حرجة قد تتحمل 10 أخطاء وتبقى مفتوحة لـ 30 ثانية فقط. ابدأ بقيم منطقية، وراقب أداء النظام، ثم عدّلها بناءً على البيانات الحقيقية.
5. قاطع الدائرة ليس الحل السحري الوحيد: الصمود (Resilience) هو منظومة متكاملة. قاطع الدائرة يعمل بشكل أفضل عند دمجه مع أنماط أخرى مثل:
   • إعادة المحاولة (Retry): لإعادة محاولة الطلبات التي تفشل بشكل عابر (مع استخدام تباعد زمني متزايد – Exponential Backoff).
   • المهلة الزمنية (Timeout): لضمان عدم بقاء طلب معلقًا إلى الأبد.
   • نمط العزل (Bulkhead): لعزل الموارد المستخدمة لكل خدمة، بحيث لا يؤدي فشل خدمة واحدة إلى استهلاك كل موارد النظام.

الخلاصة 💡

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

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

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