Tacticool मोबाइल ऑनलाइन शूटर मेटा सर्वर आर्किटेक्चर

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


सबसे पहले, मैं हमारे खेल के लिए एक छोटा सा ट्रेलर प्रदर्शित करना चाहता हूं:


रिपोर्ट में 3 भाग होंगे। पहले मैं इस बारे में बात करूंगा कि हमने कौन सी तकनीकें चुनीं और क्यों, दूसरे में - हमारे मेटा-सर्वर की व्यवस्था कैसे की जाती है, और तीसरे में मैं उन विभिन्न सहायक बुनियादी ढाँचों के बारे में बात करूँगा जो हम उपयोग करते हैं, और हमने डाउनटाइम के बिना अपडेट कैसे लागू किया। ।


टेक्नोलॉजिकल स्टैक

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

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



जब मैं कंपनी में शामिल हुआ, तो हमारे पास पहले से ही C / C ++ मिश्रण और PostageSQL स्टोरेज पर एक मोनोलिथ के रूप में लागू की गई बुनियादी कार्यक्षमता थी। इस कार्यान्वयन में कुछ समस्याएं थीं।

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

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

कुछ हफ़्ते बिताने के बाद, सबसे महत्वपूर्ण कीड़े खोजने और ठीक करने में, हमने तय किया कि वर्तमान समाधान की सभी कमियों को ठीक करने की कोशिश करने के लिए खरोंच से सब कुछ फिर से लिखना आसान था।

और जब आप खरोंच से शुरू करते हैं, तो यह एक ऐसी भाषा चुनने की कोशिश करना समझ में आता है जो पिछली कुछ समस्याओं से बचने में मदद करेगा। हमारे तीन उम्मीदवार थे:

• सी #;
• जाओ,
• अमृत।

C # "परिचित" सूची में था, जैसा कि क्लाइंट और गेम सर्वर एकता में लिखे गए हैं, और टीम में अधिकांश अनुभव इस प्रोग्रामिंग भाषा के साथ था। गो और अमृत पर विचार किया गया क्योंकि ये सर्वर अनुप्रयोगों के विकास के लिए बनाई गई आधुनिक और काफी लोकप्रिय भाषाएं हैं।

पिछली पुनरावृत्ति की समस्याओं ने हमें उम्मीदवारों के मूल्यांकन के मानदंड निर्धारित करने में मदद की।

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

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

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

और अंतिम मानदंड विशेषज्ञों की संख्या थी। यहाँ परिणाम स्पष्ट हैं। अंत में, हमने अमृत का विकल्प चुना।

होस्टिंग के विकल्प के साथ, सब कुछ बहुत सरल था। हमने पहले ही गेम गेम सर्वर को अमेज़न गेमलिफ्ट में होस्ट किया है, इसके अलावा, अमेज़ॅन बड़ी संख्या में सेवाएं प्रदान करता है जो हमें विकास के समय को कम करने की अनुमति देगा।



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

हमने प्रौद्योगिकियों की पसंद का पता लगाया, आइए आगे बढ़ते हैं कि मेटा सर्वर कैसे काम करता है।



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

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

सामान्य योजना के साथ, चलिए विवरण पर चलते हैं।



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

अब थोड़ा इस बारे में कि फ्रंटएंड की व्यवस्था कैसे की जाती है।



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

अब बैकेंड कैसा दिखता है, इसके बारे में। फिलहाल, इसमें पांच सेवाएं शामिल हैं।



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

वास्तुकला की दृष्टि से बैकएंड सेवाओं में से प्रत्येक बिल्कुल समान दिखता है। वे पाइपलाइनों का एक सेट हैं, जिनमें से प्रत्येक एक प्रकार के संदेश को संसाधित करता है। पाइपलाइन में दो तत्व होते हैं: उत्पादक और उपभोक्ता।



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

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

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



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

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



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

अब हम उस अतिरिक्त बुनियादी ढाँचे की ओर बढ़ते हैं जिसका हम उपयोग करते हैं।



सेवाओं की तैनाती काफी सरल है। वे सभी डॉकटर कंटेनरों में काम करते हैं, और हम ऑर्केस्ट्रा के लिए अमेज़ॅन ईसीएस का उपयोग करते हैं। यह कुबेरनेट्स की तुलना में बहुत सरल है, बेशक, कम परिष्कृत है, लेकिन यह उन कार्यों को करता है जो हमें इसकी आवश्यकता है। अर्थात्: जब हम किसी तरह के बगफिक्स को भरने की आवश्यकता होती है, तो स्केलिंग सेवाओं और रोलिंग रिलीज।

और अंतिम सेवा जिसका हम उपयोग करते हैं, वह है AWS Fargate। यह हमें उन मशीनों के समूह को स्वतंत्र रूप से प्रबंधित करने से बचाता है जिन पर हमारे डॉकटर कंटेनर चलते हैं।



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

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

लॉगिंग और निगरानी के लिए, हम काफी कुछ सेवाओं का उपयोग करते हैं।



चलिए CloudWatch से शुरू करते हैं। यह एक निगरानी सेवा है जिसमें सभी अमेज़ॅन सेवाओं के झुंड से मैट्रिक्स आते हैं। इसलिए, हमने अपने मेटा सर्वर से भी मैट्रिक्स भेजने का फैसला किया। और लॉगिंग के लिए, हम क्लाइंट और गेम सर्वर और मेटा सर्वर पर एक सामान्य दृष्टिकोण का उपयोग करते हैं। हम सभी लॉग को अमेजोनियन सेवा किनेसिस फायरहोज में भेजते हैं, जो बदले में उन्हें एलीस्टीचेक और एस 3 में स्थानांतरित करता है।

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

अब थोड़ा हम टेराफॉर्म का उपयोग कैसे करते हैं इसके बारे में।



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

मैं यह भी बात करूंगा कि हमने डाउनटाइम के बिना अपडेट को कैसे लागू किया



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

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

अंत में, कुछ चीजें जो हमने सीखीं। सबसे पहले, पूरे बुनियादी ढांचे का विन्यास स्वचालित होना चाहिए। यानी हमने कुछ समय के लिए अपने हाथों से कुछ चीजें स्थापित कीं, लेकिन जल्द ही या बाद में हमने सेटिंग्स में गलती कर दी, जिसकी वजह से वहाँ थापक थे।



और आखिरी बात - आपको अपने बुनियादी ढांचे के प्रत्येक तत्व के लिए या तो एक प्रतिकृति या एक बैकअप प्रतिलिपि की आवश्यकता है। और यदि आप इसे किसी चीज के लिए नहीं करते हैं, तो यह विशेष चीज कभी भी हमें निराश नहीं करेगी।

श्रोताओं से सवाल

- लेकिन क्या यह आपको परेशान नहीं करता है कि किसी तरह की त्रुटि के कारण ऑटोसालिंग बहुत अधिक चिपक सकता है और आपको बहुत पैसा मिलेगा?

- ऑटोस्कोलिंग के लिए, सीमाएँ अभी भी निर्धारित हैं। हम बहुत बड़ी सीमा निर्धारित नहीं करेंगे ताकि बहुत सारे पैसे न गिरें। यह मुख्य समाधान + निगरानी है। यदि कुछ बहुत मजबूत है तो आप अलर्ट सेट कर सकते हैं।

- आपकी वर्तमान सीमाएँ क्या हैं? प्रतिशत के रूप में वर्तमान बुनियादी ढांचे के सापेक्ष।

- अब हमारे पास 11 देशों में एक ओपन बीटा परीक्षण चरण है, इसलिए यह कम से कम किसी भी तरह का मूल्यांकन करने के लिए इतना बड़ा CCU नहीं है। अब हमारे पास जितने लोग हैं, उनके लिए आधारभूत संरचना बहुत अधिक है।

- और अभी तक कोई सीमा नहीं है?

- हां, बस इतना है कि वे हमारे CCU से 10-100 गुना अधिक हैं। कम मत करो।

- आपने कहा कि आपके सामने और बैकएंड के बीच की रेखाएं हैं - यह बहुत ही असामान्य है। सीधे क्यों नहीं?

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

- क्या कतार किसी तरह बनी रहती है?

- हां। यह एक Amazonian SQS सेवा है।

- कतारों के बारे में: खेल के दौरान कितने चैनल बनाए जाते हैं? क्या आपके पास प्रत्येक मैच के लिए कुछ निश्चित चैनल हैं?

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

- इस वास्तुकला में, यह आपके लिए एक सीमा नहीं होगी?

- नहीं।

Pixonic DevGAMM वार्ता के साथ अधिक वार्ता

• कंसूल का उपयोग राज्य स्तरीय सेवाओं (इवान बुबनोव, BIT.GAMES में DevOps) के लिए;
• CICD: डाउनटाइम (Egor Panov, Pixonic सिस्टम एडमिनिस्ट्रेटर) के बिना वितरित क्लस्टर सिस्टमों में निर्बाध तैनाती ;
• क्वेक चैंपियंस गेम के बैकएंड प्लेटफ़ॉर्म में अभिनेता मॉडल का उपयोग करने की प्रथा (रोमन रोजोज़िन, बैकएंड डेवलपर कृपाण इंटरएक्टिव);
• कैसे ECS, C # जॉब सिस्टम और SRP आर्किटेक्चर के लिए दृष्टिकोण को बदलते हैं (वैलेंटाइन साइमनोव, फील्ड इंजीनियर एट यूनिटी);
• के विकास में KISS सिद्धांत (Konstantin Gladyshev, लीड खेल 1C खेल स्टूडियो में प्रोग्रामर);
• क्लाइंट और सर्वर पर सामान्य गेम लॉजिक (एंटोन ग्रिगोरिव, पिक्सेल में उप तकनीकी अधिकारी)।
• क्लाउड में ककड़ी: उत्पाद तनाव परीक्षण के लिए बीडीडी लिपियों का उपयोग करना (एंटोन कोसयाकिन, एलिस प्लेटफॉर्म पर तकनीकी उत्पाद प्रबंधक)।