أفضل الممارسات ل Azure App Service

تلخص هذه المقالة أفضل الممارسات لاستخدام Azure App Service.

التوصيل الشبكي

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

• زيادة زمن الانتقال في الاتصال بين الموارد
• الرسوم النقدية لنقل البيانات الصادرة عبر المناطق، كما هو ملاحظ في صفحة تسعير Azure

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

تثبيت الشهادة

تثبيت الشهادة هو ممارسة يسمح فيها التطبيق فقط بقائمة محددة من المراجع المصدقة المقبولة (CAs) أو المفاتيح العامة أو بصمة الإبهام أو أي جزء من التسلسل الهرمي للشهادة.

يجب ألا يكون للتطبيقات تبعية ثابتة أو تثبيت على شهادة TLS الافتراضية لحرف البدل (*.azurewebsites.net). App Service هي نظام أساسي كخدمة (PaaS)، لذلك يمكن تدوير هذه الشهادة في أي وقت. إذا قامت الخدمة بتدوير شهادة TLS لأحرف البدل الافتراضية، فستقطع التطبيقات التي تم تثبيت الشهادة اتصالها بالتطبيقات التي تم ترميزها بشكل ثابت إلى مجموعة معينة من سمات الشهادة وتعطيلها. الدورية التي يتم تدوير الشهادة بها غير مضمونة أيضا لأن تكرار التدوير يمكن أن يتغير في أي وقت.

يجب ألا يكون للتطبيقات التي تعتمد على تثبيت الشهادة تبعية ثابتة على شهادة مدارة من App Service. يمكن تدوير الشهادات المدارة في App Service في أي وقت، مما يؤدي إلى مشاكل مشابهة للتطبيقات التي تعتمد على خصائص شهادة مستقرة. من أفضل الممارسات توفير شهادة TLS مخصصة للتطبيقات التي تعتمد على تثبيت الشهادة.

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

موارد الذاكرة

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

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

موارد وحدة المعالجة المركزية

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

لمزيد من المعلومات حول خيارات توسيع نطاق خدمة التطبيقات والتحجيم التلقائي، راجع توسيع نطاق تطبيق في Azure App Service.

موارد مأخذ التوصيل

السبب الشائع لاستنفاد اتصالات TCP الصادرة هو استخدام مكتبات العميل التي لا تعيد استخدام اتصالات TCP أو التي لا تستخدم بروتوكولا عالي المستوى مثل HTTP keep-alive.

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

طلبات HTTP Node.js والصادرة

عندما تعمل مع Node.js والعديد من طلبات HTTP الصادرة، من المهم التعامل مع HTTP على قيد الحياة. يمكنك استخدام الحزمة agentkeepalive npm لتسهيلها في التعليمات البرمجية الخاصة بك.

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

فيما يلي مثال على معالجة الاستجابة عند العمل مع أو الحزمة http https :

const request = https.request(options, function(response) {
    response.on('data', function() { /* do nothing */ });
});

إذا كنت تقوم بتشغيل تطبيق App Service الخاص بك على جهاز Linux يحتوي على ذاكرات أساسية متعددة، فمن أفضل الممارسات الأخرى استخدام PM2 لبدء عمليات Node.js متعددة لتشغيل التطبيق الخاص بك. يمكنك القيام بذلك عن طريق تحديد أمر بدء التشغيل إلى الحاوية الخاصة بك.

على سبيل المثال، استخدم هذا الأمر لبدء أربعة مثيلات:

pm2 start /home/site/wwwroot/app.js --no-daemon -i 4

النسخ الاحتياطي للتطبيق

تعمل النسخ الاحتياطية عادةً وفقاً لجدول زمني وتتطلب الوصول إلى التخزين (لإخراج الملفات الاحتياطية) وقواعد البيانات (لنسخ المحتويات وقراءتها ليتم تضمينها في النسخة الاحتياطية). نتيجة الفشل في الوصول إلى أي من هذه الموارد هي فشل النسخ الاحتياطي المتسق.

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

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

لمزيد من المعلومات حول النسخ الاحتياطية للتطبيق، راجع النسخ الاحتياطي للتطبيق واستعادته في Azure App Service.

تطبيقات Node.js

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

أجهزة إنترنت الأشياء

يمكنك تحسين بيئتك عند تشغيل أجهزة إنترنت الأشياء (IoT) المتصلة بخدمة التطبيقات.

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

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

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

هناك خيار آخر وهو استخدام موازن تحميل أمام تطبيقات الويب، مثل Azure Front Door أو Azure Traffic Manager، لضمان قابلية وصول عالية لتطبيقات الويب الخاصة بك. لمزيد من المعلومات، راجع التشغيل السريع: إنشاء مثيل Front Door لتطبيق ويب عمومي عالي التوفر أو التحكم في حركة مرور Azure App Service باستخدام Azure Traffic Manager.

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

للحصول على أفضل الممارسات القابلة للتنفيذ الخاصة بالموارد الخاصة بك، استخدم تشخيصات App Service:

1. انتقل إلى تطبيق الويب الخاص بك في مدخل Microsoft Azure.
2. افتح تشخيصات App Service عن طريق تحديد تشخيص المشكلات وحلها في الجزء الأيمن.
3. حدد لوحة أفضل الممارسات.
4. حدد أفضل الممارسات للتوفر والأداء أو أفضل الممارسات للتكوين الأمثل لعرض الحالة الحالية لتطبيقك فيما يتعلق بأفضل الممارسات هذه.

يمكنك أيضا استخدام هذا الارتباط لفتح تشخيصات App Service مباشرة لموردك: https://portal.azure.com/?websitesextension_ext=asd.featurePath%3Ddetectors%2FParentAvailabilityAndPerformance#@microsoft.onmicrosoft.com/resource/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Web/sites/{siteName}/troubleshoot.