مشاركة عبر

توصيات لتطوير وظائف الخلفية

  • مقالة

ينطبق على توصية قائمة التحقق من موثوقية Azure Well-Architected Framework هذه:

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

الأدلة ذات الصلة:أخطاء عابرة | الحفاظ على الذات

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

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

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

استراتيجيات التصميم الرئيسية

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

أنواع وظائف الخلفية

بعض الأمثلة على وظائف الخلفية هي:

  • وظائف كثيفة الاستخدام لوحدة CPU، مثل العمليات الحسابية أو تحليل النموذج الهيكلي.

  • المهام كثيفة الإدخال/الإخراج، مثل تشغيل سلسلة من معاملات التخزين أو ملفات الفهرسة.

  • وظائف دفعية، مثل تحديثات البيانات الليلية أو المعالجة المجدولة.

  • مهام سير العمل طويلة الأمد، مثل تنفيذ الطلب أو توفير الخدمات والأنظمة.

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

أزرار التشغيل

بدء مهام الخلفية باستخدام:

المشغلات المدفوعة بالحدث

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

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

  • تقوم واجهة المستخدم أو مهمة مختلفة بحفظ قيمة في التخزين أو تحديثها. تراقب مهمة الخلفية التخزين وتكتشف التغييرات. يقرأ البيانات ويستخدمها كمدخل لوظيفة الخلفية.

  • تقدم واجهة المستخدم أو مهمة مختلفة طلبا إلى نقطة نهاية، مثل HTTPS URI أو واجهة برمجة التطبيقات التي يتم عرضها كخدمة ويب. كجزء من الطلب، تقوم واجهة المستخدم أو الوظيفة بنقل البيانات التي تتطلبها مهمة الخلفية. تستدعي نقطة النهاية أو خدمة الويب مهمة تطبيق في الخلفية، والتي تستخدم البيانات كمدخلات لها.

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

مشغلات مدفوعة بالجدول

يقوم المؤقت بتشغيل استدعاء يستند إلى جدول زمني يبدأ مهمة الخلفية. تتضمن أمثلة المشغلات المستندة إلى الجدول الزمني ما يلي:

  • يستدعي المؤقت الذي يعمل محليا داخل التطبيق أو كجزء من نظام تشغيل التطبيق مهمة خلفية بانتظام.

  • يرسل المؤقت الذي يعمل في تطبيق مختلف، مثل Azure Logic Apps، طلبا بانتظام إلى واجهة برمجة تطبيقات أو خدمة ويب. تستدعي واجهة برمجة التطبيقات أو خدمة الويب مهمة تطبيق في الخلفية.

  • تبدأ عملية أو تطبيق منفصل مؤقت يستدعي مهمة الخلفية بعد تأخير زمني أو في وقت محدد.

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

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

  • إذا تم تغيير حجم مثيل الحساب الذي يقوم بتشغيل المجدول، مثل جهاز ظاهري (VM) يستخدم مهام Windows المجدولة، فأنت تقوم بتشغيل مثيلات متعددة من المجدول. يمكن أن تبدأ مثيلات متعددة من المجدول مثيلات متعددة للمهمة. لمزيد من المعلومات، راجع ماذا يعني التكرار في أنظمة البرامج؟

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

إرجاع النتائج

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

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

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

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

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

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

وظائف خلفية القسم

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

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

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

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

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

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

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

  • التكلفة: إذا أضفت مثيلات حساب لتشغيل مهام الخلفية، فستزيد تكاليف الاستضافة. ضع في اعتبارك بعناية المفاضلة بين المزيد من السعة والتكاليف الإضافية.

لمزيد من المعلومات، راجع نمط انتخاب القائد ونمطالمستهلكين المتنافسين.

النزاعات

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

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

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

التنسيق

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

قد يكون من التحدي تنسيق مهام وخطوات متعددة، ولكن هناك ثلاثة أنماط شائعة لتوجيه الحل الخاص بك:

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

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

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

اعتبارات المرونة

إنشاء مهام خلفية مرنة لتوفير خدمات موثوقة للتطبيق. عند تخطيط مهام الخلفية وتصميمها، ضع في اعتبارك النقاط التالية:

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

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

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

الرسائل

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

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

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

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

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

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

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

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

اعتبارات التحجيم والأداء

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

  • يمكن لأجهزة Azure الظاهرية وميزة تطبيقات الويب في Azure App Service استضافة عمليات التوزيع. وهي تدعم التحجيم التلقائي، سواء التحجيم أو التحجيم. يتم تحديد التحجيم التلقائي حسب الطلب والتحميل أو جدول زمني محدد مسبقا. استخدم التحجيم التلقائي للمساعدة في التأكد من أن التطبيق لديه قدرات أداء كافية مع تقليل تكاليف وقت التشغيل.

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

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

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

  • بشكل افتراضي، يتوسع WebJob مع مثيل Web Apps المقترن به. ومع ذلك، إذا كنت تريد تشغيل WebJob كمثيل واحد فقط، يمكنك إنشاء ملف Settings.job يحتوي على بيانات { "is_singleton": true }JSON . يفرض هذا الأسلوب على Azure تشغيل مثيل واحد فقط من WebJob، حتى إذا كانت هناك مثيلات متعددة لتطبيق الويب المقترن. هذه التقنية مفيدة للوظائف المجدولة التي يجب أن تعمل كمثيل واحد فقط.

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

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

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

تسهيل Azure

تصف الأقسام التالية خدمات Azure التي يمكنك استخدامها لاستضافة وظائف الخلفية وتشغيلها وتكوينها وإدارتها.

بيئات المضيف

هناك العديد من خدمات النظام الأساسي ل Azure التي يمكنها استضافة مهام الخلفية:

  • تطبيقات الويب وWebJobs: استخدم ميزة WebJobs لخدمة التطبيقات لتشغيل مهام مخصصة تستند إلى برامج نصية أو برامج مختلفة يمكنك تشغيلها في تطبيق ويب.

  • Azure Functions: استخدم تطبيقات الوظائف لوظائف الخلفية التي لا تعمل لفترة طويلة. يمكنك أيضا استخدام تطبيقات الوظائف إذا كنت تستضيف حمل العمل الخاص بك على خطة App Service غير مستغلة بشكل كبير.

  • الأجهزة الظاهرية: إذا كانت لديك خدمة Windows أو تريد استخدام Windows Task Scheduler، فاستضيف مهام الخلفية في جهاز ظاهري مخصص.

  • Azure Batch: Batch هي خدمة نظام أساسي يمكنك استخدامها لجدولة العمل كثيف الحوسبة للتشغيل على مجموعة مدارة من الأجهزة الظاهرية. يمكنها قياس موارد الحساب تلقائيًا.

  • خدمة Azure Kubernetes (AKS): توفر AKS بيئة استضافة مدارة ل Kubernetes على Azure.

  • Azure Container Apps: باستخدام Container Apps، يمكنك إنشاء خدمات مصغرة بلا خادم تستند إلى حاويات.

توفر الأقسام التالية اعتبارات لكل خيار من هذه الخيارات لمساعدتك في اختيار الخيار الأفضل لك.

تطبيقات الويب وWebJobs

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

عندما تقوم بتكوين WebJob:

  • إذا كنت تريد أن تستجيب الوظيفة لمشغل يستند إلى الحدث، فقم بتكوينه للتشغيل باستمرار. يتم تخزين البرنامج النصي أو البرنامج في المجلد المسمى site/wwwroot/app_data/jobs/continuous.

  • إذا كنت تريد أن تستجيب الوظيفة لمشغل يستند إلى جدول زمني، فقم بتكوينه إلى تشغيل على جدول زمني. يتم تخزين البرنامج النصي أو البرنامج في المجلد باسم site/wwwroot/app_data/jobs/triggered.

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

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

يتمتع WebJobs بالخصائص التالية:

  • الأمان: توفر بيانات اعتماد النشر لتطبيق الويب الحماية ل WebJobs.

  • أنواع الملفات المدعومة: تعريف WebJobs باستخدام البرامج النصية للأوامر (.cmd) وملفات الدفعات (.bat) والبرامج النصية PowerShell (.ps1) والبرامج النصية Bash shell (.sh) والبرامج النصية PHP (.php) والبرامج النصية Python (.py) ورمز JavaScript (.js) والبرامج القابلة للتنفيذ (.exe و.jar).

  • التوزيع: يمكنك نشر البرامج النصية والملفات التنفيذية باستخدام مدخل Microsoft Azure أو Visual Studio أو WebJobs SDK، أو يمكنك نسخها مباشرة إلى المواقع التالية:

    • للنشر المشغل: site/wwwroot/app_data/jobs/triggered/<job name>

    • للتوزيع المستمر: site/wwwroot/app_data/jobs/continuous/<job name>

  • ملفات السجل: Console.Out يتم التعامل معها، أو وضع علامة عليها، على أنها INFO. Console.Error يتم التعامل معه على أنه ERROR. استخدم المدخل للوصول إلى معلومات المراقبة والتشخيص. قم بتنزيل ملفات السجل مباشرة من موقع الويب. يتم حفظ ملفات السجل في المواقع التالية:

    • للنشر المشغل: Vfs/data/jobs/triggered/<job name>

    • للتوزيع المستمر: Vfs/data/jobs/continuous/<job name>

  • التكوين: تكوين WebJobs باستخدام المدخل وواجهة برمجة تطبيقات REST وPowerShell. استخدم ملف تكوين يسمى settings.job، الموجود في نفس الدليل الجذر مثل البرنامج النصي WebJob، لتوفير معلومات التكوين ل WebJob. على سبيل المثال:

    • { "stopping_wait_time": 60 }

    • { "is_singleton": true }

تطبيقات الويب واعتبارات WebJobs

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

  • لتقليل تأثير WebJobs على أداء تطبيق الويب، قم بإنشاء مثيل تطبيق ويب فارغ في خطة App Service جديدة لاستضافة WebJobs طويل الأمد أو كثيف الموارد.

دالات Azure

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

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

اعتبارات Azure Functions

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

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

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

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

الأجهزة الظاهرية

يمكنك تنفيذ مهام الخلفية بحيث لا يتم توزيعها في Web Apps. على سبيل المثال، يمكنك تنفيذ المهام باستخدام خدمات Windows أو أدوات مساعدة تابعة لجهة خارجية أو برامج قابلة للتنفيذ. يمكنك أيضا استخدام البرامج المكتوبة لبيئة وقت التشغيل التي تختلف عن البيئة التي تستضيف التطبيق. على سبيل المثال، قد تستخدم برنامج Unix أو Linux الذي تريد تشغيله من تطبيق Windows أو .NET. اختر من بين العديد من أنظمة التشغيل لجهاز Azure الظاهري، وقم بتشغيل خدمتك أو قابل للتنفيذ على هذا الجهاز الظاهري.

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

لبدء مهمة الخلفية في جهاز ظاهري منفصل، يمكنك:

  • أرسل طلبا إلى نقطة نهاية تعرضها المهمة لتشغيل المهمة عند الطلب مباشرة من التطبيق الخاص بك. ينقل الطلب البيانات التي تتطلبها المهمة. تستدعي نقطة النهاية المهمة.

  • استخدم مجدول أو مؤقت من نظام التشغيل الذي اخترته لتكوين المهمة للتشغيل حسب جدول زمني. على سبيل المثال، في Windows، يمكنك استخدام Windows Task Scheduler لتشغيل البرامج النصية والمهام. إذا كان لديك SQL Server مثبتة على الجهاز الظاهري، فاستخدم SQL Server Agent لتشغيل البرامج النصية والمهام.

  • استخدم Logic Apps لبدء المهمة عن طريق إضافة رسالة إلى قائمة انتظار تراقبها المهمة أو عن طريق إرسال طلب إلى واجهة برمجة تطبيقات تعرضها المهمة.

لمزيد من المعلومات حول كيفية بدء مهام الخلفية، راجع قسم المشغلات السابق.

اعتبارات الأجهزة الظاهرية

ضع في اعتبارك النقاط التالية عند توزيع مهام الخلفية في جهاز Azure الظاهري:

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

  • لا توجد منشأة لمراقبة المهام في المدخل ولا توجد إمكانية إعادة تشغيل تلقائية للمهام الفاشلة. ولكن يمكنك استخدام أوامر cmdlets Resource Manager Azure لمراقبة حالة الجهاز الظاهري وإدارته. لا توجد مرافق للتحكم في العمليات وخيوط الترابط في عقد الحوسبة. عادة، إذا كنت تستخدم جهازا ظاهريا، يجب عليك تنفيذ آلية تجمع البيانات من الأجهزة في المهمة، وأيضا من نظام التشغيل في الجهاز الظاهري. يمكنك استخدام System Center Management Pack ل Azure لهذا الغرض.

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

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

دُفعة

ضع في اعتبارك Batch إذا كنت بحاجة إلى تشغيل أحمال عمل حوسبة عالية الأداء (HPC) كبيرة ومتوازية عبر عشرات أو مئات أو آلاف الأجهزة الظاهرية.

استخدم Batch لإعداد الأجهزة الظاهرية وتعيين المهام إلى الأجهزة الظاهرية وتشغيل المهام ومراقبة التقدم وتوسيع نطاق الأجهزة الظاهرية تلقائيا استجابة لحمل العمل. يوفر Batch أيضا جدولة الوظائف ويدعم أجهزة Linux وWindows الظاهرية.

اعتبارات الدفعة

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

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

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

Azure Kubernetes Service

استخدم AKS لإدارة بيئة Kubernetes المستضافة حتى تتمكن من نشر التطبيقات الحاوية وإدارتها بسهولة.

الحاويات مفيدة لتشغيل مهام الخلفية. وتشمل بعض مزايا هذه الخطوة ما يلي:

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

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

  • يمكنك بدء تشغيل الحاويات وإيقافها حسب الحاجة.

  • باستخدام Azure Container Registry، يمكنك تسجيل حاوياتك داخل حدود Azure لتوفير مزايا الأمان والخصوصية والتقارب.

اعتبارات AKS

يتطلب AKS فهم كيفية استخدام منسق الحاوية.

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

التطبيقات المتعلقة بالحاوية

باستخدام تطبيقات الحاوية، يمكنك إنشاء خدمات مصغرة بلا خادم تستند إلى حاويات. تطبيقات الحاوية:

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

  • يتم تشغيلها بواسطة Kubernetes والتقنيات مفتوحة المصدر، مثل DaprوKubernetes Event-driven Autoscaling (KEDA)و Envoy.

  • يدعم التطبيقات والخدمات المصغرة بأسلوب Kubernetes مع ميزات مثل اكتشاف الخدمة وتقسيم نسبة استخدام الشبكة.

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

  • يدعم العمليات طويلة الأمد ويمكنه تشغيل مهام الخلفية.

اعتبارات تطبيقات الحاوية

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

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

قائمة التحقق من الموثوقية

راجع المجموعة الكاملة من التوصيات.

قائمة التحقق من الموثوقية