एक साधारण मल्टी-प्लेटफॉर्म बॉट की संरचना बनाएं

घटनाओं के लिए उपयोगकर्ताओं को पंजीकृत करना, स्वचालित रूप से डेटाबेस में जवाब खोजना, तकनीकी सहायता से संचार करना, संपर्कों का आदान-प्रदान करना - ये सभी हमारे लीडर-आईडी बॉट के कार्यों का हिस्सा हैं। वह तीन प्लेटफार्मों पर "रहता है": वीके, फेसबुक मैसेंजर और टेलीग्राम, जबकि उनके काम का तर्क सभी को एक बार प्लेटफॉर्म-स्वतंत्र सार का उपयोग करने के लिए लिखा गया है। यह दृष्टिकोण आपको नई सुविधाओं को जल्दी से जोड़ने और पुराने लोगों को पीसने की अनुमति देता है।



सिस्टम की संरचना विभिन्न प्लेटफार्मों के लिए कार्यों के विकास को एक समान बनाती है और प्रत्येक प्लेटफ़ॉर्म-निर्भर एपीआई में मैन्युअल रूप से उन्हें फिर से लिखने के विकल्प की तुलना में परिमाण के क्रम से प्रक्रियाओं को सरल बनाती है। उसी समय, एक नए प्लेटफ़ॉर्म पर बॉट शुरू करने के लिए, आपको बस उपयुक्त एडेप्टर ( कनेक्टर ) लिखना होगा।

मैं इस संरचना के बारे में संक्षेप में बात करना चाहता था। शायद यह उन लोगों के लिए उपयोगी होगा जो अपने क्रॉस-प्लेटफॉर्म बॉट लिखना चाहते हैं, लेकिन अभी तक इस विषय में गहराई से नहीं उतरे हैं और किसी और के अनुभव का अध्ययन कर रहे हैं।

आइए हमारे बॉट से परिचित हों। वह टेलीग्राम , वीके , एफबी में पाया जा सकता है, जहां वह एक ही समय में कई हजार लोगों की सेवा करता है (जैसा कि अन्य घटनाओं में होता है)। वैसे, हम सीख सकते हैं कि हम कौन हैं और हम अपने पहले लेख से क्या करते हैं। संक्षेप में, हम पूरे रूस में मुक्त सहकर्म और प्रस्तुति स्थलों का एक विशाल नेटवर्क संचालित करते हैं और साथ ही लीडर-आईडी संचार मंच का समर्थन करते हैं, जो पूरे सिस्टम का मूल है। और पूरी कहानी में बॉट एक महत्वपूर्ण भूमिका निभाता है।

डबल बंदूक - डबल मज़ा

वास्तव में, हमारे पास दो बॉट हैं। पहला मुख्य एक है, जो उपयोगकर्ताओं के साथ बातचीत करने के लिए जिम्मेदार है। यह घटनाओं के लिए मोबाइल उपयोगकर्ता पंजीकरण, समर्थन के साथ बातचीत और व्याख्यान और सेमिनार से अतिरिक्त जानकारी प्राप्त करने के साथ-साथ एक ही पारिस्थितिकी तंत्र के भीतर संपर्कों का आदान-प्रदान करने का एक सुविधाजनक साधन है।



दूसरा बॉट अनिवार्य रूप से समर्थन ऑपरेटरों के लिए एक इंटरफ़ेस है। बॉट्स संयोजन के रूप में काम करते हैं, लेकिन उनके आधार और इंटरफेस अलग हो जाते हैं।

उनके उदाहरण का उपयोग करते हुए, हम दिखाएंगे कि ऐसी प्रणाली की संरचना कैसी दिख सकती है। हालांकि, हम साधारण मामलों के साथ, इस गेंद को धीरे-धीरे खोलना शुरू कर देंगे।

सबसे सरल बॉट की संरचना

मूल संस्करण में, बॉट में केवल एक ही सेवा शामिल होगी जो संदेशवाहक (प्लेटफ़ॉर्म) के एपीआई के माध्यम से संदेश भेजता है और प्राप्त करता है, उदाहरण के लिए टेलीग्राम।



यदि हमारे पास कई संदेशवाहक हैं जिनके माध्यम से हम उपयोगकर्ताओं के साथ संवाद करना चाहते हैं, तो कनेक्टर्स को संरचना के लिए कनेक्टर्स के साथ प्लेटफ़ॉर्म-स्वतंत्र शैली में तर्क लिखना उचित होगा जो आंतरिक प्रारूप से कमांड और डेटा को संबंधित प्लेटफॉर्म (मैसेंजर) के प्रारूप में अनुवाद करता है।



इससे एक ही स्थान पर नई सुविधाओं को जोड़ना संभव होगा, और प्रत्येक प्लेटफ़ॉर्म के लिए उन्हें अलग से डुप्लिकेट नहीं किया जाएगा।

कनेक्टर्स ऐसी सेवाएं हैं जो प्लेटफॉर्म से कर्नेल और इसके विपरीत के लिए संदेश प्राप्त करती हैं। सामान्य तौर पर, ये सिस्टम के अपेक्षाकृत स्वतंत्र घटक होते हैं, जो यदि आवश्यक हो, तो एक अलग सर्वर पर स्थित हो सकते हैं, कई प्रतिकृतियां, और इसी तरह हो सकते हैं।

हम कनेक्टर्स और कर्नेल के संचार को व्यवस्थित करते हैं (डेटाबेस को मतदान करते हैं, या यह कैसे नहीं करते हैं)

तो, हम कनेक्टर्स और कोर के बीच डेटा के आदान-प्रदान को व्यवस्थित करने के कार्य के साथ सामना कर रहे हैं। पहला विकल्प डेटाबेस के माध्यम से नए संदेश भेजने का है। हमने इससे शुरुआत की। तदनुसार, डेटाबेस ही हमारी योजना में दिखाई देता है, और संरचना इस तरह से बनती है: पायथन में लिखा गया एक कर्नेल, प्लस मोंगोब्डी पर एक आधार (इस विकल्प के कारण विशेष रूप से ऐतिहासिक हैं), प्लस कनेक्टर।



यह योजना हमारे लिए अपेक्षाकृत लंबे समय तक काम नहीं कर सकी। जब संदेशों की संख्या 700 हजार से अधिक हो गई, और चोटियों में आवृत्ति 120 हिट प्रति सेकंड तक पहुंच गई, तो इंडेक्स भारी हो गए, डेटाबेस को महंगा करना काफी महंगा हो गया। मुझे यहां RabbitMQ ब्रोकर को कनेक्ट करना था। इसकी मुख्य भूमिका सूचनाओं को उत्पन्न करने के लिए है कि एक घटक (कोर / कनेक्टर) को एक विशिष्ट पहचानकर्ता के साथ एक संदेश को संसाधित करना चाहिए। इसके जरिए ये आईडी ट्रांसमिट की जाती हैं। RabbitMQ ने हमें आधार और घटकों को उतार दिया है, जिन्हें अब प्रसंस्करण के लिए नई जानकारी के लिए लगातार डेटाबेस की जांच करने की आवश्यकता नहीं है।

नतीजतन, हमारी बुनियादी संरचना इस तरह दिखना शुरू हुई:



डेटाबेस के माध्यम से कनेक्टर्स के काम में एक माइनस है - इससे उनकी स्वतंत्रता कम हो जाती है और सिस्टम की कनेक्टिविटी बढ़ जाती है। हालांकि, यदि कतार प्रबंधक का उपयोग करके डेटा को सीधे स्थानांतरित किया जाता है, तो उनकी सुरक्षा और उपलब्धता के लिए सभी जिम्मेदारी इस ब्रोकर के पास है। यह विश्वसनीयता और पारदर्शिता की मांगों को कैसे पूरा करता है यह एक खुला प्रश्न है। खुद के लिए, हमने तय किया कि हम सिस्टम के आगे विकास की प्रक्रिया में इसके साथ प्रयोग करेंगे।

एडमीन को जोड़ना

संपूर्ण रसोई का प्रबंधन करने के लिए आपको एक व्यवस्थापक इंटरफ़ेस की आवश्यकता होती है। इसकी मदद से, हम पत्राचार में आवश्यक जानकारी पाते हैं, डेटा संपादित करते हैं, सर्वेक्षण और समाचार पत्र करते हैं। इसलिए, वेब घटक हमारे आरेख में दिखाई देता है। उपरोक्त के अलावा, यह उपयोगकर्ताओं और बॉट एपीआई को प्रमाणित करने के लिए एक वेब इंटरफ़ेस प्रदान करता है।



वेब विशेष प्रणाली संदेशों के माध्यम से डेटाबेस और कर्नेल के साथ संचार करता है। उन्हें पाठ के रूप में रूट किया जाता है, उनके पास केवल उपयोगकर्ता के एक नए संदेश के बारे में जानकारी नहीं होती है, बल्कि सिस्टम में कुछ अन्य घटनाओं के बारे में होती है, जिसके लिए कर्नेल को जवाब देना चाहिए। उदाहरण के लिए, प्राधिकरण कोड प्राप्त करना।

व्यवस्थापकों के लिए इंटरफ़ेस स्वयं इस तरह दिखता है:

हम दूसरे बॉट के माध्यम से ऑपरेटरों को जोड़ते हैं

पूर्ण उपयोगकर्ता समर्थन को लागू करने के लिए, हमने ऑपरेटरों को सिस्टम से जोड़ा। उनके साथ संचार की गति को बनाए रखने के लिए, उपयुक्त विकल्पों की अनुपस्थिति में, टेलीग्राम को मुख्य संवाद इंटरफ़ेस के रूप में चुना गया था। ऑपरेटर इसके माध्यम से उपयोगकर्ता प्रश्न प्राप्त करते हैं और तुरंत उत्तर भेजते हैं।

मुख्य बॉट के साथ उपयोगकर्ता संवाद ऐसा लगता है जैसे समर्थन प्रश्न भेजते समय:


स्क्रीनशॉट में वाक्यांश "टेस्ट प्रश्न" तकनीकी सहायता के लिए प्रश्न का पाठ है

नतीजतन, एक दूसरा बॉट (सपोर्ट बॉट) हमारे सर्किट पर इसके कोर और टेलीग्राम कनेक्टर के साथ दिखाई देता है। वह मुख्य कोर के साथ संचार करता है और उपयोगकर्ताओं और चैट के बीच प्रश्नों और उत्तरों के हस्तांतरण का आयोजन करता है जिसमें सहायक एजेंट बैठे होते हैं।



इसका अपना डेटाबेस भी है। लेकिन अंत उपयोगकर्ता के साथ संचार मुख्य बॉट के मूल के माध्यम से जाता है, जो संदेशों के समग्र प्रवाह को नियंत्रित करता है।

यहां उपयोगकर्ता के संदेशों को रीडायरेक्ट करने वाले समर्थन बॉट के साथ ऑपरेटर का संवाद कैसा दिखता है:



हमारे मामले में, ऑपरेटरों को दो श्रेणियों में विभाजित किया गया है: वे जो सामान्य उपयोगकर्ता समर्थन में लगे हुए हैं, और जो व्यक्तिगत क्वथनांक या घटनाओं का समर्थन करने के लिए जिम्मेदार हैं। हालांकि, इस संरचना पर कोई प्रभाव नहीं है।

हमारे बॉट और क्या कर सकते हैं?

यह जानकारी केवल हमारे अभ्यास की चिंता करती है, लेकिन शायद यह सरल विचारों के चयन के रूप में दिलचस्प होगा जिसे आप नोट कर सकते हैं।

संपर्क से संपर्क करें

यह बॉट से व्यक्तिगत क्यूआर कोड की स्कैनिंग और मान्यता के माध्यम से किया जाता है। ऐसा करने के लिए, डिफ़ॉल्ट छवि प्रोसेसर को कर्नेल में जोड़ा जाता है। छवियाँ कनेक्टर्स द्वारा भेजी जाती हैं, जो उन्हें संदेश के साथ डेटाबेस में सहेजती हैं।



क्यूआर कोड मान्यता का उपयोग उपयोगकर्ता को सेमिनार से अतिरिक्त जानकारी या फ़ाइलों को प्रदान करने के लिए भी किया जाता है। यह इस तरह दिखता है:



अधिसूचना मेलिंग



वेब मॉड्यूल में नियंत्रण कक्ष के माध्यम से, हम विभिन्न घटनाओं के प्रतिभागियों को सूचनाएं भेज सकते हैं।

सर्वेक्षण करना

इसी तरह, व्याख्यान के दौरान सर्वेक्षण किए जाते हैं। लेकिन उनके लिए, हम अभी भी मैन्युअल रूप से तर्क के साथ एक JSON फ़ाइल उत्पन्न करते हैं, जिसे हम वेब पर अपलोड करते हैं।





प्रश्न उत्तर के साथ, और खुले दोनों हो सकते हैं। और सर्वेक्षण की संरचना उत्तर के आधार पर भिन्न हो सकती है।





ऑटो जवाब

बॉट स्वतंत्र रूप से अक्सर पूछे जाने वाले प्रश्नों के उत्तर का चयन कर सकता है।



ऐसा करने के लिए, हमारे पास एक विशेष आधार है, मैन्युअल रूप से फिर से भरना। अगर वहां कुछ भी उपयुक्त नहीं पाया गया या उपयोगकर्ता चयनित जवाब से संतुष्ट नहीं था, तो समर्थन बॉट के माध्यम से उसकी अपील को ऑपरेटरों को पुनर्निर्देशित किया गया।

सामान्य तौर पर, जबकि यह हमारा संपूर्ण एस्टेरिस्टोन है। फिलहाल, हम नेटवर्किंग के कार्यों के विस्तार पर काम कर रहे हैं और उम्मीद करते हैं कि निकट भविष्य में हमारे बॉट को थोड़ा और अधिक "वसा" मिलेगा, जबकि इसकी संरचना समान रहेगी।