نمط تسوية الحمل القائم على قائمة الانتظار
استخدم قائمة انتظار تعمل كمخزن مؤقت بين مهمة وخدمة تستدعيها لتسهيل الأحمال الثقيلة المتقطعة التي يمكن أن تتسبب في فشل الخدمة أو انتهاء مهلة المهمة. يمكن أن يساعد هذا في تقليل تأثير الذروات في الطلب على التوفر والاستجابة لكل من المهمة والخدمة.
السياق والمشكلة
تتضمن العديد من الحلول في السحابة تشغيل المهام التي تستدعي الخدمات. في هذه البيئة، إذا تعرضت الخدمة لأحمال ثقيلة متقطعة، يمكن أن تسبب مشكلات في الأداء أو الموثوقية.
قد تكون الخدمة جزءاً من نفس الحل مثل المهام التي تستخدمها، أو قد تكون خدمة تابعة لجهة خارجية توفر الوصول إلى الموارد المستخدمة بشكل متكرر مثل ذاكرة التخزين المؤقت أو خدمة التخزين. إذا تم استخدام نفس الخدمة من قبل عدد من المهام التي تعمل بشكل متزامن، فقد يكون من الصعب التنبؤ بحجم الطلبات إلى الخدمة في أي وقت.
قد تشهد الخدمة ذروات في الطلب تتسبب في تحميلها الزائد وتكون غير قادرة على الاستجابة للطلبات في الوقت المناسب. يمكن أن يؤدي إغراق الخدمة بعدد كبير من الطلبات المتزامنة أيضًا إلى فشل الخدمة إذا كانت غير قادرة على التعامل مع النزاع الذي تسببه هذه الطلبات.
حل
إعادة بناء التعليمات البرمجية للحل وتقديم قائمة انتظار بين المهمة والخدمة. يتم تشغيل المهمة والخدمة بشكل غير متزامن. تنشر المهمة رسالة تحتوي على البيانات المطلوبة من قبل الخدمة إلى قائمة انتظار. تعمل قائمة الانتظار كمخزن مؤقت، وتخزين الرسالة حتى يتم استردادها بواسطة الخدمة. تسترد الخدمة الرسائل من قائمة الانتظار وتعالجها. يمكن تمرير الطلبات من عدد من المهام، والتي يمكن إنشاؤها بمعدل متغير للغاية، إلى الخدمة من خلال نفس قائمة انتظار الرسالة. يوضح هذا الشكل استخدام قائمة انتظار لتسوية الحمل على الخدمة.
تقوم قائمة الانتظار بفصل المهام عن الخدمة، ويمكن للخدمة التعامل مع الرسائل بوتيرتها الخاصة بغض النظر عن حجم الطلبات من المهام المتزامنة. بالإضافة إلى ذلك، لا يوجد تأخير لمهمة إذا لم تكن الخدمة متوفرة في الوقت الذي تنشر فيه رسالة إلى قائمة الانتظار.
يوفر هذا النمط الفوائد التالية:
يمكن أن يساعد في زيادة التوفر إلى أقصى حد لأن التأخيرات الناشئة في الخدمات لن يكون لها تأثير فوري ومباشر على التطبيق، والذي يمكن أن يستمر في نشر الرسائل إلى قائمة الانتظار حتى عندما تكون الخدمة غير متوفرة أو لا تعالج الرسائل حالياً.
يمكن أن يساعد على زيادة قابلية التوسع إلى أقصى حد لأنه يمكن تنوع كل من عدد قوائم الانتظار وعدد الخدمات لتلبية الطلب.
يمكن أن يساعد في التحكم في التكاليف لأن عدد مثيلات الخدمة المنشورة يجب أن يكون كافياً فقط لتلبية متوسط الحمل بدلاً من ذروة الحمل.
تنفذ بعض الخدمات التقييد عندما يصل الطلب إلى حد قد يفشل النظام بعده. يمكن أن يقلل التقييد من الوظائف المتاحة. يمكنك تنفيذ تسوية التحميل باستخدام هذه الخدمات لضمان عدم الوصول إلى هذا الحد.
المسائل والاعتبارات
راع النقاط التالية عند تحديد كيفية تنفيذ هذا النمط:
- من الضروري تنفيذ منطق التطبيق الذي يتحكم في المعدل الذي تتعامل به الخدمات مع الرسائل لتجنب إثقال المورد المستهدف. تجنب تمرير الزيادات في الطلب إلى المرحلة التالية من النظام. اختبار النظام قيد التحميل للتأكد من أنه يوفر التسوية المطلوبة، وضبط عدد الطوابير وعدد مرات الخدمة التي تتعامل مع الرسائل لتحقيق ذلك.
- قوائم انتظار الرسائل هي آلية اتصال أحادية الاتجاه. إذا كانت المهمة تتوقع رداً من خدمة، فقد يكون من الضروري تنفيذ آلية يمكن للخدمة استخدامها لإرسال استجابة. لمزيد من المعلومات، راجع Asynchronous Messaging Primer .
- كن حذرا إذا قمت بتطبيق التحجيم التلقائي على الخدمات التي تستمع للطلبات في قائمة الانتظار. يمكن أن يؤدي هذا إلى زيادة الخلاف على أي موارد تشاركها هذه الخدمات ويقلل من فعالية استخدام قائمة الانتظار لتسوية الحمل.
- اعتمادا على تحميل الخدمة، يمكنك أن تواجه موقفا تتخلف فيه بشكل فعال دائما، حيث يقوم النظام دائما بوضع طلبات في قائمة الانتظار أكثر مما تعالجه. يجب مراعاة تغير نسبة استخدام الشبكة الواردة إلى تطبيقك
- يمكن أن يفقد النمط المعلومات استنادا إلى استمرار قائمة الانتظار. إذا تعطل قائمة الانتظار أو أسقط المعلومات (بسبب حدود النظام)، فهناك احتمال ألا يكون لديك تسليم مضمون. يجب أخذ سلوك حدود قائمة الانتظار والنظام في الاعتبار بناء على احتياجات الحل الخاص بك.
موعد استخدام النمط
هذا النمط مفيد لأي تطبيق يستخدم الخدمات التي تخضع للتحميل الزائد.
ومع ذلك، لا يكون هذا النمط مفيداً إذا كان التطبيق يتوقع استجابة من الخدمة بأقل زمن انتقال.
تصميم حمل العمل
يجب على المهندس المعماري تقييم كيفية استخدام نمط تسوية التحميل المستند إلى قائمة الانتظار في تصميم حمل العمل الخاص بهم لمعالجة الأهداف والمبادئ التي تغطيها ركائز Azure Well-Architected Framework. على سبيل المثال:
| الركيزة | كيف يدعم هذا النمط أهداف الركيزة |
|---|---|
| تساعد قرارات تصميم الموثوقية حمل العمل الخاص بك على الصمود في وجه الخلل وضمان استرداده إلى حالة تعمل بشكل كامل بعد حدوث فشل. | يمكن أن يوفر النهج الموضح في هذا النمط المرونة في مواجهة الارتفاع المفاجئ في الطلب من خلال فصل وصول المهام عن معالجتها. كما يمكن أن تعزل الأعطال في معالجة قائمة الانتظار بحيث لا تؤثر على المدخول. - RE:06 Scaling - وظائف الخلفية RE:07 |
| يركز تحسين التكلفة على الحفاظ على عائد حمل العمل على الاستثمار وتحسينه. | نظرا لأن معالجة التحميل منفصلة عن الطلب أو كمية المهام، يمكنك استخدام هذا الأسلوب لتقليل الحاجة إلى الإفراط في توفير الموارد للتعامل مع ذروة الحمل. - تكاليف التحجيم ل CO:12 |
| تساعد كفاءة الأداء حمل العمل الخاص بك على تلبية الطلبات بكفاءة من خلال التحسينات في التحجيم والبيانات والرمز. | يتيح هذا الأسلوب التصميم المتعمد على أداء معدل النقل لأن كمية الطلبات لا تحتاج إلى الارتباط بالمعدل الذي تتم معالجتها به. - PE:05 التحجيم والتقسيم |
كما هو الحال مع أي قرار تصميم، ضع في اعتبارك أي مفاضلات ضد أهداف الركائز الأخرى التي يمكن إدخالها مع هذا النمط.
مثال
يكتب تطبيق الويب البيانات إلى مخزن بيانات خارجي. إذا تم تشغيل عدد كبير من مثيلات تطبيق الويب بشكل متزامن، فقد لا يتمكن مخزن البيانات من الاستجابة للطلبات بسرعة كافية، مما يتسبب في انتهاء مهلة الطلبات أو تقييدها أو فشلها بطريقة أخرى. يوضح الرسم التخطيطي التالي مخزن بيانات يغمره عدد كبير من الطلبات المتزامنة من مثيلات التطبيق.
لحل هذه المشكلة، يمكنك استخدام قائمة انتظار لتسوية الحمل بين مثيلات التطبيق ومخزن البيانات. يقرأ تطبيق Azure Functions الرسائل من قائمة الانتظار وينفذ طلبات القراءة/الكتابة إلى مخزن البيانات. يمكن لمنطق التطبيق في تطبيق الوظيفة التحكم في المعدل الذي يمرر به الطلبات إلى مخزن البيانات، لمنع إغراق المخزن. (وإلا فإن تطبيق الوظائف سيعيد تقديم نفس المشكلة في النهاية الخلفية.)
الخطوات التالية
قد تكون الإرشادات التالية مناسبة أيضاً عند تنفيذ هذا النمط:
الدليل التمهيدي للرسائل غير المتزامنة. قوائم انتظار الرسائل غير متزامنة بطبيعتها. قد يكون من الضروري إعادة تصميم منطق التطبيق في مهمة إذا تم تكييفه من الاتصال مباشرة بخدمة إلى استخدام قائمة انتظار الرسائل. وبالمثل، قد يكون من الضروري إعادة بناء التعليمات البرمجية لخدمة لقبول الطلبات من قائمة انتظار الرسائل. بدلاً من ذلك، قد يكون من الممكن تنفيذ خدمة وكيل، كما هو موضح في المثال.
الاختيار بين خدمات مراسلة Azure. معلومات حول اختيار آلية المراسلة ووضع قائمة الانتظار في تطبيقات Azure.
الاتصال غير المتزامن المستند إلى الرسائل.
الموارد ذات الصلة
- نمط بنية Web-Queue-Worker. الويب والعامل كلاهما عديمي الحالة. يمكن تخزين حالة جلسة العمل في ذاكرة تخزين مؤقت تم توزيعها. يتم إجراء أي عمل طويل الأمد بشكل غير متزامن بواسطة العامل. يمكن تشغيل العامل من خلال الرسائل الموجودة في قائمة الانتظار، أو تشغيله على جدول زمني لمعالجة دفعة من الملفات.
قد تكون الأنماط الموضحة أدناه مناسبة أيضًا عند تنفيذ هذا النمط:
نمط المستهلكين المنافسين. قد يكون من الممكن تشغيل مثيلات متعددة من الخدمة، كل منها يعمل كمستهلك رسالة من قائمة انتظار تسوية التحميل. يمكنك استخدام هذا الأسلوب لضبط معدل تلقي الرسائل وتم تمريرها إلى خدمة.
نمط التقييد. إحدى الطرق البسيطة لتنفيذ التقييد باستخدام خدمة هي استخدام تسوية التحميل المستندة إلى قائمة الانتظار وتوجيه جميع الطلبات إلى خدمة من خلال قائمة انتظار الرسائل. يمكن للخدمة معالجة الطلبات بمعدل يضمن عدم استنفاد الموارد التي تتطلبها الخدمة، وتقليل مقدار الخلاف الذي يمكن أن يحدث.