إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
تقدم هذه المقالة إرشادات لتحسين أداء وموثوقية تطبيقات الوظائف بدون خادم . للحصول على مجموعة عامة من أفضل الممارسات دالات Azure، انظر دالات Azure أفضل الممارسات.
فيما يلي أفضل الممارسات في كيفية بناء وتصميم حلولك بدون خوادم باستخدام دالات Azure.
تجنب الدوال طويلة الأمد
يمكن أن تتسبب الدالات الكبيرة طويلة الأمد في حدوث مشكلات مهلة غير متوقعة. لمعرفة المزيد عن المهلات الزمنية لخطة استضافة معينة، راجع مدة انتهاء تطبيق الوظائف.
يمكن أن تصبح الدالة كبيرة بسبب العديد من التبعيات Node.js. يمكن أن يؤدي استيراد التبعيات أيضا إلى زيادة أوقات التحميل التي تؤدي إلى مهلات غير متوقعة. يتم تحميل التبعيات بشكل صريح وضمني. قد تقوم وحدة نمطية واحدة محملة بواسطة التعليمات البرمجية بتحميل وحداتها الإضافية.
كلما أمكن، أعد بناء التعليمات البرمجية للوظائف الكبيرة في مجموعات وظائف أصغر تعمل معا وتعيد الاستجابات بسرعة. على سبيل المثال، قد تتطلب دالة مشغل webhook أو HTTP استجابة إقرار ضمن حد زمني معين؛ من الشائع أن تتطلب خطافات الويب استجابة فورية. يمكنك تمرير حمولة مشغل HTTP إلى قائمة انتظار لتتم معالجتها بواسطة دالة مشغل قائمة انتظار. يتيح لك هذا الأسلوب تأجيل العمل الفعلي وإرجاع استجابة فورية.
تأكد من اكتمال مهام الخلفية
عندما تبدأ الدالة أي مهام أو عمليات رد اتصال أو مؤشرات ترابط أو عمليات، يجب إكمالها قبل إرجاع التعليمات البرمجية للدالة. نظرا لأن الدالات لا تتعقب مؤشرات ترابط الخلفية هذه، يمكن أن يحدث إيقاف تشغيل الموقع بغض النظر عن حالة مؤشر ترابط الخلفية، مما قد يتسبب في سلوك غير مقصود في الدالات الخاصة بك.
على سبيل المثال، إذا بدأت دالة مهمة في الخلفية وأرجعت استجابة ناجحة قبل اكتمال المهمة، فإن وقت تشغيل الدالات يعتبر التنفيذ قد اكتمل بنجاح، بغض النظر عن نتيجة مهمة الخلفية. إذا كانت مهمة الخلفية هذه تؤدي عملا أساسيا، فقد يتم استباقها بواسطة إيقاف تشغيل الموقع، مما يترك هذا العمل في حالة غير معروفة.
اتصال الوظائف المتقاطعة
تم بناء Durable Functions وAzure Logic Apps لإدارة انتقالات الحالات والتواصل بين وظائف متعددة.
إذا لم تكن تستخدم Durable Functions أو Logic Apps للتكامل مع وظائف متعددة، فمن الأفضل استخدام قوائم التخزين للتواصل بين الوظائف. السبب الرئيسي هو أن قوائم انتظار التخزين أرخص وأسهل بكثير في التوفير من خيارات التخزين الأخرى.
يقتصر حجم الرسائل الفردية في قائمة انتظار التخزين على 64 كيلوبايت. إذا كنت بحاجة لتمرير رسائل أكبر بين الوظائف، يمكن استخدام قائمة انتظار ناقل خدمة Azure لدعم أحجام رسائل تصل إلى 256 كيلوبايت في المستوى القياسي، وحتى 100 ميجابايت في الطبقة المميزة.
مواضيع Service Bus مفيدة إذا كنت بحاجة إلى تصفية الرسائل قبل المعالجة.
تعد مراكز الأحداث مفيدة لدعم الاتصالات ذات الحجم الكبير.
كتابة الدالات لتكون عديمة الحالة
يجب أن تكون الوظائف عديمة الحالة ومكررة إن أمكن. إقران أي معلومات حالة مطلوبة ببياناتك. على سبيل المثال، من المرجح أن يكون للأمر الذي يتم معالجته عضو مرتبط state . يمكن أن تعالج الدالة ترتيبا استنادا إلى تلك الحالة بينما تظل الدالة نفسها عديمة الحالة.
يوصى بالوظائف غير الفعالة بشكل خاص مع مشغلات المؤقت. على سبيل المثال، إذا كان لديك شيء يجب تشغيله مرة واحدة في اليوم، فاكتبه حتى يمكن تشغيله في أي وقت خلال اليوم بنفس النتائج. يمكن إنهاء الدالة عندما لا يكون هناك عمل ليوم معين. أيضا إذا فشل تشغيل سابق في الاكتمال، يجب أن يلتقط التشغيل التالي من حيث توقفت. هذا مهم بشكل خاص للروابط المستندة إلى الرسائل التي تعيد المحاولة عند الفشل. لمزيد من المعلومات، راجع تصميم دالات Azure لإدخال متطابق.
كتابة وظائف دفاعية
افترض أن الدالة قد تواجه استثناء في أي وقت. صمم وظائفك مع القدرة على المتابعة من نقطة فشل سابقة أثناء التنفيذ التالي. ضع في اعتبارك سيناريو يتطلب الإجراءات التالية:
- الاستعلام عن 10000 صف في قاعدة بيانات.
- قم بإنشاء رسالة قائمة انتظار لكل صف من هذه الصفوف لمعالجتها بشكل أكبر أسفل السطر.
اعتمادا على مدى تعقيد النظام الخاص بك، قد يكون لديك: مشاركة خدمات انتقال البيانات من الخادم تتصرف بشكل سيئ، أو انقطاع الشبكات، أو الوصول إلى حدود الحصة النسبية، وما إلى ذلك. يمكن أن تؤثر كل هذه على وظيفتك في أي وقت. تحتاج إلى تصميم وظائفك لتكون مستعدا لذلك.
كيف تتفاعل التعليمات البرمجية الخاصة بك إذا حدث فشل بعد إدراج 5000 من هذه العناصر في قائمة انتظار للمعالجة؟ تعقب العناصر في مجموعة قمت بإكمالها. وإلا، يمكنك إدراجها مرة أخرى في المرة القادمة. هذا الإدخال المزدوج يمكن أن يؤثر بشكل كبير على سير عملك، لذا اجعل وظائفك غير موثوقة.
إذا تمت معالجة عنصر قائمة انتظار بالفعل، فاسمح لوظيفتك بأن تكون no-op.
استفد من الإجراءات الدفاعية المتوفرة بالفعل للمكونات التي تستخدمها في منصة دالات Azure. على سبيل المثال، انظر التعامل مع رسائل قائمة الانتظار السامة في وثائق تخزين Azure محفزات وربط الطابور.
بالنسبة للوظائف المعتمدة على HTTP، اعتبر استراتيجيات إصدار
أفضل ممارسات تنظيم الوظائف
كجزء من الحل الخاص بك، يمكنك تطوير ونشر وظائف متعددة. غالبًا ما يتم دمج هذه الوظائف في تطبيق وظيفة واحدة، ولكن يمكن تشغيلها أيضًا في تطبيقات وظائف منفصلة. في خطط استضافة Premium والمخصصة (App Service)، يمكن لتطبيقات الوظائف المتعددة أيضا مشاركة نفس الموارد عن طريق التشغيل في نفس الخطة. يمكن أن تؤثر كيفية تجميع وظائفك وتطبيقات الوظائف على الأداء وتغيير السعة والتكوين والتوزيع وأمان الحل ككل. لا توجد قواعد تنطبق على كل سيناريو، لذا ضع في اعتبارك المعلومات الواردة في هذا القسم عند تخطيط وظائفك وتطويرها.
تنظيم وظائف الأداء والتحجيم
كل وظيفة تقوم بإنشائها لها بصمة ذاكرة. في حين أن هذه البصمة عادة ما تكون صغيرة، فإن وجود عدد كبير جدا من الوظائف داخل تطبيق الوظائف يمكن أن يؤدي إلى بدء تشغيل أبطأ لتطبيقك على مثيلات جديدة. وهذا يعني أيضا أن الاستخدام الكلي للذاكرة لتطبيق الوظائف الخاص بك قد يكون أعلى. من الصعب تحديد عدد الوظائف التي يجب أن تكون في تطبيق واحد، والذي يعتمد على حمل العمل الخاص بك. ومع ذلك، إذا كانت وظيفتك تخزن الكثير من البيانات في الذاكرة، ففكر في وجود وظائف أقل في تطبيق واحد.
إذا قمت بتشغيل تطبيقات وظائف متعددة في خطة Premium واحدة أو خطة مخصصة (App Service)، فستشارك جميع هذه التطبيقات نفس الموارد المخصصة للخطة. إذا كان لديك تطبيق وظائف واحد يحتوي على متطلبات ذاكرة أعلى بكثير من التطبيقات الأخرى، فإنه يستخدم كمية غير متناسبة من موارد الذاكرة على كل مثيل يتم نشر التطبيق عليه. نظرا لأن هذا قد يترك ذاكرة أقل متوفرة للتطبيقات الأخرى على كل مثيل، فقد تحتاج إلى تشغيل تطبيق وظائف عالي الذاكرة باستخدام هذا في خطة الاستضافة المنفصلة الخاصة به.
Note
عند استخدام خطة الاستهلاك، نوصي دائما بوضع كل تطبيق في خطة خاصة به، لأن التطبيقات يتم تكبيرها بشكل مستقل على أي حال. لمزيد من المعلومات، راجع تطبيقات متعددة في نفس الخطة.
ضع في اعتبارك ما إذا كنت تريد تجميع الدالات مع ملفات تعريف تحميل مختلفة. على سبيل المثال، إذا كانت لديك دالة تعالج عدة آلاف من رسائل قائمة الانتظار، وأخرى يتم استدعاؤها أحيانا فقط ولكن تحتوي على متطلبات ذاكرة عالية، فقد تحتاج إلى نشرها في تطبيقات وظائف منفصلة حتى تحصل على مجموعات مواردها الخاصة وتحجيمها بشكل مستقل عن بعضها البعض.
تنظيم الوظائف للتكوين والنشر
تطبيقات الوظائف تحتوي على ملف host.json، يستخدم لتكوين السلوك المتقدم لمشغلات الوظائف ووقت التشغيل دالات Azure. التغييرات في الملف تنطبق host.json على جميع الوظائف داخل التطبيق. إذا كان لديك بعض الوظائف التي تحتاج إلى تكوينات مخصصة، ففكر في نقلها إلى تطبيق الوظائف الخاص بها.
جميع الوظائف في مشروعك المحلي يتم نشرها معا كمجموعة من الملفات إلى تطبيق الوظائف الخاص بك في Azure. قد تحتاج إلى نشر وظائف فردية بشكل منفصل أو استخدام ميزات مثل فتحات النشر لبعض الوظائف وليس لغيرها. في مثل هذه الحالات، يجب نشر هذه الوظائف (في مشاريع التعليمات البرمجية المنفصلة) إلى تطبيقات وظائف مختلفة.
تنظيم الوظائف حسب الامتياز
تمنح سلاسل الاتصال وبيانات الاعتماد الأخرى المخزنة في إعدادات التطبيق جميع الوظائف في تطبيق الوظائف نفس مجموعة الأذونات في المورد المقترن. يمكنك التفكير في تقليل عدد الوظائف التي لها حق الوصول إلى بيانات الاعتماد المحددة عن طريق نقل الوظائف التي لا تستخدم بيانات الاعتماد هذه إلى تطبيق وظائف منفصل. يمكنك دائماً استخدام تقنيات مثل تسلسل الوظائف لتمرير البيانات بين الوظائف في تطبيقات الوظائف المختلفة.
أفضل ممارسات قابلية التوسع
هناك عدد من العوامل التي تؤثر على كيفية تأثير مثيلات مقياس تطبيق الوظائف. التفاصيل موفرة في وثائق تحجيم الوظائف. فيما يلي بعض أفضل الممارسات لضمان قابلية التوسع الأمثل لتطبيق الوظائف.
مشاركة الاتصالات وإدارتها
إعادة استخدام الاتصالات بالموارد الخارجية كلما أمكن ذلك. راجع كيفية إدارة الاتصالات في دالات Azure.
تجنب مشاركة حسابات التخزين
عند إنشاء تطبيق دالة، يجب إقرانه بحساب تخزين. يتم الحفاظ على اتصال حساب التخزين في إعداد تطبيق AzureWebJobsStorage.
لتحقيق أقصى قدر من الأداء، استخدم حساب تخزين منفصل لكل تطبيق وظائف. هذا النهج مهم بشكل خاص عندما يكون لديك دوال مفعلة من Durable Functions أو Event Hubs، وكلاهما يولد حجما كبيرا من معاملات التخزين. عندما يتفاعل منطق تطبيقك مع تخزين Azure، إما مباشرة (باستخدام مجموعة تطوير البرمجيات للتخزين) أو من خلال أحد قيود التخزين، يجب عليك استخدام حساب تخزين مخصص. على سبيل المثال، إذا كان لديك دالة مشغلة بواسطة مركز الأحداث تكتب بعض البيانات إلى تخزين كائن ثنائي كبير الحجم، فاستخدم حسابي تخزين: أحدهما لتطبيق الدالة والآخر للكائنات الثنائية كبيرة الحجم التي تخزنها الدالة.
لا تخلط التعليمات البرمجية للاختبار والإنتاج في نفس تطبيق الوظائف
تتشارك الوظائف داخل تطبيق الوظائف في الموارد. على سبيل المثال، تتم مشاركة الذاكرة. إذا كنت تستخدم تطبيق وظائف في الإنتاج، فلا تقم بإضافة وظائف وموارد متعلقة بالاختبار إليه. يمكن أن يسبب حملا غير متوقع أثناء تنفيذ التعليمات البرمجية للإنتاج.
كن حذرا فيما تقوم بتحميله في تطبيقات وظائف الإنتاج. يتم حساب متوسط الذاكرة عبر كل وظيفة في التطبيق.
إذا كان لديك تجميع مشترك مشار إليه في عدة دوال .NET، ضعه في مجلد مشترك مشترك. وإلا، يمكنك عن طريق الخطأ نشر إصدارات متعددة من نفس الثنائي الذي يتصرف بشكل مختلف بين الدالات.
لا تستخدم التسجيل المطول في التعليمات البرمجية للإنتاج، والتي لها تأثير سلبي على الأداء.
استخدام التعليمات البرمجية غير المتزامنة ولكن تجنب حظر المكالمات
البرمجة غير المتزامنة هي أفضل ممارسة موصى بها، خاصة عند تضمين حظر عمليات الإدخال/الإخراج.
في C#، تجنب دائما الإشارة إلى Result الخاصية أو طريقة الاستدعاء Wait على مثيل Task . يمكن أن يؤدي هذا النهج إلى استنفاد مؤشر الترابط.
Tip
إذا كنت تخطط لاستخدام روابط HTTP أو WebHook، فخطط لتجنب استنفاد المنفذ الذي قد ينتج عن إنشاء مثيل غير صحيح لـ HttpClient. لمزيد من المعلومات، راجع كيفية إدارة الاتصالات في دالات Azure.
استخدام عمليات متعددة للعاملين
بشكل افتراضي، يستخدم أي مثيل مضيف ل Functions عملية عامل واحد. لتحسين الأداء، خاصة مع أوقات التشغيل أحادية الخيط مثل Python، استخدم FUNCTIONS_WORKER_PROCESS_COUNT لزيادة عدد عمليات العمال لكل مضيف (حتى 10). يحاول دالات Azure بعد ذلك توزيع استدعاءات الوظائف المتزامنة بالتساوي بين هؤلاء الموظفين.
ينطبق FUNCTIONS_WORKER_PROCESS_COUNT على كل مضيف تقوم Functions بإنشائه عند توسيع نطاق التطبيق الخاص بك لتلبية الطلب.
تلقي الرسائل على دفعة كلما أمكن ذلك
تتيح بعض المشغلات مثل Event Hub تلقي دفعة من الرسائل على استدعاء واحد. يتمتع إرسال الرسائل في دفعات بأداء أفضل بكثير. يمكنك ضبط الحد الأقصى لحجم الدفعة في host.json الملف كما هو موضح في وثائقhost.json المرجعية
بالنسبة إلى وظائف C#، يمكنك تغيير النوع إلى صفيف مكتوب بقوة. على سبيل المثال، بدلا من EventData sensorEvent توقيع الطريقة، يمكن أن يكون .EventData[] sensorEvent بالنسبة للغات الأخرى، ستحتاج إلى تعيين خاصية العدد الكبير في function.json إلى many لتمكين التجميع كما هو موضح هنا.
تكوين سلوكيات المضيف للتعامل بشكل أفضل مع التزامن
يسمح الملف host.json في تطبيق الوظائف بتكوين سلوكيات تشغيل المضيف وسلوكيات التشغيل. بالإضافة إلى سلوكيات الإرسال في دفعات، يمكنك إدارة التزامن لعدد من المشغلات. غالبًا ما يساعد ضبط القيم في هذه الخيارات على تغيير سعة كل مثيل بما يناسب مطالب الوظائف التي تم استدعاؤها.
الإعدادات في ملف host.json تنطبق على جميع الوظائف داخل التطبيق، ضمن نسخة واحدة من الوظيفة. على سبيل المثال، إذا كان لديك تطبيق وظيفي يحتوي على وظيفتين HTTP وطلبات maxConcurrentRequests مضبوطة على 25، فإن الطلب لأي من مشغلي HTTP يحتسب ضمن 25 طلبا متزامنا مشتركا. عند تحجيم تطبيق الوظائف هذا إلى 10 مثيلات، تسمح الوظائف العشرة فعليا ب 250 طلبا متزامنا (10 مثيلات * 25 طلبا متزامنا لكل مثيل).
خيارات تكوين المضيف الأخرى موجودة في مقالة تكوينhost.json.
الخطوات التالية
لمزيد من المعلومات، راجع الموارد التالية: