مشاركة عبر

تصميم مرن لمراكز الأحداث و Functions

  • مقالة

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

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

فوائد البث والتحديات

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

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

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

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

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

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

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

التكرار

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

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

تكرار الأحداث

هناك العديد من السيناريوهات المختلفة التي قد تؤدي إلى تسليم أحداث مكررة إلى دالة:

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

  • الأحداث المكررة المنشورة: يمكن للعديد من التقنيات تقليل فرص نشر نفس الحدث في دفق، ولكن المستهلك لا يزال مسؤولا عن التعامل مع التكرارات بشكل متكرر.

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

تقنيات إلغاء التكرار

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

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

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

معالجة الخطأ وإعادة المحاولة

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

خطأ في معالجة الإرشاد

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

  • استخدام Application Insights: تمكين Application Insights واستخدامه لتسجيل الأخطاء ومراقبة صحة وظائفك. ضع في اعتبارك خيارات أخذ العينات القابلة للتكوين للسيناريوهات التي تعالج عدداً كبيراً من الأحداث.

  • إضافة معالجة الأخطاء المنظمة: قم بتطبيق تركيبات معالجة الأخطاء المناسبة لكل لغة برمجة لالتقاط وتسجيل واكتشاف الاستثناءات المتوقعة وغير المعالجة في التعليمات البرمجية للدالة. على سبيل المثال، استخدم كتلة try/catch في C# وJava وJavaScript واستفد من تجربة واستثناء الكتل في Python للتعامل مع الاستثناءات.

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

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

إعادة المحاولات

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

تتضمن العديد من العوامل المهمة التي يجب مراعاتها عند استخدام سياسات إعادة المحاولة مع ربط مركز الأحداث:

  • تجنب عمليات إعادة المحاولة غير المحددة: عند تعيين إعداد الحد الأقصى لعدد مرات إعادة المحاولة إلى قيمة -1، تعيد الدالة المحاولة إلى أجل غير مسمى. بشكل عام، يجب استخدام عمليات إعادة المحاولات لأجل غير مسمى بشكل مقتصد مع Functions ولا يتم استخدامها تقريباً مطلقاً مع ربط مشغل مركز الأحداث.

  • اختر استراتيجية إعادة المحاولة المناسبة: قد تكون استراتيجية التأخير الثابت هي الأمثل للسيناريوهات التي تتلقى ضغطاً عكسياً من خدمات Azure الأخرى. في هذه الحالات، يمكن أن يساعد التأخير في تجنب التقييد والقيود الأخرى التي تواجهها تلك الخدمات. توفر استراتيجية التراجع الأسي مزيداً من المرونة لفترات تأخير إعادة المحاولة وتستخدم عادة عند التكامل مع خدمات الجهات الخارجية ونقاط نهاية REST وخدمات Azure الأخرى.

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

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

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

استراتيجيات حالات الفشل والبيانات التالفة

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

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

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

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

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

  • إعادة المحاولة والحرف غير المستخدم: الجمع بين العديد من محاولات إعادة المحاولة قبل النشر في نهاية المطاف إلى دفق الرسائل المهملة بمجرد استيفاء الحد، هو أسلوب مألوف آخر.

  • استخدام سجل مخطط: يمكن استخدام سجل المخطط كأداة استباقية للمساعدة في تحسين التناسق وجودة البيانات. يمكن أن يدعم Azure Schema Registry انتقال المخططات جنباً إلى جنب مع وضعي تعيين الإصدار والتوافق المختلفين مع تطور المخططات. ويعمل المخطط في جوهره كعقد بين المنتجين والمستهلكين، مما قد يقلل من إمكانية نشر بيانات غير صالحة أو تالفة على الدفق.

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

المساهمون

تحتفظ Microsoft بهذه المقالة. وهي مكتوبة في الأصل من قبل المساهمين التاليين.

الكاتب الرئيسي:

لمشاهدة ملفات تعريف LinkedIn غير العامة، سجل الدخول إلى LinkedIn.

الخطوات التالية

قبل المتابعة، فكر في مراجعة هذه المقالات ذات الصلة:

الأمان

معالجة الأحداث بلا خادم هي بنية مرجعية توضح بالتفصيل بنية نموذجية من هذا النوع، مع نماذج من التعليمة البرمجية ومناقشة للاعتبارات المهمة.