إشعار
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تسجيل الدخول أو تغيير الدلائل.
يتطلب الوصول إلى هذه الصفحة تخويلاً. يمكنك محاولة تغيير الدلائل.
This article provides guidance to improve the performance and reliability of your serverless function apps. للحصول على مجموعة أكثر عمومية من أفضل ممارسات Azure Functions، راجع أفضل ممارسات Azure Functions.
فيما يلي أفضل الممارسات في كيفية إنشاء حلولك بلا خادم وهندستها باستخدام Azure Functions.
تجنب الدوال طويلة الأمد
يمكن أن تتسبب الدالات الكبيرة طويلة الأمد في حدوث مشكلات مهلة غير متوقعة. لمعرفة المزيد حول المهلات لخطة استضافة معينة، راجع مدة مهلة تطبيق الوظائف.
يمكن أن تصبح الدالة كبيرة بسبب العديد من التبعيات Node.js. يمكن أن يؤدي استيراد التبعيات أيضا إلى زيادة أوقات التحميل التي تؤدي إلى مهلات غير متوقعة. يتم تحميل التبعيات بشكل صريح وضمني. قد تقوم وحدة نمطية واحدة محملة بواسطة التعليمات البرمجية بتحميل وحداتها الإضافية.
كلما أمكن، أعد بناء التعليمات البرمجية للوظائف الكبيرة في مجموعات وظائف أصغر تعمل معا وتعيد الاستجابات بسرعة. على سبيل المثال، قد تتطلب دالة مشغل webhook أو HTTP استجابة إقرار ضمن حد زمني معين؛ من الشائع أن تتطلب خطافات الويب استجابة فورية. يمكنك تمرير حمولة مشغل HTTP إلى قائمة انتظار لتتم معالجتها بواسطة دالة مشغل قائمة انتظار. يتيح لك هذا الأسلوب تأجيل العمل الفعلي وإرجاع استجابة فورية.
تأكد من اكتمال مهام الخلفية
عندما تبدأ الدالة أي مهام أو عمليات رد اتصال أو مؤشرات ترابط أو عمليات، يجب إكمالها قبل إرجاع التعليمات البرمجية للدالة. نظرا لأن الدالات لا تتعقب مؤشرات ترابط الخلفية هذه، يمكن أن يحدث إيقاف تشغيل الموقع بغض النظر عن حالة مؤشر ترابط الخلفية، مما قد يتسبب في سلوك غير مقصود في الدالات الخاصة بك.
على سبيل المثال، إذا بدأت دالة مهمة في الخلفية وأرجعت استجابة ناجحة قبل اكتمال المهمة، فإن وقت تشغيل الدالات يعتبر التنفيذ قد اكتمل بنجاح، بغض النظر عن نتيجة مهمة الخلفية. إذا كانت مهمة الخلفية هذه تؤدي عملا أساسيا، فقد يتم استباقها بواسطة إيقاف تشغيل الموقع، مما يترك هذا العمل في حالة غير معروفة.
اتصال الوظائف المتقاطعة
Durable Functions and Azure Logic Apps are built to manage state transitions and communication between multiple functions.
إذا لم تستخدم Durable Functions أو Logic Apps للتكامل مع وظائف متعددة، فمن الأفضل استخدام قوائم انتظار التخزين للاتصال عبر الوظائف. السبب الرئيسي هو أن قوائم انتظار التخزين أرخص وأسهل بكثير في التوفير من خيارات التخزين الأخرى.
يقتصر حجم الرسائل الفردية في قائمة انتظار التخزين على 64 كيلوبايت. إذا كنت بحاجة إلى تمرير رسائل أكبر بين الدالات، يمكن استخدام قائمة انتظار ناقل خدمة Microsoft Azure لدعم أحجام الرسائل التي تصل إلى 256 كيلوبايت في المستوى القياسي، وما يصل إلى 100 ميغابايت في الطبقة المتميزة.
تكون مواضيع ناقل خدمة Microsoft Azure مفيدة إذا كنت تحتاج إلى تصفية الرسائل قبل المعالجة.
تعد مراكز الأحداث مفيدة لدعم الاتصالات ذات الحجم الكبير.
كتابة الدالات لتكون عديمة الحالة
يجب أن تكون الوظائف عديمة الحالة ومكررة إن أمكن. إقران أي معلومات حالة مطلوبة ببياناتك. على سبيل المثال، من المحتمل أن يكون للطلب الذي تتم معالجته عضوا مقترنا state . يمكن أن تعالج الدالة ترتيبا استنادا إلى تلك الحالة بينما تظل الدالة نفسها عديمة الحالة.
يوصى بالوظائف غير الفعالة بشكل خاص مع مشغلات المؤقت. على سبيل المثال، إذا كان لديك شيء يجب تشغيله مرة واحدة في اليوم، فاكتبه حتى يمكن تشغيله في أي وقت خلال اليوم بنفس النتائج. يمكن إنهاء الدالة عندما لا يكون هناك عمل ليوم معين. أيضا إذا فشل تشغيل سابق في الاكتمال، يجب أن يلتقط التشغيل التالي من حيث توقفت. هذا مهم بشكل خاص للروابط المستندة إلى الرسائل التي تعيد المحاولة عند الفشل. لمزيد من المعلومات، راجع تصميم Azure Functions لإدخال متطابق.
كتابة وظائف دفاعية
افترض أن الدالة قد تواجه استثناء في أي وقت. صمم وظائفك مع القدرة على المتابعة من نقطة فشل سابقة أثناء التنفيذ التالي. ضع في اعتبارك سيناريو يتطلب الإجراءات التالية:
- الاستعلام عن 10000 صف في قاعدة بيانات.
- قم بإنشاء رسالة قائمة انتظار لكل صف من هذه الصفوف لمعالجتها بشكل أكبر أسفل السطر.
اعتمادا على مدى تعقيد النظام الخاص بك، قد يكون لديك: مشاركة خدمات انتقال البيانات من الخادم تتصرف بشكل سيئ، أو انقطاع الشبكات، أو الوصول إلى حدود الحصة النسبية، وما إلى ذلك. يمكن أن تؤثر كل هذه على وظيفتك في أي وقت. تحتاج إلى تصميم وظائفك لتكون مستعدا لذلك.
كيف تتفاعل التعليمات البرمجية الخاصة بك إذا حدث فشل بعد إدراج 5000 من هذه العناصر في قائمة انتظار للمعالجة؟ تعقب العناصر في مجموعة قمت بإكمالها. وإلا، يمكنك إدراجها مرة أخرى في المرة القادمة. يمكن أن يكون لهذا الإدراج المزدوج تأثير خطير على تدفق العمل الخاص بك، لذا اجعل وظائفك غير فعالة.
إذا تمت معالجة عنصر قائمة انتظار بالفعل، فاسمح لوظيفتك بأن تكون no-op.
استفد من التدابير الدفاعية المتوفرة بالفعل للمكونات التي تستخدمها في النظام الأساسي ل Azure Functions. على سبيل المثال، راجع معالجة رسائل قائمة الانتظار غير المستخدمة في الوثائق الخاصة بمشغلات وروابط قائمة انتظار تخزين Azure.
بالنسبة للوظائف المستندة إلى HTTP، ضع في اعتبارك استراتيجيات تعيين إصدار واجهة برمجة التطبيقات باستخدام Azure API Management. على سبيل المثال، إذا كان عليك تحديث تطبيق الوظائف المستند إلى HTTP، فقم بنشر التحديث الجديد إلى تطبيق وظائف منفصل واستخدم مراجعات أو إصدارات إدارة واجهة برمجة التطبيقات لتوجيه العملاء إلى الإصدار الجديد أو المراجعة. بمجرد أن يستخدم جميع العملاء الإصدار أو المراجعة ولا يتم ترك المزيد من عمليات التنفيذ على تطبيق الوظائف السابق، يمكنك إلغاء توفير تطبيق الوظائف السابق.
أفضل ممارسات تنظيم الوظائف
كجزء من الحل الخاص بك، يمكنك تطوير ونشر وظائف متعددة. غالبًا ما يتم دمج هذه الوظائف في تطبيق وظيفة واحدة، ولكن يمكن تشغيلها أيضًا في تطبيقات وظائف منفصلة. في خطط استضافة Premium والمخصصة (App Service)، يمكن لتطبيقات الوظائف المتعددة أيضا مشاركة نفس الموارد عن طريق التشغيل في نفس الخطة. يمكن أن تؤثر كيفية تجميع وظائفك وتطبيقات الوظائف على الأداء وتغيير السعة والتكوين والتوزيع وأمان الحل ككل. لا توجد قواعد تنطبق على كل سيناريو، لذا ضع في اعتبارك المعلومات الواردة في هذا القسم عند تخطيط وظائفك وتطويرها.
تنظيم وظائف الأداء والتحجيم
كل وظيفة تقوم بإنشائها لها بصمة ذاكرة. في حين أن هذه البصمة عادة ما تكون صغيرة، فإن وجود عدد كبير جدا من الوظائف داخل تطبيق الوظائف يمكن أن يؤدي إلى بدء تشغيل أبطأ لتطبيقك على مثيلات جديدة. وهذا يعني أيضا أن الاستخدام الكلي للذاكرة لتطبيق الوظائف الخاص بك قد يكون أعلى. من الصعب تحديد عدد الوظائف التي يجب أن تكون في تطبيق واحد، والذي يعتمد على حمل العمل الخاص بك. ومع ذلك، إذا كانت وظيفتك تخزن الكثير من البيانات في الذاكرة، ففكر في وجود وظائف أقل في تطبيق واحد.
إذا قمت بتشغيل تطبيقات وظائف متعددة في خطة Premium واحدة أو خطة مخصصة (App Service)، فستشارك جميع هذه التطبيقات نفس الموارد المخصصة للخطة. إذا كان لديك تطبيق وظائف واحد يحتوي على متطلبات ذاكرة أعلى بكثير من التطبيقات الأخرى، فإنه يستخدم كمية غير متناسبة من موارد الذاكرة على كل مثيل يتم نشر التطبيق عليه. نظرا لأن هذا قد يترك ذاكرة أقل متوفرة للتطبيقات الأخرى على كل مثيل، فقد تحتاج إلى تشغيل تطبيق وظائف عالي الذاكرة باستخدام هذا في خطة الاستضافة المنفصلة الخاصة به.
Note
When using the Consumption plan, we recommend you always put each app in its own plan, since apps are scaled independently anyway. لمزيد من المعلومات، راجع تطبيقات متعددة في نفس الخطة.
ضع في اعتبارك ما إذا كنت تريد تجميع الدالات مع ملفات تعريف تحميل مختلفة. على سبيل المثال، إذا كانت لديك دالة تعالج عدة آلاف من رسائل قائمة الانتظار، وأخرى يتم استدعاؤها أحيانا فقط ولكن تحتوي على متطلبات ذاكرة عالية، فقد تحتاج إلى نشرها في تطبيقات وظائف منفصلة حتى تحصل على مجموعات مواردها الخاصة وتحجيمها بشكل مستقل عن بعضها البعض.
تنظيم الوظائف للتكوين والنشر
تحتوي تطبيقات الوظائف على host.json ملف، والذي يستخدم لتكوين السلوك المتقدم لمشغلات الوظائف ووقت تشغيل Azure Functions. تنطبق التغييرات على host.json الملف على جميع الوظائف داخل التطبيق. إذا كان لديك بعض الوظائف التي تحتاج إلى تكوينات مخصصة، ففكر في نقلها إلى تطبيق الوظائف الخاص بها.
يتم نشر جميع الوظائف في مشروعك المحلي معا كملف مجموعة من الملفات إلى تطبيق الوظائف في Azure. You might need to deploy individual functions separately or use features like deployment slots for some functions and not others. في مثل هذه الحالات، يجب نشر هذه الوظائف (في مشاريع التعليمات البرمجية المنفصلة) إلى تطبيقات وظائف مختلفة.
تنظيم الوظائف حسب الامتياز
تمنح سلاسل الاتصال وبيانات الاعتماد الأخرى المخزنة في إعدادات التطبيق جميع الوظائف في تطبيق الوظائف نفس مجموعة الأذونات في المورد المقترن. يمكنك التفكير في تقليل عدد الوظائف التي لها حق الوصول إلى بيانات الاعتماد المحددة عن طريق نقل الوظائف التي لا تستخدم بيانات الاعتماد هذه إلى تطبيق وظائف منفصل. You can always use techniques such as function chaining to pass data between functions in different function apps.
أفضل ممارسات قابلية التوسع
هناك عدد من العوامل التي تؤثر على كيفية تأثير مثيلات مقياس تطبيق الوظائف. The details are provided in the documentation for function scaling. فيما يلي بعض أفضل الممارسات لضمان قابلية التوسع الأمثل لتطبيق الوظائف.
مشاركة الاتصالات وإدارتها
إعادة استخدام الاتصالات بالموارد الخارجية كلما أمكن ذلك. راجع كيفية إدارة الاتصالات في Azure Functions.
تجنب مشاركة حسابات التخزين
عند إنشاء تطبيق دالة، يجب إقرانه بحساب تخزين. يتم الاحتفاظ باتصال حساب التخزين في إعداد تطبيق AzureWebJobsStorage.
لتحقيق أقصى قدر من الأداء، استخدم حساب تخزين منفصل لكل تطبيق وظائف. هذا الأسلوب مهم بشكل خاص عندما يكون لديك Durable Functions أو Event Hubs تشغيل الوظائف، والتي تنشئ كل منهما حجم كبير من معاملات التخزين. عندما يتفاعل منطق التطبيق الخاص بك مع Azure Storage، إما مباشرةً (باستخدام SDK للتخزين) أو من خلال أحد روابط التخزين، يجب عليك استخدام حساب تخزين مخصص. على سبيل المثال، إذا كان لديك دالة مشغلة بواسطة مركز الأحداث تكتب بعض البيانات إلى تخزين كائن ثنائي كبير الحجم، فاستخدم حسابي تخزين: أحدهما لتطبيق الدالة والآخر للكائنات الثنائية كبيرة الحجم التي تخزنها الدالة.
لا تخلط التعليمات البرمجية للاختبار والإنتاج في نفس تطبيق الوظائف
تتشارك الوظائف داخل تطبيق الوظائف في الموارد. على سبيل المثال، تتم مشاركة الذاكرة. إذا كنت تستخدم تطبيق وظائف في الإنتاج، فلا تقم بإضافة وظائف وموارد متعلقة بالاختبار إليه. يمكن أن يسبب حملا غير متوقع أثناء تنفيذ التعليمات البرمجية للإنتاج.
كن حذرا فيما تقوم بتحميله في تطبيقات وظائف الإنتاج. يتم حساب متوسط الذاكرة عبر كل وظيفة في التطبيق.
إذا كان لديك تجميع مشترك تمت الإشارة إليه في دالات .NET متعددة، فضعه في مجلد مشترك مشترك مشترك. وإلا، يمكنك عن طريق الخطأ نشر إصدارات متعددة من نفس الثنائي الذي يتصرف بشكل مختلف بين الدالات.
لا تستخدم التسجيل المطول في التعليمات البرمجية للإنتاج، والتي لها تأثير سلبي على الأداء.
استخدام التعليمات البرمجية غير المتزامنة ولكن تجنب حظر المكالمات
البرمجة غير المتزامنة هي أفضل ممارسة موصى بها، خاصة عند تضمين حظر عمليات الإدخال/الإخراج.
في C#، تجنب دائما الرجوع إلى الخاصية Result أو أسلوب الاستدعاء Wait على مثيل Task . يمكن أن يؤدي هذا النهج إلى استنفاد مؤشر الترابط.
Tip
إذا كنت تخطط لاستخدام روابط HTTP أو WebHook، فخطط لتجنب استنفاد المنفذ الذي قد ينتج عن إنشاء مثيل غير صحيح لـ HttpClient. لمزيد من المعلومات، راجع كيفية إدارة الاتصالات في وظائف Azure.
استخدام عمليات متعددة للعاملين
بشكل افتراضي، يستخدم أي مثيل مضيف ل Functions عملية عامل واحد. To improve performance, especially with single-threaded runtimes like Python, use the FUNCTIONS_WORKER_PROCESS_COUNT to increase the number of worker processes per host (up to 10). يحاول Azure Functions بعد ذلك توزيع استدعاءات الوظيفة المتزامنة عبر هذه العوامل بالتساوي.
ينطبق FUNCTIONS_WORKER_PROCESS_COUNT على كل مضيف تقوم Functions بإنشائه عند توسيع نطاق التطبيق الخاص بك لتلبية الطلب.
تلقي الرسائل على دفعة كلما أمكن ذلك
تتيح بعض المشغلات مثل Event Hub تلقي دفعة من الرسائل على استدعاء واحد. يتمتع إرسال الرسائل في دفعات بأداء أفضل بكثير. يمكنك تكوين الحد الأقصى لحجم الدفعة host.json في الملف كما هو مفصل في الوثائق المرجعيةhost.json
بالنسبة إلى وظائف C#، يمكنك تغيير النوع إلى صفيف مكتوب بقوة. على سبيل المثال، بدلا من EventData sensorEvent توقيع الأسلوب يمكن أن يكون EventData[] sensorEvent. بالنسبة للغات الأخرى، ستحتاج إلى تعيين خاصية العلاقة الأساسية بشكل صريح في الخاص بك function.jsonmany لتمكين الإرسال في دفعات كما هو موضح هنا.
تكوين سلوكيات المضيف للتعامل بشكل أفضل مع التزامن
host.json يسمح الملف في تطبيق الوظائف بتكوين وقت تشغيل المضيف وسلوكيات المشغل. بالإضافة إلى سلوكيات الإرسال في دفعات، يمكنك إدارة التزامن لعدد من المشغلات. غالبًا ما يساعد ضبط القيم في هذه الخيارات على تغيير سعة كل مثيل بما يناسب مطالب الوظائف التي تم استدعاؤها.
Settings in the host.json file apply across all functions within the app, within a single instance of the function. على سبيل المثال، إذا كان لديك تطبيق دالة مع اثنتين من دالات HTTP والطلبات maxConcurrentRequests المعينة إلى 25، فإن الطلب إلى أي من مشغلي HTTP سيحسب في الطلبات المتزامنة ال 25 المشتركة. عند تحجيم تطبيق الوظائف هذا إلى 10 مثيلات، تسمح الوظائف العشرة فعليا ب 250 طلبا متزامنا (10 مثيلات * 25 طلبا متزامنا لكل مثيل).
يتم العثور على خيارات تكوين المضيف الأخرى في مقالة تكوينhost.json.
Next steps
لمزيد من المعلومات، راجع الموارد التالية: