تحرير

مشاركة عبر

إرشادات الأداء والمقياس لمراكز الأحداث ووظائف Azure

Azure Event Hubs
Azure Functions

توفر هذه المقالة إرشادات لتحسين قابلية التوسع والأداء عند استخدام Azure Event Hubs وAzure Functions معا في تطبيقاتك.

تجميع الدالات

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

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

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

للحصول على إرشادات حول أفضل الممارسات للوظائف للت تجميع وجوانب أخرى، راجع أفضل الممارسات لوظائف Azure الموثوقة وتحسين أداء وموثوقية Azure Functions.

القائمة التالية هي إرشادات لدالات التجميع. تنظر الإرشادات في جوانب التخزين ومجموعة المستهلكين:

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

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

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

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

    مجموعات المستهلكين المخصصة لكل تطبيق وظائف

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

خطط استضافة الوظائف

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

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

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

توفر Azure Container Apps دعما متكاملا لتطوير تطبيقات الوظائف المعبأة في حاويات ونشرها وإدارتها على Azure Functions. يسمح لك هذا بتشغيل الوظائف المستندة إلى الحدث في بيئة مدارة بالكامل وقائمة على Kubernetes مع دعم مضمن للمراقبة مفتوحة المصدر وmTLS وDpr و KEDA.

تحجيم مراكز الأحداث

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

تتوافق مساحة اسم مراكز الأحداث مع نظام مجموعة Kafka. للحصول على معلومات حول كيفية ارتباط مراكز الأحداث وKafka ببعضها البعض، راجع ما هي مراكز أحداث Azure ل Apache Kafka.

فهم وحدات معدل النقل (TUs)

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

تتم فوترة وحدات TUs على أساس كل ساعة.

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

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

لمزيد من المعلومات، راجع وحدات معدل النقل لمراكز الأحداث.

توسيع النطاق باستخدام التضخيم التلقائي

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

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

إذا كان التطبيق يحتاج إلى سعة تتجاوز الحد الأقصى المسموح به لعدد وحدات TUs، ففكر في استخدام طبقة Event Hubs Premium أو المستوى المخصص.

الأقسام والوظائف المتزامنة

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

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

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

الحد الأقصى لدرجة التوازي

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

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

التوفر والاتساق

عندما لا يتم تحديد مفتاح قسم أو معرف، توجه مراكز الأحداث حدثا واردا إلى القسم المتوفر التالي. توفر هذه الممارسة توفرا عاليا وتساعد على زيادة معدل النقل للمستهلكين.

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

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

لمزيد من المعلومات حول كيفية دعم مراكز الأحداث للتوفر والاتساق، راجع التوفر والاتساق في مراكز الأحداث.

مشغل مراكز الأحداث

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

إرسال دفعات للوظائف التي تم تشغيلها

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

يختلف تمكين الإرسال في دفعات لربط مشغل مراكز الأحداث بين اللغات:

  • تمكن JavaScript وPython واللغات الأخرى الإرسال في دفعات عند تعيين خاصية العلاقة الأساسية إلى العديد في ملف function.json للدالة.
  • في C#، يتم تكوين العلاقة الأساسية تلقائيا عند تعيين صفيف للنوع في السمة EventHubTrigger .

لمزيد من المعلومات حول كيفية تمكين الإرسال في دفعات، راجع مشغل مراكز الأحداث ل Azure Functions.

إعدادات المشغل

تلعب العديد من إعدادات التكوين في ملف host.json دورا رئيسيا في خصائص الأداء لربط مشغل مراكز الأحداث للوظائف:

  • maxEventBatchSize: يمثل هذا الإعداد الحد الأقصى لعدد الأحداث التي يمكن أن تتلقاها الدالة عند استدعاؤها. إذا كان عدد الأحداث المستلمة أقل من هذا المقدار، فلا يزال يتم استدعاء الدالة مع العديد من الأحداث المتوفرة. لا يمكنك تعيين الحد الأدنى لحجم الدفعة.
  • prefetchCount: يعد عدد الإحضار المسبق أحد أهم الإعدادات عند تحسين الأداء. تشير قناة AMQP الأساسية إلى هذه القيمة لتحديد عدد الرسائل التي يجب إحضارها وتخزينها مؤقتا للعميل. يجب أن يكون عدد الجلب المسبق أكبر من أو يساوي قيمة maxEventBatchSize ويتم تعيينه عادة إلى مضاعف من هذا المبلغ. يمكن أن يؤدي تعيين هذه القيمة إلى رقم أقل من إعداد maxEventBatchSize إلى الإضرار بالأداء.
  • batchCheckpointFrequency: بينما تعالج وظيفتك الدفعات، تحدد هذه القيمة معدل إنشاء نقاط التحقق. القيمة الافتراضية هي 1، ما يعني أن هناك نقطة تحقق كلما نجحت دالة في معالجة دفعة واحدة. يتم إنشاء نقطة تحقق على مستوى القسم لكل قارئ في مجموعة المستهلكين. للحصول على معلومات حول كيفية تأثير هذا الإعداد على عمليات إعادة التشغيل وإعادة محاولة الأحداث، راجع دالة Azure التي تم تشغيلها في مركز الأحداث: عمليات إعادة التشغيل وإعادة المحاولة (منشور المدونة).

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

التحقق

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

يمكن أن تساعدك المفاهيم التالية على فهم العلاقة بين نقاط التحقق والطريقة التي تعالج بها وظيفتك الأحداث:

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

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

أخذ عينات بيانات تتبع الاستخدام

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

توفر هذه الإمكانية القوية بعض خيارات التكوين الرئيسية التي تؤثر على الأداء. بعض الإعدادات والاعتبارات البارزة للمراقبة والأداء هي:

  • تمكين أخذ عينات بيانات تتبع الاستخدام: بالنسبة لسيناريوهات معدل النقل العالي، يجب تقييم كمية بيانات تتبع الاستخدام والمعلومات التي تحتاجها. ضع في اعتبارك استخدام ميزة أخذ عينات بيانات تتبع الاستخدام في Application Insights لتجنب تدهور أداء وظيفتك باستخدام القياس عن بعد والمقاييس غير الضرورية.
  • تكوين إعدادات التجميع: فحص وتكوين تكرار تجميع البيانات وإرسالها إلى Application Insights. يوجد إعداد التكوين هذا في ملف host.json مع العديد من الخيارات الأخرى المتعلقة بأخذ العينات والتسجيل. لمزيد من المعلومات، راجع تكوين المجمع.
  • تعطيل AzureWebJobDashboard: بالنسبة للتطبيقات التي تستهدف الإصدار 1.x من وقت تشغيل الوظائف، يخزن هذا الإعداد سلسلة الاتصال إلى حساب تخزين يستخدمه Azure SDK للاحتفاظ بالسجلات للوحة معلومات WebJobs. إذا تم استخدام Application Insights بدلا من لوحة معلومات WebJobs، فيجب إزالة هذا الإعداد. لمزيد من المعلومات، راجع AzureWebJobsDashboard.

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

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

ربط بيانات الإخراج

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

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

نوصي بشدة بمراجعة قائمة اللغات التي تدعمها Functions وإرشادات المطور لتلك اللغات. يوفر قسم الروابط لكل لغة أمثلة مفصلة ووثائق.

الإرسال في دفعات عند نشر الأحداث

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

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

يتوفر دعم استخدام ربط الإخراج لإرسال أحداث متعددة إلى مراكز الأحداث في C# وJava وPython وJavaScript.

إخراج أحداث متعددة باستخدام نموذج قيد المعالجة (C#)

استخدم نوعي ICollector وIAsyncCollector عند إرسال أحداث متعددة من دالة في C#‎.

  • ICollector <T>. يمكن استخدام أسلوب Add() في كل من الدالات المتزامنة وغير المتزامنة. ينفذ عملية الإضافة بمجرد استدعائه.
  • IAsyncCollector<T>. يقوم أسلوب AddAsync() بإعداد الأحداث ليتم نشرها إلى دفق الحدث. إذا كتبت دالة غير متزامنة، يجب استخدام IAsyncCollector لإدارة الأحداث المنشورة بشكل أفضل.

للحصول على أمثلة لاستخدام C# لنشر أحداث فردية ومتعددة، راجع ربط إخراج مراكز الأحداث ل Azure Functions.

إخراج أحداث متعددة باستخدام نموذج العامل المعزول (C#)

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

التقييد والضغط المعاكس

تنطبق اعتبارات التقييد على روابط الإخراج، ليس فقط لمراكز الأحداث ولكن أيضا لخدمات Azure مثل Azure Cosmos DB. من المهم أن تكون على دراية بالحدود والحصص النسبية التي تنطبق على هذه الخدمات والتخطيط وفقا لذلك.

لمعالجة أخطاء انتقال البيانات من الخادم باستخدام نموذج قيد المعالجة، يمكنك تضمين AddAsync و FlushAsync في معالج استثناء لوظائف .NET من أجل التقاط الاستثناءات من IAsyncCollector. خيار آخر هو استخدام Event Hubs SDKs مباشرة بدلا من استخدام روابط الإخراج.

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

التعليمة البرمجية للوظائف

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

برمجة غير متزامنة

نوصي بكتابة وظيفتك لاستخدام التعليمات البرمجية غير المتزامنة وتجنب حظر المكالمات، خاصة عند تضمين مكالمات الإدخال/الإخراج.

فيما يلي الإرشادات التي يجب اتباعها عند كتابة دالة لمعالجتها بشكل غير متزامن:

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

المزيد حول حظر المكالمات

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

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

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

المساهمون

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

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

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

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

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

تصميم مراكز الأحداث والوظائف المرنة