مرحبا ، habrozhiteli!
قررنا مشاركة ترجمة الفصل "أنظمة قائمة على قوائم انتظار المهام" من الحداثة القادمة "الأنظمة الموزعة". أنماط التصميم "(موجودة بالفعل في دار الطباعة).
أبسط أشكال معالجة الدُفعات هي قائمة انتظار المهام. في نظام به قائمة انتظار مهمة ، هناك مجموعة من المهام التي يجب إكمالها. كل مهمة مستقلة تمامًا عن المهام الأخرى ويمكن معالجتها دون أي تفاعل معهم. في الحالة العامة ، يكون الهدف من نظام مع قائمة انتظار مهمة هو التأكد من اكتمال كل مرحلة من مراحل العمل خلال فترة زمنية معينة. يزيد عدد مهام سير العمل أو ينقص وفقًا للتغيير في الحمل. يتم عرض مخطط قائمة انتظار المهام العامة في الشكل. 10.1.
نظام يعتمد على قائمة انتظار مهمة معممة
يمثل خط المهام مثالاً مثاليًا يوضح القدرة الكاملة لأنماط تصميم النظام الموزعة. لا يعتمد معظم منطق قائمة انتظار المهام على نوع العمل المنجز. في كثير من الحالات ، ينطبق الشيء نفسه على تسليم المهام نفسها.
دعونا نوضح هذا البيان باستخدام قائمة انتظار المهام الموضحة في الشكل. 10.1. بعد النظر إليها مرة أخرى ، حدد الوظائف التي يمكن توفيرها بواسطة مجموعة مشتركة من الحاويات. يصبح من الواضح أن معظم تنفيذ قائمة انتظار حاوية في حاوية يمكن استخدامها من قبل مجموعة واسعة من المستخدمين.
تتطلب قائمة انتظار المهام المستندة إلى الحاوية مطابقة الواجهات بين حاويات المكتبات والحاويات بمنطق المستخدم. داخل قائمة انتظار المهام الحاوية ، يتم تمييز واجهتين: واجهة الحاوية المصدر ، والتي توفر مجموعة من المهام التي تتطلب معالجة ، وواجهة حاوية التنفيذ ، التي تعرف كيفية التعامل معها.
واجهة حاوية المصدر
أي قائمة انتظار مهمة تعمل على أساس مجموعة من المهام التي تتطلب معالجة. بناءً على التطبيق المحدد الذي تم تنفيذه على أساس قائمة انتظار المهام ، هناك العديد من مصادر المهام التي تقع فيها. ولكن بعد تلقي مجموعة من المهام ، يكون نظام تشغيل قائمة الانتظار بسيطًا للغاية. لذلك ، يمكننا فصل منطق التطبيق الخاص بمصدر المهمة عن المخطط العام لمعالجة قائمة انتظار المهام. إذ تشير إلى أنماط مجموعات الحاويات التي تمت مناقشتها سابقًا ، يمكنك هنا رؤية تنفيذ نموذج السفير. حاوية قائمة انتظار المهام المعممة هي حاوية التطبيق الرئيسية ، وحاوية المصدر الخاصة بالتطبيق عبارة عن طلبات بث السفير من حاوية مرسل قائمة الانتظار إلى منفذي المهام المعينين. تظهر هذه المجموعة من الحاويات في الشكل. 10.2.
بالمناسبة ، على الرغم من أن سفير الحاوية خاص بالتطبيق (وهو أمر واضح) ، هناك أيضًا عدد من التطبيقات المعممة لواجهة برمجة التطبيقات لمصدر المهمة. على سبيل المثال ، يمكن أن يكون المصدر عبارة عن قائمة بالصور الموجودة في بعض التخزين السحابي ، أو مجموعة من الملفات على محرك أقراص الشبكة ، أو حتى قائمة انتظار في الأنظمة التي تعمل وفق مبدأ "النشر / الاشتراك" ، مثل Kafka أو Redis. على الرغم من حقيقة أنه يمكن للمستخدمين اختيار سفراء الحاوية الأكثر ملاءمة لمهمتهم ، يجب عليهم استخدام "مكتبة" معممة لتنفيذ الحاوية نفسها. سيؤدي هذا إلى تقليل مقدار العمل وزيادة إعادة استخدام الرمز.
قائمة انتظار المهام API بالنظر إلى آلية التفاعل بين قائمة انتظار المهام وسفينة الحاوية الخاصة بالتطبيق ، ينبغي لنا صياغة تعريف رسمي للواجهة بين الحاويتين. هناك العديد من البروتوكولات المختلفة ، ولكن من السهل تنفيذ واجهات برمجة التطبيقات HTTP RESTful وهي المعيار الفعلي لمثل هذه الواجهات. قائمة انتظار المهام تتوقع عناوين URL التالية ليتم تنفيذها في الحاوية بعد:
لماذا تضيف v1 إلى تعريف API الخاص بك ، تسأل؟ هل سيكون هناك نسخة ثانية من الواجهة؟ يبدو غير منطقي ، لكن تكلفة إصدار واجهة برمجة التطبيقات عند تعريفها مبدئيًا هي الحد الأدنى. إجراء إعادة بيع المباني المناسبة لاحقًا سيكون مكلفًا للغاية. اجعل من القاعدة إضافة إصدارات إلى جميع واجهات برمجة التطبيقات ، حتى لو لم تكن متأكدًا مما إذا كانت ستتغير على الإطلاق. الله ينقذ الآمن.
عنوان URL / العناصر / إرجاع قائمة بجميع المهام:
{ kind: ItemList, apiVersion: v1, items: [ "item-1", "item-2", …. ] }
يوفر عنوان URL / items / <item-name> معلومات مفصلة حول مهمة محددة:
{ kind: Item, apiVersion: v1, data: { "some": "json", "object": "here", } }
يرجى ملاحظة أن واجهة برمجة التطبيقات لا توفر أي آليات لإصلاح حقيقة المهمة. يمكن للمرء تطوير واجهة برمجة تطبيقات أكثر تعقيدًا وتحويل معظم التنفيذ إلى سفير حاوية. تذكر ، مع ذلك ، أن هدفنا هو تركيز أكبر قدر ممكن من التنفيذ الشامل داخل مدير قائمة انتظار المهام. في هذا الصدد ، يجب أن يقوم مدير قائمة انتظار المهام بمراقبة المهام التي تمت معالجتها بالفعل والتي لم تتم معالجتها بعد.
من واجهة برمجة التطبيقات هذه ، نحصل على معلومات حول مهمة محددة ، ثم نمرر قيمة حقل item.data لواجهة حاوية المنفذ.
تنفيذ واجهة الحاوية
بمجرد أن يتلقى مدير الصف المهمة التالية ، يجب عليه أن يعهد بها إلى بعض المنفذ. هذه هي الواجهة الثانية في قائمة انتظار المهام المعممة. الحاوية نفسها وواجهتها تختلف قليلاً عن واجهة الحاوية المصدر لعدة أسباب. أولاً ، هو واجهة برمجة تطبيقات لمرة واحدة. يبدأ عمل المنفذ بتنفيذ مكالمة واحدة ، وخلال دورة حياة الحاوية ، لا يتم إجراء المزيد من المكالمات. ثانياً ، الحاوية المنفذة ومدير قائمة انتظار المهام في مجموعات حاوية مختلفة. يتم تشغيل منفذ الحاوية من خلال API حاوية أوركسترا في مجموعته الخاصة. هذا يعني أن مدير قائمة انتظار المهام يجب أن يقوم بإجراء مكالمة عن بعد لبدء تشغيل حاوية التنفيذ. هذا يعني أيضًا أن عليك أن تكون أكثر حذراً بشأن مشكلات الأمان ، حيث يمكن لمستخدم ضار في المجموعة تحميله بعمل غير ضروري.
في الحاوية المصدر ، استخدمنا مكالمة HTTP بسيطة لإرسال قائمة المهام إلى مدير المهام. تم ذلك على افتراض أن مكالمة واجهة برمجة التطبيقات هذه يجب إجرائها عدة مرات ، ولم تتم مراعاة مشكلات الأمان ، حيث أن كل شيء كان يعمل في إطار المضيف المحلي. يجب استدعاء واجهة برمجة تطبيقات الحاوية مرة واحدة فقط ومن المهم التأكد من أن المستخدمين الآخرين للنظام لا يمكنهم إضافة عمل إلى المسؤولين التنفيذيين ، حتى عن طريق الصدفة أو عن طريق نية خبيثة. لذلك ، بالنسبة للحاوية المنفذة ، سوف نستخدم ملف API. عند الإنشاء ، سنقوم بتمرير الحاوية متغير بيئة يسمى WORK_ITEM_FILE ، حيث تشير القيمة إلى ملف في نظام الملفات الداخلي للحاوية. يحتوي هذا الملف على بيانات حول المهمة المطلوب إكمالها. يمكن تطبيق هذا النوع من API ، كما هو موضح أدناه ، بواسطة كائن ConfigMap Kubernetes. يمكن تركيبه في مجموعة من الحاويات كملف (الشكل 10.3).
آلية تطبيق ملف API هذه أسهل في التنفيذ باستخدام الحاوية. غالبًا ما يكون المنفذ في قائمة انتظار المهام عبارة عن برنامج نصي بسيط يصل إلى العديد من الأدوات. من غير العملي رفع خادم ويب بأكمله لإدارة المهام - وهذا يؤدي إلى تعقيد البنية. كما هو الحال بالنسبة لمصادر المهام ، فإن معظم منفذي الحاويات سيكونون حاويات متخصصة لمهام معينة ، ولكن هناك أيضًا منفذي معمم قابلون للتطبيق لحل عدة مهام مختلفة.
اطلع على مثال الحاوية المنفذة التي تقوم بتنزيل ملف من التخزين السحابي ، وتقوم بتشغيل البرنامج النصي shell ، ثم تنسخ النتيجة مرة أخرى إلى التخزين السحابي. يمكن أن تكون مثل هذه الحاوية عامةً ، ولكن يمكن تمرير سيناريو محدد لها كمعلمة. وبالتالي ، يمكن إعادة استخدام معظم رمز معالجة الملف بواسطة العديد من قوائم انتظار المستخدمين / المهام. يحتاج المستخدم النهائي فقط إلى توفير برنامج نصي يحتوي على تفاصيل معالجة الملف.
بنية أساسية قائمة انتظار مهمة شائعة
ما الذي يجب تنفيذه في تنفيذ قائمة انتظار قابلة لإعادة الاستخدام إذا كان لديك بالفعل تطبيقات واجهات حاوية الموصوفة مسبقًا؟ الخوارزمية الأساسية لقائمة المهام بسيطة للغاية.
- قم بتنزيل المهام المتوفرة حاليًا من الحاوية المصدر.
- قم بتوضيح حالة قائمة انتظار المهام لمعرفة المهام التي تم إكمالها بالفعل أو ما زالت قيد التنفيذ.
- لكل مهمة من المهام التي لم يتم حلها ، قم بإنشاء حاويات حاوية بواجهة مناسبة.
- عند الانتهاء بنجاح من الحاوية المنفذة ، سجل أن المهمة قد اكتملت.
هذه الخوارزمية بسيطة في الكلمات ، لكنها في الواقع ليست سهلة التنفيذ. لحسن الحظ ، فإن أوركسترا Kubernetes لديها العديد من الميزات التي تبسط تنفيذه إلى حد كبير. وهي: Kubernetes يحتوي على كائن Job يضمن التشغيل الموثوق لقائمة الانتظار المهمة. يمكنك تكوين كائن المهمة بحيث يبدأ تشغيل حاوية التنفيذ المقابلة إما لمرة واحدة أو حتى تكتمل المهمة بنجاح. إذا قمت بتكوين الحاوية المنفذة بحيث يتم تشغيلها قبل اكتمال المهمة ، فعندما يفشل الجهاز الموجود في الكتلة ، سيتم إتمام المهمة بنجاح.
وبالتالي ، فإن قائمة انتظار المهام مبسطة إلى حد كبير ، حيث تتحمل الأوركسترا مسؤولية التنفيذ الموثوق للمهام.
بالإضافة إلى ذلك ، يسمح لك Kubernetes بتعليق المهام ، مما يسمح لنا بتمييز كل كائن مهمة باسم عنصر قائمة انتظار المهام التي تمت معالجتها. أصبح من السهل التمييز بين المهام التي تتم معالجتها وإكمالها بنجاح مع وجود خطأ.
هذا يعني أنه يمكننا تنفيذ قائمة انتظار المهام أعلى منسق أعمال Kubernetes دون استخدام مستودعنا الخاص. كل هذا يبسط إلى حد كبير مهمة بناء البنية التحتية لقائمة الانتظار المهمة.
لذلك ، خوارزمية مفصلة لتشغيل الحاوية ، مدير قائمة انتظار المهام ، كما يلي.
كرر ما لا نهاية.
- الحصول على قائمة المهام من خلال واجهة الحاوية - مصدر المهام.
- الحصول على قائمة المهام التي تخدم قائمة انتظار هذه المهمة.
- على أساس هذه القوائم ، حدد قائمة من المهام غير المجهزة.
- لكل مهمة غير معالجة ، قم بإنشاء كائن مهمة يولد الحاوية المنفذة المقابلة.
فيما يلي نص بيثون يقوم بتنفيذ قائمة الانتظار هذه:
import requests import json from kubernetes import client, config import time namespace = "default" def make_container(item, obj): container = client.V1Container() container.image = "my/worker-image" container.name = "worker" return container def make_job(item): response = requests.get("http://localhost:8000/items/{}".format(item)) obj = json.loads(response.text) job = client.V1Job() job.metadata = client.V1ObjectMeta() job.metadata.name = item job.spec = client.V1JobSpec() job.spec.template = client.V1PodTemplate() job.spec.template.spec = client.V1PodTemplateSpec() job.spec.template.spec.restart_policy = "Never" job.spec.template.spec.containers = [ make_container(item, obj) ] return job def update_queue(batch): response = requests.get("http://localhost:8000/items") obj = json.loads(response.text) items = obj['items'] ret = batch.list_namespaced_job(namespace, watch=False) for item in items: found = False for i in ret.items: if i.metadata.name == item: found = True if not found: # Job, # job = make_job(item) batch.create_namespaced_job(namespace, job) config.load_kube_config() batch = client.BatchV1Api() while True: update_queue(batch) time.sleep(10)
ورشة عمل تنفيذ مولد مصغر لملفات الفيديو
كمثال على استخدام قائمة انتظار المهام ، فكر في مهمة إنشاء صور مصغرة لملفات الفيديو. بناءً على هذه الصور المصغرة ، يقرر المستخدمون مقاطع الفيديو التي يرغبون في مشاهدتها.
لتنفيذ الصور المصغرة ، تحتاج إلى حاويتين. الأول هو لمصدر المهام. سيكون من الأسهل وضع المهام على محرك أقراص شبكة مشترك متصل ، على سبيل المثال ، عبر NFS (نظام ملفات الشبكة ، نظام ملفات الشبكة). يتلقى مصدر المهمة قائمة بالملفات الموجودة في هذا الدليل ويمررها إلى المتصل.
سأقدم برنامجًا بسيطًا على NodeJS:
const http = require('http'); const fs = require('fs'); const port = 8080; const path = process.env.MEDIA_PATH; const requestHandler = (request, response) => { console.log(request.url); fs.readdir(path + '/*.mp4', (err, items) => { var msg = { 'kind': 'ItemList', 'apiVersion': 'v1', 'items': [] }; if (!items) { return msg; } for (var i = 0; i < items.length; i++) { msg.items.push(items[i]); } response.end(JSON.stringify(msg)); }); } const server = http.createServer(requestHandler); server.listen(port, (err) => { if (err) { return console.log(' ', err); } console.log(` ${port}`) });
يحدد هذا المصدر قائمة الأفلام المراد معالجتها. يتم استخدام الأداة المساعدة ffmpeg لاستخراج الصور المصغرة.
يمكنك إنشاء حاوية تقوم بتشغيل الأمر التالي:
ffmpeg -i ${INPUT_FILE} -frames:v 100 thumb.png
يستخرج الأمر واحدًا من كل 100 إطار (-frames: v 100 المعلمة) ويحفظه بتنسيق PNG (على سبيل المثال ، thumb1.png ، thumb2.png ، إلخ).
يمكن تنفيذ هذا النوع من المعالجة بناءً على صورة ffmpeg Docker الحالية.
صورة jrottenberg / ffmpeg شائعة.
من خلال تحديد حاوية مصدر بسيطة ومنفذ حاوية أبسط ، من السهل رؤية فوائد نظام إدارة قوائم الانتظار العامة والموجهة نحو الحاويات. فهو يقلل بشكل كبير من الوقت بين تصميم وتنفيذ قائمة انتظار المهمة.
التحجيم الديناميكي للفنانين
قائمة انتظار المهام التي تم بحثها سابقًا مناسبة تمامًا لمعالجة المهام عند توفرها ، ولكن يمكن أن تؤدي إلى تحميل مفاجئ على موارد مُنسق مجموعة الحاوية. يعد هذا أمرًا جيدًا عندما يكون لديك العديد من أنواع المهام المختلفة التي تنشئ قمم تحميل في أوقات مختلفة ، وبالتالي تقوم بتوزيع الحمل على الكتلة بمرور الوقت.
ولكن إذا لم يكن لديك أنواع كافية من التحميل ، فقد يتطلب نهج "ثم سميك ، ثم فارغ" لتوسيع قائمة انتظار المهام حجز موارد إضافية لدعم رشقات من التحميل. بقية الوقت ، ستكون الموارد في وضع الخمول ، وتفريغ محفظتك دون داع.
لحل هذه المشكلة ، يمكنك تحديد العدد الإجمالي للكائنات المهمة التي تم إنشاؤها بواسطة قائمة انتظار المهام. سيؤدي هذا بطبيعة الحال إلى الحد من عدد المهام التي تتم معالجتها بالتوازي ، وبالتالي ، يقلل من استخدام الموارد أثناء حمل الذروة. من ناحية أخرى ، ستزداد مدة كل مهمة فردية مع زيادة الحمل على الكتلة.
إذا كان الحمل متقطعًا ، فهذا ليس مخيفًا ، لأنه يمكن استخدام فترات التوقف لإكمال المهام المتراكمة. ومع ذلك ، إذا كان التحميل الثابت مرتفعًا جدًا ، فلن يتوفر لقائمة انتظار المهام الوقت لمعالجة المهام الواردة وسيتم إنفاق المزيد والمزيد من الوقت على تنفيذها.
في مثل هذه الحالة ، سوف تضطر إلى ضبط الحد الأقصى لعدد المهام المتوازية ديناميكيًا ، وبالتالي موارد الحوسبة المتاحة للحفاظ على مستوى الأداء المطلوب. لحسن الحظ ، هناك صيغ رياضية تسمح لك بتحديد متى يكون من الضروري توسيع قائمة انتظار المهمة لمعالجة المزيد من الطلبات.
ضع في اعتبارك قائمة انتظار مهمة تظهر فيها مهمة جديدة في المتوسط مرة واحدة في الدقيقة ، ويستغرق إكمالها 30 ثانية في المتوسط. قائمة الانتظار هذه قادرة على مواجهة تدفق المهام القادمة إليها. حتى إذا وصلت حزمة كبيرة من المهام في وقت واحد ، مما أدى إلى ازدحام حركة المرور ، فسيتم التخلص من ازدحام المرور بمرور الوقت ، لأنه قبل وصول المهمة التالية ، يمكن لقائمة الانتظار معالجة متوسط مهمتين في المتوسط.
إذا وصلت مهمة جديدة كل دقيقة واستغرق الأمر دقيقة واحدة في المتوسط لمعالجة مهمة واحدة ، فإن مثل هذا النظام متوازن بشكل مثالي ، لكنه لا يستجيب جيدًا للتغيرات في الحمل. إنها قادرة على تحمل رشقات الحمل ، لكن الأمر سيستغرق الكثير من الوقت. لن يكون النظام خاملاً ، لكن لن يكون هناك احتياطي من وقت الكمبيوتر للتعويض عن الزيادة الطويلة الأجل في سرعة استلام المهام الجديدة. للحفاظ على استقرار النظام ، من الضروري أن يكون لديك احتياطي في حالة نمو الحمل على المدى الطويل أو التأخيرات غير المتوقعة في مهام المعالجة.
أخيرًا ، ضع في اعتبارك نظامًا تصل فيه مهمة واحدة في الدقيقة ، وتستغرق معالجة المهمة دقيقتين. مثل هذا النظام سوف تفقد الأداء باستمرار. سوف يزداد طول قائمة انتظار المهام مع التأخير بين استلام المهام ومعالجتها (ودرجة تهيج المستخدمين).
يجب مراقبة قيم هذين المؤشرين باستمرار. عن طريق حساب متوسط الوقت بين استلام المهام لفترة طويلة من الوقت ، على سبيل المثال ، بناءً على عدد المهام في اليوم ، نحصل على تقدير للفاصل الزمني بين المهام. من الضروري أيضًا مراقبة متوسط وقت معالجة المهمة (باستثناء الوقت المستغرق في قائمة الانتظار). في قائمة انتظار مهمة مستقرة ، يجب أن يكون متوسط وقت معالجة المهمة أقل من الفاصل الزمني بين المهام. لضمان تلبية هذا الشرط ، من الضروري ضبط عدد قوائم الانتظار المتاحة لموارد الحوسبة ديناميكيًا. إذا تمت معالجة المهام بالتوازي ، فيجب تقسيم وقت المعالجة على عدد الوظائف التي تتم معالجتها بشكل متواز. على سبيل المثال ، إذا تمت معالجة مهمة واحدة لمدة دقيقة ، ولكن تمت معالجة أربع مهام بالتوازي ، فإن وقت المعالجة الفعال لمهمة واحدة هو 15 ثانية ، مما يعني أن الفاصل بين المهام يجب أن يكون 16 ثانية على الأقل.
يتيح لك هذا الأسلوب إنشاء وحدة نمطية بسهولة لتوسيع قائمة انتظار المهام لأعلى. إن تقليص حجمها أكثر إشكالية إلى حد ما. ومع ذلك ، فمن الممكن استخدام نفس الحسابات كما كان من قبل ، بالإضافة إلى وضع احتياطي موارد الحوسبة التي تحددها طريقة الكشف عن مجريات الأمور. على سبيل المثال ، يمكنك تقليل عدد المهام المتوازية حتى يصبح وقت المعالجة لمهمة واحدة 90٪ من الفاصل الزمني بين المهام.
متعدد العمال نمط
أحد الموضوعات الرئيسية لهذا الكتاب هو استخدام الحاويات لتغليف وإعادة استخدام الرمز. كما أنه مرتبط بأنماط قائمة انتظار المهام الموضحة في هذا الفصل. بالإضافة إلى الحاويات التي تدير قائمة الانتظار نفسها ، يمكنك إعادة استخدام مجموعات من الحاويات التي تشكل تنفيذ فناني الأداء. افترض أنك بحاجة إلى معالجة كل مهمة في قائمة انتظار بثلاث طرق مختلفة. على سبيل المثال ، لاكتشاف الوجوه في صورة ما ، قم بربطها بأشخاص محددين ، ثم قم بطمس الأجزاء المقابلة من الصورة. يمكنك وضع كل المعالجة في حاوية تنفيذ واحدة ، ولكن هذا حل لمرة واحدة لا يمكن إعادة استخدامه. للتستر على شيء آخر ، مثل السيارات ، في الصورة ، سيتعين عليك إنشاء فنان حاوي من الصفر.
يمكن تحقيق هذا النوع من إعادة الاستخدام من خلال تطبيق نقش متعدد العمال ، وهو في الواقع حالة خاصة من نمط المحول الموصوف في بداية الكتاب. يحول نمط Multi-Worker مجموعة من الحاويات إلى حاوية واحدة مشتركة مع واجهة البرنامج الخاصة بالحاوية المنفذة. تفويض هذه الحاوية المشتركة معالجة عدة حاويات منفصلة قابلة لإعادة الاستخدام. تظهر هذه العملية بشكل تخطيطي في الشكل. 10.4.
عن طريق إعادة استخدام الكود من خلال الجمع بين الحاويات المنفذة ، يتم تقليل عمالة الأشخاص الذين يقومون بتصميم أنظمة معالجة الدُفعات الموزعة.
»يمكن الاطلاع على مزيد من المعلومات حول الكتاب على
موقع الناشر»
المحتويات»
مقتطفاتل habrozhitelami خصم 20 ٪ على القسيمة -
النظم الموزعة .