مشاركة عبر

المقياس القائم على الأحداث في Azure Functions

  • مقالة

في خطط Consumption و Flex Consumption و Premium، تقوم Azure Functions بتحجيم الموارد عن طريق إضافة المزيد من المثيلات استنادا إلى عدد الأحداث التي تشغل وظيفة.

هام

خطة Flex Consumption قيد المعاينة حاليا.

تعتمد الطريقة التي يتدرج بها تطبيق الوظائف على خطة الاستضافة:

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

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

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

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

قياس وقت التشغيل

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

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

أحداث مراقبة وحدة تحكم المقياس وإنشاء مثيلات

تشغيل بارد

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

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

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

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

فهم سلوكيات المقياس

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

  • الحد الأقصى للمثيلات: يتم توسيع نطاق تطبيق دالة واحدة فقط إلى الحد الأقصى المسموح به من قبل الخطة. ومع ذلك، يمكن لمثيل واحد معالجة أكثر من رسالة أو طلب واحد في كل مرة. يمكنك تحديد الحد الأقصى الأدنى لخنق المقياس كما هو مطلوب.
  • معدل المثيل الجديد: بالنسبة إلى مشغلات HTTP، يتم تخصيص مثيلات جديدة، على الأكثر، مرة واحدة في الثانية. بالنسبة للمشغلات غير HTTP، يتم تخصيص مثيلات جديدة، على الأكثر، مرة واحدة كل 30 ثانية. المقياس أسرع عند تشغيل في خطة Premium.
  • التحجيم المستند إلى الهدف: يوفر التحجيم المستند إلى الهدف نموذج تحجيم سريع وبديهي للعملاء وهو مدعوم حاليا لقوائم انتظار وموضوعات ناقل الخدمة وقوائم انتظار التخزين ومراكز الأحداث وملحقات Apache Kafka وAzure Cosmos DB. تأكد من مراجعة التحجيم المستند إلى الهدف لفهم سلوك التحجيم.
  • التحجيم لكل وظيفة: مع بعض الاستثناءات الملحوظة، تعمل الوظائف في مقياس خطة استهلاك Flex على مثيلات مستقلة. تتضمن الاستثناءات مشغلات HTTP ومشغلات تخزين Blob (شبكة الأحداث). يتدرج كل نوع من أنواع المشغلات هذه معا كمجموعة على نفس المثيلات. وبالمثل، تشترك جميع مشغلات Durable Functions أيضا في المثيلات وتتوسع معا. لمزيد من المعلومات، راجع التحجيم لكل وظيفة.
  • الحد الأقصى للمشغلات المراقبة: حاليا، يمكن لوحدة التحكم في المقياس مراقبة ما يصل إلى 100 مشغل فقط لاتخاذ قرارات التحجيم. عندما يحتوي تطبيقك على أكثر من 100 مشغل مستند إلى الحدث، يتم اتخاذ قرارات تغيير الحجم استنادا إلى أول 100 مشغل يتم تنفيذها فقط. لمزيد من المعلومات، راجع أفضل الممارسات والأنماط للتطبيقات القابلة للتطوير.

الحد من التوسيع

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

خطة استهلاك Flex

بشكل افتراضي، التطبيقات التي تعمل في خطة استهلاك Flex لها حد من 100 المثيلات الإجمالية. حاليا الحد الأقصى لقيمة عدد المثيلات هو 40، وأعلى قيمة لعدد المثيلات المدعومة هي 1000. عند استخدام az functionapp create الأمر لإنشاء تطبيق دالة في خطة Flex Consumption، استخدم المعلمة --maximum-instance-count لتعيين الحد الأقصى لعدد المثيلات لتطبيقك.

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

ينشئ هذا المثال تطبيقا بحد أقصى لعدد المثيلات :200

az functionapp create --resource-group <RESOURCE_GROUP> --name <APP_NAME> --storage <STORAGE_ACCOUNT_NAME> --runtime <LANGUAGE_RUNTIME> --runtime-version <RUNTIME_VERSION> --flexconsumption-location <REGION> --maximum-instance-count 200

يستخدم az functionapp scale config set هذا المثال الأمر لتغيير الحد الأقصى لعدد المثيلات لتطبيق موجود إلى 150:

az functionapp scale config set --resource-group <RESOURCE_GROUP> --name <APP_NAME> --maximum-instance-count 150

خطط الاستهلاك/Premium

في خطة Consumption أو Elastic Premium، يمكنك تحديد حد أقصى أقل لتطبيقك عن طريق تعديل قيمة functionAppScaleLimit إعداد تكوين الموقع. يمكن تعيين functionAppScaleLimit إلى 0 أوnull لقيمة غير مقيدة وصالحة بين 1 والحد الأقصى للتطبيق.

az resource update --resource-type Microsoft.Web/sites -g <RESOURCE_GROUP> -n <FUNCTION_APP-NAME>/config/web --set properties.functionAppScaleLimit=<SCALE_LIMIT>

سلوكيات تضييق النطاق

يقلل التحجيم المستند إلى الحدث تلقائيًا من السعة عند تقليل الطلب على وظائفك. يقوم بذلك عن طريق استنزاف مثيلات عمليات تنفيذ الدالة الحالية الخاصة بهم ثم إزالة هذه المثيلات. يتم تسجيل هذا السلوك كوضع استنزاف. يمكن أن تمتد فترة السماح للوظائف التي يتم تنفيذها حاليا إلى 10 دقائق لتطبيقات خطة الاستهلاك وما يصل إلى 60 دقيقة لتطبيقات خطة Flex Consumption وPremium. لا ينطبق التحجيم المستند إلى الحدث وهذا السلوك على تطبيقات الخطة المخصصة.

تنطبق الاعتبارات التالية على سلوكيات تضييق النطاق:

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

التحجيم لكل وظيفة

ينطبق فقط على خطة استهلاك Flex (معاينة).

خطة Flex Consumption فريدة من نوعها من حيث أنها تنفذ سلوك تحجيم لكل وظيفة. في التحجيم لكل وظيفة، باستثناء مشغلات HTTP ومشغلات Blob (Event Grid) و Durable Functions، جميع أنواع مشغلات الوظائف الأخرى في مقياس التطبيق الخاص بك على مثيلات مستقلة. يتم توسيع نطاق مشغلات HTTP في تطبيقك معا كمجموعة على نفس المثيلات، كما تفعل جميع Blob (Event Grid)، وجميع مشغلات Durable Functions، والتي لها مثيلاتها المشتركة الخاصة.

ضع في اعتبارك أن تطبيق الوظائف يستضيف خطة استهلاك Flex التي تحتوي على هذه الدالة:

function1 الدالة 2 الدالة 3 الدالة 4 دالة5 الدالة 6 الدالة 7
مشغل HTTP مشغل HTTP مشغل التزامن (دائم) مشغل النشاط (دائم) مشغل ناقل خدمة Azure مشغل ناقل خدمة Azure مشغل مراكز الأحداث

في هذا المثال:

  • تعمل الدالتان المشغلتان من HTTP (function1 و function2) معا على مثيلاتهما الخاصة وتوسعان معا وفقا لإعدادات تزامن HTTP.
  • تعمل الدالتان Durable (function3 و function4) معا على مثيلاتهما الخاصة وتوسعان معا استنادا إلى تقييدات التزامن المكونة.
  • تعمل الوظيفة function5 المشغلة لناقل الخدمة في حد ذاتها ويتم تغيير حجمها بشكل مستقل وفقا لقواعد التحجيم المستندة إلى الهدف لقوائم انتظار وموضوعات ناقل خدمة Microsoft Azure.
  • تعمل الوظيفة function6 المشغلة لناقل الخدمة في حد ذاتها ويتم تغيير حجمها بشكل مستقل وفقا لقواعد التحجيم المستندة إلى الهدف لقوائم انتظار وموضوعات ناقل خدمة Microsoft Azure.
  • يتم تشغيل مشغل مراكز الأحداث (function7) في مثيلاته الخاصة ويتم تغيير حجمه بشكل مستقل وفقا لقواعد التحجيم المستندة إلى الهدف لمراكز الأحداث.

أفضل الممارسات والأنماط للتطبيقات القابلة للتطوير

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

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

لمزيد من المعلومات حول المقياس في Python و Node.js، راجع دليل مطور Azure Functions Python - التحجيم والتزامن ودليل مطور وظائف Azure Node.js - المقياس والتزامن.

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

لمعرفة المزيد، راجع المقالات التالية: