टैंक सर्वर की विश्व विश्वसनीयता

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

आमतौर पर, जब वे विश्वसनीयता, निगरानी, ​​तनाव परीक्षण आदि के बारे में बात करते हैं तो हर समय उल्लेख किया जाता है। इसमें कुछ भी अलौकिक नहीं है, और रिपोर्ट टैंक के लिए विशिष्ट क्षणों के लिए समर्पित थी।

स्पीकर के बारे में: लेवॉन अवाक्यन वॉट गेम सर्विसेज और विश्वसनीयता के प्रमुख के रूप में वॉरगामिंग के लिए काम करता है और टैंक सर्वर विश्वसनीयता की समस्याओं से निपटता है।

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


आमतौर पर, जब वे विश्वसनीयता, निगरानी, ​​तनाव परीक्षण के बारे में बात करते हैं, और इसी तरह हर समय उल्लेख किया जाता है। मैंने इसे यहाँ शामिल नहीं किया क्योंकि मुझे लगता है कि यह उबाऊ है। हमने इसमें कुछ भी अलौकिक नहीं खोजा है। हां, हमारे पास एक मॉनिटरिंग सिस्टम भी है, हम सिस्टम की विश्वसनीयता बढ़ाने के लिए तनाव परीक्षण के साथ तनाव परीक्षण करते हैं और जानते हैं कि यह कहां गिर सकता है। लेकिन आज मैं बात करूंगा कि टैंकों के लिए क्या अधिक विशिष्ट है।

बिगवर्ल्ड टेक्नोलॉजी

यह एक बैकएंड इंजन है, साथ ही साथ MMO बनाने के लिए टूलकिट भी है।

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

इंजन को बिगवर्ल्ड कहा जाता है, क्योंकि इस पर गेम बनाना बहुत अच्छा है, जिसमें एक बड़ा क्षेत्र (स्पेस) है, जिस पर सैन्य अभियान (लड़ाई) होते हैं। टैंकों के लिए, यह पूरी तरह से फिट बैठता है।

विश्वसनीयता के संदर्भ में, बिगवर्ल्ड में निम्नलिखित प्रमुख विशेषताओं का निवेश किया गया था:

• लोड संतुलन। इंजन संसाधनों को आवंटित करता है, दो लक्ष्यों को प्राप्त करने की कोशिश कर रहा है:
  
  1. संभव के रूप में कुछ मशीनों का उपयोग करें;
  2. उसी समय, अपने अनुप्रयोगों को लोड न करें ताकि उनका भार एक निश्चित सीमा से अधिक हो जाए।
• अनुमापकता। हमने कार को क्लस्टर में जोड़ा, उस पर प्रक्रियाएं शुरू कीं - जिसका अर्थ है कि आप अधिक लड़ाइयों को गिन सकते हैं और खिलाड़ियों को स्वीकार कर सकते हैं।
  
• उच्च उपलब्धता। यदि, उदाहरण के लिए, एक कार गिर गई है या गेम की प्रक्रियाओं में से एक के साथ कुछ गलत हो गया है जो गेम को स्वयं सेवा करता है, तो चिंता करने की कोई बात नहीं है - गेम नोटिस नहीं करेगा, दूसरी जगह पर बहाल हो जाएगा और काम करेगा।
• डेटा अखंडता और स्थिरता बनाए रखें। यह दोष सहिष्णुता का दूसरा स्तर है। यदि टैंकों में, और डेटा सेंटर में या मुख्य चैनल पर किसी प्रकार की आपदा आती है, तो इसका मतलब यह नहीं है कि हम उस गेम डेटा को पूरी तरह से खो देंगे जो व्यक्ति ने खेला है। हम ठीक हो जाएंगे, संगति होगी।

हमारे सिस्टम और उनके कार्यों में जो प्रक्रियाएं हैं

• CellApp खेल अंतरिक्ष या इसके भाग के प्रसंस्करण के लिए जिम्मेदार प्रक्रिया है।
  

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

• CellAppMgr - वह प्रक्रिया जो CellApp के कार्य को समन्वित करती है, संतुलन को लोड करती है।
  

CellApp कई हो सकते हैं, तदनुसार, एक प्रक्रिया होनी चाहिए जो उन्हें नियंत्रित करती है।

• BaseApp संस्थाओं का प्रबंधन करता है, सेलएप के साथ काम करने से ग्राहकों को अलग करता है।

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

• ServiceApp एक विशेष BaseApp है जो किसी प्रकार की सेवा को लागू करता है।

यह BaseApp का एक सरलीकृत संस्करण है, एक प्रक्रिया जो विभिन्न सेवा सामग्री करती है। उदाहरण के लिए, किसी को RabbitMQ से पढ़ने में सक्षम होना चाहिए। यह खेल संस्थाओं के बारे में नहीं है, बल्कि इसकी जरूरत भी है।

• BaseAppMgr BaseApp और ServiceApp का प्रबंधन करता है, क्योंकि उनमें से बहुत सारे भी हैं।
• LoginApp ग्राहकों से नए कनेक्शन बनाता है, और BaseApp पर उपयोगकर्ताओं को भी समीप करता है।
• DBApp एक स्टोरेज एक्सेस इंटरफ़ेस (डेटाबेस) को लागू करता है। हम पेरकोना के साथ काम करते हैं, लेकिन यह एक और डेटाबेस हो सकता है।
• DBAppMgr DBApp के कार्य का समन्वय करता है।
• InterClusterMgr इंटरक्लस्टर संचार का प्रबंधन करता है।
• समीक्षक एक प्रक्रिया निरीक्षक है जो प्रक्रियाओं को पुनः आरंभ कर सकता है।
• BWMachineD   - एक डेमन जो क्लस्टर में प्रत्येक मशीन पर अपना काम समन्वय करने के लिए चलाता है। यह सभी BaseApp प्रबंधकों को एक दूसरे के साथ संवाद करने की अनुमति देता है।

यह टैंक अंदर से कैसा दिखता है, अगर बहुत संक्षेप में:

• ग्राहक इंटरनेट से जुड़ते हैं, LoginApp पर प्राप्त करते हैं।
• LoginApp DBApp का उपयोग करके उन्हें अधिकृत करता है और BaseApp से एक पता जारी करता है।
• आगे ग्राहक उन पर खेलते हैं।

यह सब कई मशीनों में बिखरा हुआ है, जिनमें से प्रत्येक में BWMachineD है, जो यह सब, ऑर्केस्ट्रा, आदि का प्रबंधन कर सकता है।

टैंक पारिस्थितिकी तंत्र की दुनिया

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

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

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

प्रमुख प्रौद्योगिकी और प्रोटोकॉल:

1. पायथन 2.7, 3.5;

2. एरलांग;

3. स्केला;

4. जावास्क्रिप्ट;

चौखटे:

5. Django;

6. बाज़;

7. एसिंसीओ;

गोदाम:

8. पोस्टग्रेट्स;

9. पर्कोना।

10. कैशिंग के लिए मेमकाटेड और रेडिस।

खिलाड़ी के लिए सभी एक साथ यह टैंक सर्वर है:

• प्राधिकरण का एकल बिंदु;
• चैट;
• कुलों;
• भुगतान प्रणाली;
• टूर्नामेंट प्रणाली;
• मेटा गेम्स (वैश्विक मानचित्र, फोर्टिफाइड क्षेत्र);
• टैंक पोर्टल, कबीले पोर्टल;
• सामग्री प्रबंधन आदि

लेकिन अगर आप देखें, तो ये अलग-अलग तकनीकों पर लिखी गई कुछ अलग चीजें हैं। यह कुछ विश्वसनीयता समस्याओं का कारण बनता है।



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

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

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

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

हमारे पास कई क्लस्टर हैं - ऐसा हुआ - मैं आपको बताऊंगा कि क्यों। यह सीआईएस क्षेत्र जैसा दिखता है।



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

यह वही है जो विश्व का पारिस्थितिक तंत्र दिखता है।

इस सारी अर्थव्यवस्था में क्या गलत हो सकता है? कुछ भी आप चाहते हैं! और जाता है जे। लेकिन चलो इसे अलग ले लो।

एक क्लस्टर के भीतर विफलता के प्रमुख बिंदु

एक मशीन या प्रक्रिया की विफलता

सबसे सरल विकल्प जिसकी हम भविष्यवाणी कर सकते हैं वह है क्लस्टर के भीतर एक मशीन या प्रक्रिया की विफलता। हमारे पास 10 से 100 कारों के क्लस्टर हैं - कुछ उड़ सकते हैं। जैसा कि मैंने कहा, बिगवर्ल्ड खुद को बॉक्स तंत्र से बाहर प्रदान करता है जो हमें अधिक विश्वसनीय होने की अनुमति देता है।



स्टैंडर्ड स्कीम: बेसऐप्स हैं जो विभिन्न मशीनों में फैले हुए हैं। इन BaseApp पर ऐसी इकाइयाँ होती हैं जिनमें राज्य इकाइयाँ होती हैं। प्रत्येक BaseApp दूसरों पर राउंड रॉबिन के साथ खुद को बैकअप देता है।

मान लीजिए कि हमारे पास एक फ़ाइल थी और कुछ BaseApp मर गए, या पूरी मशीन मर गई - यह ठीक है! शेष BaseApps ने इन संस्थाओं को छोड़ दिया, उन्हें बहाल किया जाएगा, और खिलाड़ी के लिए गेमप्ले को नुकसान नहीं होगा।



CellAPPs बिल्कुल एक ही काम करते हैं, केवल एक चीज यह है कि वे अपने राज्यों को BaseApps पर संग्रहीत करते हैं, और अन्य CellAPPs पर नहीं।

यह एक विश्वसनीय तंत्र लगता है, लेकिन ...

आपको हर चीज के लिए भुगतान करना होगा

समय के साथ, हम निम्नलिखित निरीक्षण करने लगे।

• संस्थाओं की बैकअप प्रतियाँ बनाना अधिक से अधिक सिस्टम संसाधनों और नेटवर्क ट्रैफ़िक को लेना शुरू करता है।

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

• संस्थाओं का आकार समय के साथ बढ़ता है, क्योंकि नई विशेषताओं और गेम मैकेनिक्स को जोड़ा जाता है।

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

• सिस्टम की स्थिरता समग्र रूप से घट जाती है

इस तथ्य के कारण कि हम एक मशीन या प्रक्रिया के पतन से बचने की कोशिश कर रहे हैं, हम पूरी प्रणाली की स्थिरता को छोड़ देते हैं।

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

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

डेटा सेंटर की विफलता। मल्टी क्लस्टर

यदि अचानक 1-2 कारें नहीं गिरती हैं, और हमने पूरे डेटा सेंटर को खोना शुरू कर दिया है, यानी पूरी तरह से क्लस्टर, खेल में ऐसी स्थिति में न पड़ने के लिए सिस्टम के पास क्या गुण होना चाहिए?

• प्रत्येक क्लस्टर स्वतंत्र होना चाहिए, जो है:
  
  1. अपना स्वयं का डेटाबेस होना चाहिए;
  2. क्लस्टर केवल इसके रिक्त स्थान (लड़ाई एरेनास) को संसाधित करता है।
  इस प्रकार, अगर कुछ एरेनास हिट होते हैं, तो अन्य अभी भी काम करते हैं।
• समूहों को एक दूसरे के साथ संवाद करना चाहिए ताकि कोई दूसरे से कह सके: "मैं गिर गया!" जब यह बढ़ जाता है, तो डेटा को सहेजे गए प्रतियों से पुनर्स्थापित किया जाएगा।
• यह भी वांछनीय है कि आप उपयोगकर्ता को क्लस्टर से क्लस्टर में स्थानांतरित कर सकते हैं।

फिलहाल, हमारे मल्टी-क्लस्टर की योजना इस तरह दिखती है।



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

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

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

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

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

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

उदाहरण के लिए, पहले एक लड़ाई बनाने के लिए, केंद्रीय क्लस्टर को यह बताना आवश्यक था कि कुछ परिधि पर एक लड़ाई बनाने के लिए आवश्यक था। इसके अलावा, आंतरिक तंत्र द्वारा, निकाय चले गए, अखाड़े का सार बनाया गया, आदि।

अब केंद्रीय क्लस्टर को दरकिनार करते हुए, परिधि से सीधे संपर्क करना संभव है। इसलिए हम उससे अतिरिक्त काम निकालते हैं। लेकिन अभी तक ऐसी योजना को पूरी तरह से बंद करने की कोई इच्छा नहीं है, जिसमें सभी क्लस्टर लगभग सहकर्मी से सहकर्मी हों, और यह सब कुछ प्रक्रियाओं द्वारा नियंत्रित होता है, लेकिन क्लस्टर नहीं।

मैं आपको याद दिलाता हूं कि इसके BaseApps, CellApps और अन्य के साथ गेम क्लस्टर के अलावा, हमारे पास एक पारिस्थितिकी तंत्र है।



हम यह सुनिश्चित करने की कोशिश करते हैं कि पारिस्थितिकी तंत्र का प्रदर्शन गेमप्ले को प्रभावित नहीं करता है। सबसे खराब स्थिति में, उदाहरण के लिए, टूर्नामेंट सिस्टम काम नहीं करता है, लेकिन आप यादृच्छिक में खेल सकते हैं - वैसे भी, ज्यादातर लोग यादृच्छिक में खेलते हैं। हां, हमने गुणवत्ता को कम किया है, लेकिन सामान्य तौर पर, आप टूर्नामेंट के बिना कई घंटों तक जीवित रह सकते हैं।

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

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

टैंक पारिस्थितिकी तंत्र की विफलता की दुनिया

समस्या संख्या 1. बढ़ा हुआ भार

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

इंटरफ़ेस अन्तरक्रियाशीलता और प्रतिक्रियाशीलता, पारिस्थितिक तंत्र में वृद्धि का मुख्य स्रोत है।

मैं कबीले सेवा से दो उदाहरण दूंगा:

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

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

इसे कैसे संभालना है, इस पर मेरी व्यक्तिगत सलाह: सिस्टम को लोड के तहत अधिक विश्वसनीय बनाने का सबसे अच्छा तरीका यह है कि आम तौर पर किसी तरह से लोड को कम किया जाए।

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

यदि आप ध्यान से सोचते हैं, तो वे बस से बचा जा सकता है।

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

— Web-sockets (nginx-pushstream) . , Web-sockets. , Chromium Embedded Framework — , , Web-sockets Nginx. pushstream, Web-sockets .

№ 2.

, , , — . , , — . , , .

? : - , - , , . - , , . .

.



, 120 Game Play . . , , . , . .



3 , :

1. HTTP API;
2. RabbitMQ — ;
3. Apache Kafka .

, , , , , . , - — , . , .



1. HTTP

— HTTP. , , -, . :

• ( , ).
  

, , . , , , Django, 100 200 , API, . , , - 30-40 , , . , — .

• .
  

, , HTTP, — . . — — . , , , , .

• .
  

. . - , - API — API, .

— , . , , . , 10 , - 100 500. , HTTP . nginx' , — .

, HTTP , .

2. RabbitMQ

RabbitMQ BigWord .

• .
  

— - , , , .

• «», , .
  

: . , API: « N — ». , , , , — . , .

«», «», — .

• .
  

RabbitMQ , , , , , , , .

— RabbitMQ .

3. Kafka

, , — Kafka. , RabbitMQ - .

• .
  

, , , . , , . . Kafka. , — , .

• .
  

, . , , - — .

Kafka , , , - , . .

— .



:

• . , - , ..
• — , , , .
• — , . , , .

. , , , entity. . , , .

DLC

, DLC (Development Lifecycle) — , , .



, , . DLC , , . , . , , , .

DLC, . , , , .

DLC, , :

• ( ).

, , «- , », . , , , , .

• : SRE.

, solution-, technical-owner, reability- — , - , game- . , , , . - , , , , . , .

• SRE .

— - . , . , SRE -. SRE , : « , , , — !» , .

QA , , - , , — .

BigWorld Technology «» . , . . « », .

« » , , . — «» (, ) — . , . , - .

: ++. , 40 , . रिपोर्ट के अंत में और सुनो, शायद आप पहलुओं में रुचि रखते थे।

रुटकॉन्फ कॉन्फ्रेंस रीब्रांडिंग से गुजर रही है - अब यह DevOpsConf रूस है । हमने मॉस्को में 1 और 2 अक्टूबर को इन्फोपेस में देवओप्स पर एक अलग पेशेवर सम्मेलन आयोजित करने का फैसला किया । हम उन सभी विषयों पर चर्चा करने की योजना बनाते हैं जो सूचना प्रणाली विशेषज्ञों के लिए प्रासंगिक हैं। देखें कि कार्यक्रम समिति को प्राप्त रिपोर्ट के लिए किस प्रकार के आवेदन हैं - चुनने के लिए बहुत सारे हैं!