مشاركة عبر

وظائف الخلفية

  • مقالة

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

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

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

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

تتضمن وظائف الخلفية عادةً واحدًا أو أكثر من أنواع الوظائف التالية:

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

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

يمكن بدء تشغيل وظائف الخلفية بعدة طرق مختلفة. تقع في إحدى الفئات التالية:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

بيئة الاستضافة

يمكنك استضافة تطبيق في الخلفية باستخدام مجموعة من خدمات النظام الأساسي المختلفة لـ Azure:

  • تطبيق ويب Azure وWebJobs. يمكنك استخدام WebJobs لتنفيذ مهام مخصصة بناءً على مجموعة من أنواع مختلفة من البرامج النصية أو البرامج القابلة للتنفيذ في سياق تطبيق الويب.
  • Azure Functions. يمكنك استخدام الدالات من أجل وظائف الخلفية التي لا تعمل لفترة طويلة. حالة استخدام أخرى هي ما إذا كان عبء حمل العمل الخاص بك مستضافًا بالفعل على خطة خدمة التطبيق وغير مستغل بشكل كافٍ.
  • أجهزة Azure الظاهرية. إذا كانت لديك خدمة Windows أو تريد استخدام برنامج جدولة مهام Windows، فمن الشائع أن تستضيف مهامك في الخلفية داخل جهاز ظاهري مخصص.
  • Azure Batch. فهي خدمة نظام أساسي تقوم بجدولة العمل كثيف الحوسبة للتشغيل على مجموعة مُدارة من الأجهزة الظاهرية. يمكنها قياس موارد الحساب تلقائيًا.
  • خدمة Azure Kubernetes (AKS). توفر خدمة Azure Kubernetes بيئة استضافة مُدارة لـ Kubernetes على Azure.
  • تطبيقات Azure Container. تمكّنك Azure Container Apps من إنشاء خدمات مصغرة دون خادم استناداً إلى الحاويات.

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

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

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

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

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

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

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

  • الأمان: يتم حماية WebJobs بواسطة بيانات اعتماد التوزيع لتطبيق الويب.
  • أنواع الملفات المدعومة: يمكنك تعريف WebJobs باستخدام البرامج النصية للأوامر (.cmd)، والملفات الدفعية (.bat)، والبرامج النصية PowerShell (.ps1)، والبرامج النصية Bash shell (.sh)، والبرامج النصية PHP (.php)، والبرامج النصية ل Python (.py)، ورمز JavaScript (.js)، والبرامج القابلة للتنفيذ (.exe، و، .jarوالمزيد).
  • النشر: يمكنك نشر البرامج النصية والملفات التنفيذية باستخدام مدخل Microsoft Azure، أو باستخدام Visual Studio، أو باستخدام Azure WebJobs SDK، أو عن طريق نسخها مباشرة إلى المواقع التالية:
    • بالنسبة للتنفيذ المشغل: site/wwwroot/app_data/jobs/triggered/{job name}
    • بالنسبة للتنفيذ المستمر: site/wwwroot/app_data/jobs/continuous/{job name}
  • التسجيل: يتم التعامل مع Console.Out (تم تحديدها) على أنها INFO. ويتم التعامل مع Console.Error على أنها ERROR. يمكنك الوصول إلى معلومات الرصد والتشخيص باستخدام مدخل Microsoft Azure. يمكنك تنزيل ملفات السجل مباشرةً من الموقع. يتم حفظها في المواقع التالية:
    • بالنسبة للتنفيذ المشغل: Vfs/data/jobs/triggered/jobName
    • بالنسبة للتنفيذ المستمر: Vfs/data/jobs/continuous/jobName
  • التكوين: يمكنك تكوين WebJobs باستخدام المدخل، وواجهة برمجة تطبيقات REST، وPowerShell. يمكنك استخدام ملف تكوين يسمى settings.job في الدليل الجذر نفسه مثل البرنامج النصي للمهمة لتوفير معلومات التكوين لوظيفة ما. على سبيل المثال:
    • { "stopping_wait_time": 60 }
    • { "is_singleton": true }

الاعتبارات

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

دالات Azure

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

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

الاعتبارات

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

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

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

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

Azure Virtual Machines

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

لمساعدتك في اختيار وقت استخدام الأجهزة الظاهرية، راجع مقارنة خدمات تطبيقات Azure، والخدمات السحابية، والأجهزة الظاهرية. للحصول على معلومات حول خيارات الأجهزة الظاهرية، راجع أحجام أجهزة Windows الظاهرية في Azure. لمزيد من المعلومات حول أنظمة التشغيل والصور المنشأة مسبقًا والمتوفرة للأجهزة الظاهرية، راجع Azure Virtual Machines Marketplace (سوق أجهزة Azure الظاهرية).

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

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

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

الاعتبارات

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

  • توفر استضافة مهام تطبيق في الخلفية في جهاز ظاهري منفصل من Azure المرونة ويسمح بالتحكم الدقيق في البدء والتنفيذ والجدولة وتخصيص الموارد. ومع ذلك، فإنه سيزيد من تكلفة وقت التشغيل إذا كان لا بد من توزيع جهاز ظاهري فقط لتشغيل مهام تطبيق في الخلفية.
  • لا توجد وسيلة لمراقبة المهام في مدخل Microsoft Azure ولا توجد إمكانية إعادة التشغيل التلقائي للمهام الفاشلة، على الرغم من أنه يمكنك مراقبة الحالة الأساسية للجهاز الظاهري وإدارته باستخدام Azure Resource Manager Cmdlets. مع ذلك، لا توجد مرافق للتحكم في العمليات ومؤشرات الترابط في عقد الحساب. عادةً ما يتطلب استخدام جهاز ظاهري جهدًا إضافيًا لتنفيذ آلية تجمع البيانات من تقرير عن حالة النظام في المهمة ومن نظام التشغيل في الجهاز الظاهري. أحد الحلول التي قد يكون مناسبًا هو استخدام حزمة إدارة مركز النظام لـ Azure.
  • قد تفكر في إنشاء فحوصات مراقبة يتم عرضها من خلال نقاط نهاية HTTP. يمكن أن تقوم التعليمة البرمجية لهذه الفحوصات بإجراء فحوصات صحية وجمع المعلومات والإحصائيات التشغيلية، أو جمع معلومات الخطأ وإعادتها إلى تطبيق الإدارة. لمزيد من المعلومات، راجع نمط مراقبة نقطة النهاية الصحية.

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

Azure Batch

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

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

الاعتبارات

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

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

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

Azure Kubernetes Service

تدير خدمة Azure Kubernetes (AKS) بيئة Kubernetes المستضافة، مما يجعل من السهل توزيع وإدارة التطبيقات المعبأة في حاويات.

يمكن أن تكون الحاويات مفيدة لتشغيل وظائف الخلفية. تشمل بعض المزايا ما يلي:

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

الاعتبارات

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

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

Azure Container Apps

تمكّنك Azure Container Apps من إنشاء خدمات مصغرة دون خادم استناداً إلى الحاويات. وتشمل الميزات المميزة لتطبيقات الحاويات ما يلي:

الاعتبارات

لا تتيح Azure Container Apps إمكانية الوصول المباشر إلى واجهات برمجة تطبيقات Kubernetes الأساسية. إذا كنت تحتاج إلى الوصول إلى واجهات برمجة تطبيقات Kubernetes ووحدة التحكم، فيجب عليك استخدام Azure Kubernetes Service. ومع ذلك، إذا كنت ترغب في إنشاء تطبيقات مماثلة لـ Kubernetes ولا تتطلب وصولاً مباشراً إلى جميع واجهات برمجة تطبيقات Kubernetes وإدارة نظام المجموعة، فإن Container Apps توفر تجربة مُدارة بشكل كامل بناءً على أفضل الممارسات. ولهذه الأسباب، قد تفضل العديد من الفِرق البدء في إنشاء خدمات مصغرة للحاويات باستخدام Azure Container Apps.

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

يمكنك البدء في إنشاء تطبيق الحاوية الأول باستخدام قوالب التشغيل السريع.

التقسيم

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

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

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

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

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

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

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

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

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

النزاعات

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

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

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

التنسيق

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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