← أحدث الأبحاث
💻 علوم الحاسوب

Intelligent Runtime Adaptation of Cloud-Native Microservices through Design-Principle-Aware Resource Management

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

المؤلفون الأصليون: Syed Fakhar Abbas, Musharif Ahmed, Nabil Almashfi, Asim Bakhshi, Sajjad Aamir, Mamoona Humayun, Maram Fahaad Almufareh

نُشر 2026-10-13
📖 4 دقيقة قراءة☕ قراءة في استراحة قهوة

المؤلفون الأصليون: Syed Fakhar Abbas, Musharif Ahmed, Nabil Almashfi, Asim Bakhshi, Sajjad Aamir, Mamoona Humayun, Maram Fahaad Almufareh

البحث الأصلي مرخَّص بموجب CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). ✨ هذا شرح مولَّده بالذكاء الاصطناعي للبحث أدناه. لم يكتبه المؤلفون ولم يصادقوا عليه. وللتحقق من الدقة التقنية، يرجى الرجوع إلى البحث الأصلي. اقرأ إخلاء المسؤولية الكامل

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

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

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

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

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

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

غارق في أبحاث مجالك؟

تصلك نشرة يومية بأحدث الأبحاث المطابقة لكلماتك البحثية المفتاحية — مع ملخصات تقنية، بلغتك.

جرّب Digest →