أنظمة متعددة الوكالات في بناء المساحات الافتراضية

واحدة من المشاكل الحرجة التي تنشأ عند بناء أنظمة متعددة المستخدمين هي التوسع. هناك العديد من الحلول لهذه المشاكل: التقسيم ونموذج الخدمة ونظام الكيان - المكون. سننظر اليوم في جميع الخيارات ، وسنناقش أيضًا حالة عملية لحل المشكلة. انضم الآن!



الجزء الأول
الجزء 2

انقل الكلمة للمؤلفين.

الأساليب التقليدية لبناء أنظمة متعددة المستخدمين. هندسة الخدمة

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

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

المشكلة الرئيسية هي الدولة المشتركة

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

الحل: نظام مكون الكيان. مشاكل في الشرق الأقصى

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

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

أنظمة الوكيل كوسيلة لكتابة رمز مواز

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

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

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

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

قضيتنا هي جوهر الشرق الأقصى كعامل

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

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



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



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

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

المؤلفين

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

Vitaliy Chashchin - مطور برامج مع أكثر من 10 سنوات من الخبرة في تصميم وتنفيذ تطبيقات خادم العميل ثلاثية الأبعاد - من المفهوم إلى التنفيذ الكامل والتكامل بين التطبيقات والحلول في مجال الواقع الافتراضي. مهندس النظم Jedium LLC ، ماجستير في تكنولوجيا المعلومات.

أليكسي سارافانوف

Marketing Manager في Jedium LLC.

سيرجي كودريافتسيف

الرئيس التنفيذي ومؤسس Jedium LLC.