معالجة الأحداث الموثوقة في وظائف Azure
معالجة الأحداث من السيناريوهات الأكثر شيوعًا المقترنة ببنية بلا خادم. توضح هذه المقالة كيفية إنشاء معالج موثوق للرسائل باستخدام وظائف Azure لتجنب فقدان الرسائل.
تحديات تدفقات الأحداث في الأنظمة الموزعة
فكّر في نظام يرسل أحداثًا بمعدل ثابت يبلغ 100 حدث في الثانية. عند هذا المعدل، يمكن لمثيلات متعددة متوازية في الوظائف أن تستهلك الأحداث المئة الواردة كل ثانية في غضون دقائق.
ومع ذلك، يُحتمل حدوث أيٍّ من الشروط التالية الأقل مثاليةً:
- ماذا لو أرسل ناشر الحدث حدثًا تالفًا؟
- ماذا لو واجه مثيل الوظائف استثناءات غير معالجة؟
- ماذا لو انقطع اتصال أحد أنظمة المراحل النهائية؟
كيف يمكنك التعامل مع هذه الحالات مع الحفاظ على معدل النقل في تطبيقك؟
في وجود قوائم الانتظار، تأتي الرسائل الموثوقة بشكل طبيعي. عند إقرانها بأحد مشغّلات الوظائف، تنشئ الوظيفة قفلًا على رسالة قائمة الانتظار. إذا فشلت المعالجة، يتم تحرير القفل للسماح لمثيل آخر بإعادة محاولة المعالجة. ثم تستمر المعالجة حتى يتم تقييم الرسالة بنجاح، أو تتم إضافتها إلى قائمة انتظار الرسائل غير القابلة للمعالجة.
حتى برغم أنه قد تظل رسالة قائمة انتظار واحدة في دورة إعادة المحاولة، تستمر عمليات التنفيذ المتوازية الأخرى بانتظام في حذف الرسائل المتبقية من قائمة الانتظار. والنتيجة هي أن معدل النقل الإجمالي يظل - إلى حد كبير - بعيدًا عن التأثر برسالة واحدة غير صالحة. لكن قوائم انتظار التخزين لا تضمن التنظيم، ولا يُستحسن استخدامها في طلبات معدلات النقل العالية التي تتطلبها مراكز الأحداث.
وعلى النقيض من ذلك، لا تتضمن مراكز الأحداث من Azure مفهوم تأمين. للسماح بميزات مثل معدل النقل العالي ومجموعات المستهلكين المتعددة والقدرة على إعادة التشغيل، تتصرف الأحداث في مراكز الأحداث بشكل أشبه بمشغل الفيديو. تتم قراءة الأحداث من نقطة واحدة في الدفق لكل قسم. من المؤشر، يمكنك قراءة ما يلي أو ما سبق أو إلى الوراء من هذا الموقع، ولكن عليك أن تختار تحريك المؤشر لكي تتوالى الأحداث.
إذا قررت إبقاء المؤشر في نفس المكان عند حدوث أخطاء في دفق، فسوف يتم حظر معالجة الحدث حتى يتقدم المؤشر. بمعنى آخر، إذا تم إيقاف المؤشر للتعامل مع مشكلات في معالجة حدث واحد، فسوف تبدأ الأحداث غير المُعالجة في التراكم.
تتجنب وظائف Azure حالات التوقف التام، عن طريق التقدم بمؤشر الدفق بغض النظر عن النجاح أو الفشل. وبينما يستمر المؤشر في التقدم، يلزم أن تتعامل الوظائف مع الفشل بشكل مناسب.
كيف تستهلك وظائف Azure أحداث مراكز الأحداث
تستهلك وظائف Azure أحداث مراكز الأحداث أثناء المرور بالخطوات التالية:
- عند إنشاء مؤشر واستمراره في مساحة تخزين Azure لكل قسم من مركز الأحداث.
- عند استلام رسائل جديدة (في دفعة بشكل افتراضي)، يحاول المضيف تشغيل الوظيفة مع دفعة الرسائل.
- إذا اكتمل تنفيذ الوظيفة (في وجود استثناءات أو بدون استثناء)، تقدم المؤشر وحُفظت نقطة اختبار إلى حساب التخزين.
- إذا كانت الشروط تمنع اكتمال تنفيذ الوظيفة، فشل المضيف في جَعل المؤشر يتقدم. إذا لم يكن المؤشر متقدمًا، فسوف ينتهي الأمر إلى معالجة عمليات الفحص الأخيرة للرسائل ذاتها.
- كرّر الخطوات من 2 حتى 4
يكشف هذا السلوك بضع نقاط مهمة:
- قد تتسبب الاستثناءات غير المُعالجة في فقدان الرسائل. تستمر الاستثناءات في تلك النتيجة في إحداث تقدم المؤشر. يؤدي تعيين نهج لإعادة المحاولة إلى تأخير تقدم المؤشر حتى يتم تقييم نهج إعادة المحاولة بالكامل.
- تضمن الوظائف تسليم كل رسالة لمرة واحدة على الأقل. قد تحتاج التعليمات البرمجية والأنظمة التابعة إلى توضيح لحقيقة أنه قد يتم استلام الرسالة نفسها مرتين.
معالجة الاستثناءات
كقاعدة عامة، يجب أن تتضمن كل وظيفة كتلة "محاولة/تحديد" على أعلى مستوى من التعليمات البرمجية. وبوجه خاص، يجب أن يكون لجميع الوظائف التي تستهلك أحداث مراكز الأحداث كتلة catch. بهذه الطريقة، تتولى كتلة التحديد معالجة الخطأ قبل تقدم المؤشر عند تقديم استثناء.
آليات ونُهج إعادة المحاولة
بعض الاستثناءات عابرة بطبيعتها، ولا تعاود الظهور عند محاولة إجراء عملية مرة أخرى بعد لحظات. لهذا السبب، دائمًا ما تكون الخطوة الأولى هي إعادة محاولة تنفيذ العملية. يمكنك الاستفادة من نُهج إعادة المحاولة في تطبيق الوظائف، أو منطق إعادة محاولة المؤلف داخل تنفيذ الوظيفة.
إدخال سلوكيات معالجة الأخطاء إلى وظائفك يتيح لك تعريف كلٍّ من نُهج إعادة المحاولة الأساسية والمتقدمة. على سبيل المثال، يمكنك تنفيذ نهج يتابع سير عمل موضح بالقواعد التالية:
- حاول إدراج رسالة ثلاث مرات (يُحتمل أن يحدث تأخير بين مرات إعادة المحاولة).
- إذا كانت النتيجة النهائية لكافة عمليات إعادة المحاولة هي الفشل، فأضف رسالة إلى قائمة انتظار حتى يمكن متابعة المعالجة على الدفق.
- ثم تتم لاحقًا معالجة الرسائل التالفة أو غير المُعالجة.
ملاحظة
Polly مثال لمكتبة للإجراءات المرنة ومعالجة الأخطاء العابرة بتطبيقات C#.
الأخطاء في حال عدم وجود استثناء
تنشأ بعض المشكلات حتى عندما لا يوجد خطأ. على سبيل المثال، فكّر في الفشل الذي يحدث في منتصف عملية تنفيذ. في هذه الحالة، لا يتقدم مؤشر الإزاحة أبدًا إذا لم يكتمل تنفيذ إحدى الوظائف. إذا لم يتقدم المؤشر، فإن أي مثيل يتم تشغيله بعد تنفيذ فاشل يستمر في قراءة الرسائل نفسها. ويوفر هذا الوضع ضمانًا للتعامل مع كل رسالة لمرة واحدة على الأقل.
يعني التأكيد على معالجة كل رسالة مرة واحدة على الأقل أنه قد تتم معالجة بعض الرسائل أكثر من مرة. يلزم أن تتضمن تطبيقات الوظائف وعيًا بهذه الاحتمالية، كما يجب بناؤها على أساس مبادئ الاستخدام لمرة واحدة.
إيقاف التنفيذ وإعادة تشغيله
برغم أن بعض الأخطاء قد تكون مقبولة، ماذا لو تعرض تطبيقك لحوادث فشل بارزة؟ قد ترغب في إيقاف تشغيل الأحداث حتى يصل النظام إلى حالة سليمة. غالبًا ما يتحقق الحصول على فرصة لإيقاف المعالجة مؤقتًا باستخدام نمط قاطع الدائرة. يسمح نمط قاطع الدائرة لتطبيقك "بكسر دورة" عملية الحدث واستئنافها في وقت لاحق.
هناك جزءان مطلوبان لتنفيذ قطع الدائرة في عملية حدث:
- الحالة المشتركة في جميع المثيلات لتتبع سلامة الدائرة ومراقبتها
- العملية الرئيسية التي يمكنها إدارة حالة الدارة (مفتوحة أو مغلقة)
قد تختلف تفاصيل التنفيذ، ولكن يلزم وجود آلية تخزين لمشاركة الحالة فيما بين المثيلات. يمكنك أن تختار تخزين الحالة في مساحة تخزين Azure أو ذاكرة التخزين المؤقت Redis أو أي حساب آخر يمكن الوصول إليه بواسطة مجموعة من الوظائف.
التطبيقات المنطقية من Azure أو الوظائف الدائمة مناسبة بطبيعتها لإدارة سير العمل وحالة الدائرة. قد تعمل منتجات أخرى أيضًا، ولكننا نستخدم التطبيقات المنطقية في هذا المثال. باستخدام التطبيقات المنطقية، يمكنك إيقاف تنفيذ إحدى الوظائف مؤقتاً وإعادة تشغيله مما يمنحك التحكم المطلوب لتنفيذ نمط قاطع الدائرة.
تعريف حد فشل عبر المثيلات
لحساب مثيلات متعددة تعالج الأحداث في وقت واحد، يلزم استمرار الحالة الخارجية المشتركة لمراقبة سلامة الدائرة.
إحدى القواعد التي يمكنك أن تختار تنفيذها قد تتطلب بالضرورة ما يلي:
- في حال وجود أكثر من 100 فشل نهائي في غضون 30 ثانية عبر جميع المثيلات، اكسر الدائرة وتوقّف عن تشغيل رسائل جديدة.
تختلف تفاصيل التنفيذ وفقاً لاحتياجاتك، ولكن بشكل عام يمكنك إنشاء نظام يتولى المهام التالية:
- يسجّل حالات الفشل في حساب تخزين (مساحة تخزين Azure أو Redis أو ما شابه)
- عند تسجيل فشل جديد، يفحص العدد المتداول لمعرفة ما إذا كان قد تم استيفاء الحد (على سبيل المثال، أكثر من 100 في آخر 30 ثانية).
- في حال استيفاء الحد، يرسل حدثًا إلى شبكة أحداث Azure يأمر النظام بكسر الدائرة.
إدارة حالة الدارة باستخدام التطبيقات المنطقية من Azure
يبرز الوصف التالي إحدى الطرق التي يمكنك من خلالها إنشاء تطبيق منطقي في Azure لإيقاف معالجة تطبيق وظائف.
تأتي التطبيقات المنطقية من Azure مزودة بموصلات مدمجة لتوفير خدمات مختلفة، وتتميز بتنسيقات ذات حالة خاصة، وتمثّل خيارًا طبيعيًّا لإدارة حالة الدائرة. بعد الكشف عن الدائرة التي يلزم كسرها، يمكنك بناء تطبيق منطقي لتنفيذ سير العمل التالي:
- تشغيل سير عمل في شبكة الأحداث وإيقاف وظيفة Azure (باستخدام موصل موارد Azure)
- إرسال رسالة إعلام إلكترونية تتضمن خيارًا لإعادة تشغيل سير العمل
يمكن لمستلم الرسالة الإلكترونية التحقق من سلامة الدائرة، كما يمكنه - عند الاقتضاء - إعادة تشغيل الدائرة عبر رابط في رسالة الإعلام الإلكترونية. بينما يُعيد سير العمل تشغيل الوظيفة، تتم معالجة الرسائل من نقطة التفتيش الأخيرة لمركز الأحداث.
باستخدام هذا الأسلوب، لا تُفقد أية رسائل، وتُعالج جميع الرسائل بالترتيب، ويمكنك قطع الدائرة متى لزم الأمر.
الموارد
الخطوات التالية
لمزيد من المعلومات، راجع الموارد التالية: