التزامن في Azure Functions

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

توفر الوظائف طريقتين رئيسيتين لإدارة التزامن:

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

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

القياس مقابل التزامن

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

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

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

يعتمد توازن المقياس مقابل التزامن الذي تحاول تحقيقه في تطبيقك على المكان الذي قد تحدث فيه الاختناقات: في المعالجة (قيود العملية كثيفة وحدة المعالجة المركزية) أو في خدمة الخادم (القيود المستندة إلى الإدخال/الإخراج).

تم إصلاح التزامن لكل مثيل

بشكل افتراضي، تدعم معظم المشغلات نموذج تكوين التزامن الثابت لكل مثيل عبر التحجيم المستند إلى الهدف. في هذا النموذج، يحتوي كل نوع مشغل على حد تزامن لكل مثيل.

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

في بعض سيناريوهات التحجيم المستندة إلى الهدف، مثل عند استخدام مشغل Apache Kafka أو Azure Cosmos DB، يكون تكوين التزامن في إعلان الوظيفة، وليس في ملف host.json . تحتوي أنواع المشغلات الأخرى على آليات مضمنة لاستدعاءات موازنة التحميل عبر المثيلات. على سبيل المثال، يستخدم كل من Azure Event Hubs وAzure Cosmos DB مخططا يستند إلى القسم.

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

تزامن مشغل HTTP

ينطبق فقط على خطة الاستهلاك المرن

التزامن المشغل HTTP هو نوع خاص من التزامن الثابت لكل مثيل. في التزامن مع مشغل HTTP، يعتمد التزامن الافتراضي أيضا على حجم المثيل.

تقوم خطة Flex Consumption بتحجيم جميع وظائف مشغل HTTP معا كمجموعة. لمزيد من المعلومات، راجع التحجيم لكل وظيفة.

يشير الجدول التالي إلى إعداد التزامن الافتراضي لمشغلات HTTP على مثيل معين، استنادا إلى حجم ذاكرة المثيل الذي تم تكوينه:

حجم المثيل (ميغابايت)	التزامن الافتراضي*
512	4
2,048	16
4,096	32

^*في تطبيقات Python، تستخدم جميع أحجام المثيلات مستوى التزامن لمشغل HTTP لواحد افتراضيا.

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

إذا كنت بحاجة إلى ضبط التزامن HTTP، فيمكنك القيام بذلك باستخدام Azure CLI. لمزيد من المعلومات، راجع تعيين حدود تزامن HTTP.

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

تحديد التزامن الثابت الأمثل لكل مثيل

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

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

التزامن الديناميكي

توفر Functions نموذج التزامن الديناميكي الذي يبسط تكوين التزامن لجميع تطبيقات الوظائف التي تعمل في نفس الخطة.

إشعار

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

المزايا

يوفر التزامن الديناميكي المزايا التالية:

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

تكوين التزامن الديناميكي

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

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

يمكنك تشغيل التزامن الديناميكي في تطبيق الوظائف الخاص بك عن طريق إضافة الإعدادات التالية إلى ملف host.json الخاص بك:

    { 
        "version": "2.0", 
        "concurrency": { 
            "dynamicConcurrencyEnabled": true, 
            "snapshotPersistenceEnabled": true 
        } 
    } 

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

مدير التزامن

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

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

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

دعم التمديد

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

ملحق	إصدار	‏‏الوصف
تخزين قائمة الانتظار	الإصدار 5.x (ملحق التخزين)	يحتوي مشغل تخزين قائمة الانتظار على حلقة استقصاء الرسائل الخاصة به. عند استخدام تكوين ثابت لكل مثيل، BatchSize تحكم خيارات التكوين NewBatchThreshold والتكوين التزامن. عند استخدام التزامن الديناميكي، يتم تجاهل قيم التكوين هذه. يتم دمج التزامن الديناميكي في حلقة الرسالة، بحيث يتم ضبط عدد الرسائل التي يتم استردادها لكل تكرار ديناميكيا. عند تشغيل دواسة الوقود ، يكون المضيف محملا بشكل زائد. يتم إيقاف معالجة الرسائل مؤقتا حتى يتم إيقاف تشغيل دواسة القيود. عند إيقاف تشغيل دواسة الوقود ، يزداد التزامن.
تخزين كائن ثنائي كبير الحجم	الإصدار 5.x (ملحق التخزين)	داخليا، يستخدم مشغل Blob Storage نفس البنية الأساسية التي يستخدمها مشغل تخزين قائمة الانتظار. عندما تحتاج الكائنات الثنائية كبيرة الحجم الجديدة أو المحدثة إلى المعالجة، تتم كتابة الرسائل إلى قائمة انتظار تحكم مدارة من قبل النظام الأساسي. تتم معالجة قائمة الانتظار هذه باستخدام نفس المنطق المستخدم لمشغل تخزين قائمة الانتظار. عند تشغيل التزامن الديناميكي، تتم إدارة التزامن لمعالجة قائمة انتظار التحكم هذه ديناميكيا.
ناقل الخدمة	الإصدار 5.x	مشغل ناقل الخدمة يدعم حاليًا ثلاثة نماذج تنفيذ. يؤثر التزامن الديناميكي على نماذج التنفيذ هذه بالطرق التالية: معالجة موضوع / قائمة انتظار الإرسال الفردي: يعالج كل استدعاء للوظيفة رسالة واحدة. عند استخدام تكوين ثابت لكل مثيل، MaxConcurrentCalls يتحكم خيار التكوين في التزامن. عند استخدام التزامن الديناميكي، يتم تجاهل قيمة التكوين هذه، ويتم ضبط التزامن ديناميكيا. معالجة موضوع الإرسال الفردي المستند إلى الجلسة: يعالج كل استدعاء للوظيفة رسالة واحدة. استنادا إلى عدد الجلسات النشطة لموضوعك أو قائمة الانتظار، يستأجر كل مثيل جلسة واحدة أو أكثر. تُعالج الرسائل في كل جلسة بشكل تسلسلي؛ لضمان الترتيب في الجلسة. عندما لا تستخدم التزامن الديناميكي، يتحكم الإعداد MaxConcurrentSessions في التزامن. عند تشغيل التزامن الديناميكي، يتم تجاهل القيمة MaxConcurrentSessions ، ويتم ضبط عدد الجلسات التي يعالجها كل مثيل ديناميكيا. معالجة الدفعات: يعالج كل استدعاء للوظيفة مجموعة من الرسائل، تحكمها الإعداد MaxMessageCount . نظرا لأن استدعاءات الدفعات متسلسلة، فإن التزامن للوظيفة التي يتم تشغيلها على الدفعة يكون دائما واحدا، ولا ينطبق التزامن الديناميكي.

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

لمزيد من المعلومات، راجع الموارد التالية:

• أفضل الممارسات لوظائف Azure الموثوقة
• دليل مطور خدمة وظائف Azure
• مشغلات وعمليات الربط في Azure Functions