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

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

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

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

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

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

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

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

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

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

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

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


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

الردود التلقائيةيمكن للبوت تحديد إجابات للأسئلة المتداولة بشكل مستقل.

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