· · 2 دقائق قراءة

توقف عن قصف تبعية تعاني: أنماط إعادة المحاولة لـ Azure Functions + Service Bus

أنماط الانسحاب الأسي وقاطع الدائرة مدعومان الآن بشكل أصلي لـ Azure Functions المشغَّلة بـ Service Bus — إليك كيفية عملها ولماذا تحتاج كليهما.

Azure Functions Service Bus Resilience .NET Azure SDK Serverless
هذا المقال متاح أيضاً بـ:English, Català, Español, Deutsch, Français, Português, Italiano, 日本語, 中文, 한국어, Русский, हिन्दी, Polski, Türkçe, Bahasa Indonesia, Nederlands

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

ربما تعرف هذه القصة. يتوسع Azure Functions بسرعة — هذا هو كل الهدف. لكن “التوسع السريع” و"إعادة المحاولة الفورية" معاً يمكن أن يجعلا الإخفاقات أسوأ بشكل درامي.

نمطان يساعدان. الانسحاب الأسي وقاطع الدائرة. كلاهما مدعومان الآن بشكل أصلي لـ Azure Functions المشغَّلة بـ Service Bus.

نمطان، أدوار مختلفة

هذان النمطان متكاملان، وليسا بديلين:

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

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

تحتاج كليهما. يتعامل الانسحاب مع توقيت إعادة المحاولة لكل رسالة. يتعامل قاطع الدائرة مع قرارات الصحة المجمّعة.

لماذا هذا مهم بشكل خاص لـ Service Bus

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

التصميم الأكثر أماناً:

  1. اكتشاف الفشل المؤقت
  2. تأخير المحاولة التالية بالانسحاب الأسي
  3. إيقاف الاستدعاءات إلى التبعية عند الوصول إلى حد الفشل (الدائرة مفتوحة)
  4. الاستئناف بحذر بعد فترة تهدئة (استكشاف الدائرة)
  5. نقل العمل غير القابل للاسترداد إلى dead-letter أو مسار عزل

كيف يبدو الدعم الأصلي

يتكامل الدعم الجديد مع نموذج المضيف الحالي لـ Azure Functions — لا مكتبات إضافية، لا تطبيقات مخصصة. التكوين يذهب في ملف host.json الخاص بك:

{
  "extensions": {
    "serviceBus": {
      "messageHandlerOptions": {
        "maxRetryCount": 5,
        "retryPolicy": {
          "mode": "exponentialBackoff",
          "minBackoff": "00:00:02",
          "maxBackoff": "00:05:00",
          "maxRetryCount": 5
        }
      }
    }
  }
}

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

اللغات المشمولة

هذا ليس لـ .NET فقط. تشمل الميزة dotnet وJavaScript وTypeScript وPython — المجموعة الكاملة من اللغات المدعومة بمشغّل Service Bus في Azure Functions.

الخلاصة

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

المنشور الأصلي: Exponential backoff and circuit breaker for Service Bus-triggered Azure Functions

شارك:
عرض الكود المصدري لهذا المقال على GitHub ↗
← وكيل الذكاء الاصطناعي لديك مشكلة في الهوية (وهذا هو القالب الذي يحلها)
يمكن لـ Azure SQL الآن توليد التضمينات — في T-SQL النقي، دون حاجة لطبقة التطبيق →