मिखाईल सालोसिन. गोलंग भेट. लुक+ ऍप्लिकेशनच्या बॅकएंडमध्ये गो वापरणे

मिखाईल सलोसिन (यापुढे - एमएस): - सर्वांना नमस्कार! माझे नाव मायकल आहे. मी MC2 सॉफ्टवेअरमध्ये बॅकएंड डेव्हलपर म्हणून काम करतो आणि मी लुक+ मोबाइल ऍप्लिकेशनच्या बॅकएंडमध्ये गो वापरण्याबद्दल बोलेन.

इथे कोणाला हॉकी आवडते का?

मग हा अनुप्रयोग तुमच्यासाठी आहे. हे Android आणि iOS साठी आहे आणि विविध क्रीडा स्पर्धांचे ऑनलाइन आणि रेकॉर्ड केलेले प्रसारण पाहण्यासाठी वापरले जाते. ऍप्लिकेशनमध्ये विविध आकडेवारी, मजकूर प्रसारण, परिषदांसाठी टेबल, स्पर्धा आणि चाहत्यांसाठी उपयुक्त असलेली इतर माहिती देखील आहे.

तसेच अॅप्लिकेशनमध्ये व्हिडिओ मोमेंट्स सारखी गोष्ट आहे, म्हणजे तुम्ही मॅचचे सर्वात महत्वाचे क्षण (गोल, मारामारी, शूटआउट्स इ.) पाहू शकता. आपण संपूर्ण प्रसारण पाहू इच्छित नसल्यास, आपण फक्त सर्वात मनोरंजक पाहू शकता.

आपण विकासात काय वापरले?

मुख्य भाग गो मध्ये लिहिला होता. मोबाइल क्लायंट ज्या API सोबत संप्रेषण करतात ते Go मध्ये लिहिलेले होते. मोबाईल फोनवर पुश नोटिफिकेशन पाठवण्याची सेवा देखील गो मध्ये लिहिलेली होती. आम्हाला आमचे स्वतःचे ORM देखील लिहायचे होते, ज्याबद्दल आम्ही एखाद्या दिवशी बोलू शकतो. बरं, गो मध्ये काही छोट्या सेवा लिहिल्या होत्या: संपादकांसाठी प्रतिमांचा आकार बदलणे आणि लोड करणे...

आम्ही डेटाबेस म्हणून PostgreSQL वापरले. ActiveAdmin रत्न वापरून संपादक इंटरफेस Ruby on Rails मध्ये लिहिला होता. सांख्यिकी प्रदात्याकडून आकडेवारी आयात करणे देखील रुबीमध्ये लिहिलेले आहे.

सिस्टम API चाचण्यांसाठी, आम्ही Python unittest वापरले. Memcached चा वापर API पेमेंट कॉल थ्रॉटल करण्यासाठी केला जातो, "शेफ" कॉन्फिगरेशन नियंत्रित करण्यासाठी वापरला जातो, Zabbix चा वापर अंतर्गत सिस्टम आकडेवारी गोळा आणि निरीक्षण करण्यासाठी केला जातो. ग्रेलॉग2 हे लॉग गोळा करण्यासाठी आहे, स्लेट क्लायंटसाठी API दस्तऐवजीकरण आहे.

प्रोटोकॉल निवड

आम्हाला आलेली पहिली समस्या: आम्हाला खालील मुद्द्यांवर आधारित, बॅकएंड आणि मोबाइल क्लायंटमधील परस्परसंवादासाठी प्रोटोकॉल निवडणे आवश्यक आहे...

• सर्वात महत्वाची आवश्यकता: क्लायंटवरील डेटा रिअल टाइममध्ये अद्यतनित करणे आवश्यक आहे. म्हणजेच, सध्या ब्रॉडकास्ट पाहत असलेल्या प्रत्येकाला जवळजवळ त्वरित अपडेट्स मिळायला हवेत.
• गोष्टी सुलभ करण्यासाठी, आम्ही गृहीत धरले की क्लायंटसह समक्रमित केलेला डेटा हटविला जात नाही, परंतु विशेष ध्वजांचा वापर करून लपविला जातो.
• सर्व प्रकारच्या दुर्मिळ विनंत्या (जसे की आकडेवारी, संघ रचना, संघ आकडेवारी) सामान्य GET विनंत्यांद्वारे प्राप्त केल्या जातात.
• शिवाय, सिस्टमला एकाच वेळी 100 हजार वापरकर्त्यांना सहजपणे समर्थन द्यावे लागले.

यावर आधारित, आमच्याकडे दोन प्रोटोकॉल पर्याय होते:

1. वेबसॉकेट्स. परंतु आम्हाला क्लायंटपासून सर्व्हरपर्यंत चॅनेलची आवश्यकता नव्हती. आम्हाला फक्त सर्व्हरवरून क्लायंटला अद्यतने पाठवायची होती, म्हणून वेबसॉकेट हा एक अनावश्यक पर्याय आहे.
2. सर्व्हर-सेंड इव्हेंट्स (SSE) अगदी बरोबर आले! हे अगदी सोपे आहे आणि मुळात आपल्याला आवश्यक असलेल्या प्रत्येक गोष्टीचे समाधान करते.

सर्व्हर-पाठवलेले कार्यक्रम

ही गोष्ट कशी कार्य करते याबद्दल काही शब्द...

हे http कनेक्शनच्या वर चालते. क्लायंट विनंती पाठवतो, सर्व्हर सामग्री-प्रकार: मजकूर/इव्हेंट-स्ट्रीमसह प्रतिसाद देतो आणि क्लायंटसह कनेक्शन बंद करत नाही, परंतु कनेक्शनवर डेटा लिहिणे सुरू ठेवतो:

क्लायंटसह मान्य केलेल्या फॉरमॅटमध्ये डेटा पाठवला जाऊ शकतो. आमच्या बाबतीत, आम्ही ते या फॉर्ममध्ये पाठवले: बदललेल्या संरचनेचे नाव (व्यक्ती, खेळाडू) इव्हेंट फील्डवर पाठवले गेले आणि प्लेअरसाठी नवीन, बदललेल्या फील्डसह JSON डेटा फील्डवर पाठवले गेले.

आता संवाद स्वतःच कसा कार्य करतो याबद्दल बोलूया.

• क्लायंटने केलेली पहिली गोष्ट म्हणजे सेवेसह शेवटचे सिंक्रोनाइझेशन कधी केले गेले हे निर्धारित करते: तो त्याचा स्थानिक डेटाबेस पाहतो आणि त्याच्याद्वारे रेकॉर्ड केलेल्या शेवटच्या बदलाची तारीख ठरवतो.
• ते या तारखेसह विनंती पाठवते.
• प्रतिसादात, आम्ही त्याला त्या तारखेपासून घडलेल्या सर्व अपडेट्स पाठवतो.
• त्यानंतर, ते थेट चॅनेलशी कनेक्शन बनवते आणि या अद्यतनांची आवश्यकता होईपर्यंत बंद होत नाही:

आम्ही त्याला बदलांची यादी पाठवतो: जर एखाद्याने गोल केला, तर आम्ही सामन्याचा स्कोअर बदलतो, जर तो जखमी झाला तर हे देखील रिअल टाइममध्ये पाठवले जाते. अशा प्रकारे, क्लायंटला मॅच इव्हेंट फीडमध्ये तात्काळ अद्ययावत डेटा प्राप्त होतो. वेळोवेळी, जेणेकरून क्लायंटला समजेल की सर्व्हरचा मृत्यू झाला नाही, त्याला काहीही झाले नाही, आम्ही दर 15 सेकंदांनी एक टाइमस्टॅम्प पाठवतो - जेणेकरून त्याला कळेल की सर्व काही व्यवस्थित आहे आणि पुन्हा कनेक्ट करण्याची आवश्यकता नाही.

थेट कनेक्शनची सेवा कशी केली जाते?

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

आम्हाला समोर आलेली पहिली समस्या खालीलप्रमाणे होती: क्लायंटसह उघडलेल्या प्रत्येक कनेक्शनसाठी, आम्ही एक टायमर तयार केला जो प्रत्येक 15 सेकंदात एकदा टिकला - असे दिसून आले की जर आमच्याकडे एका मशीनसह (एका API सर्व्हरसह) 6 हजार कनेक्शन उघडले असतील तर 6. हजार टाइमर तयार केले. यामुळे मशीन आवश्यक भार धारण करत नाही. समस्या आमच्यासाठी स्पष्ट नव्हती, परंतु आम्हाला थोडी मदत मिळाली आणि त्याचे निराकरण केले.

परिणामी, आता आमचे पिंग त्याच चॅनेलवरून येते ज्यावरून अपडेट येते.

त्यानुसार, एकच टायमर आहे जो दर 15 सेकंदात एकदा टिकतो.

येथे अनेक सहाय्यक कार्ये आहेत - शीर्षलेख, पिंग आणि रचना स्वतः पाठवणे. म्हणजेच, टेबलचे नाव (व्यक्ती, सामना, हंगाम) आणि या नोंदीबद्दलची माहिती येथे प्रसारित केली जाते:

अद्यतने पाठविण्याची यंत्रणा

आता बदल कुठून येतात याबद्दल थोडेसे. आमच्याकडे अनेक लोक, संपादक आहेत जे रिअल टाइममध्ये प्रसारण पाहतात. ते सर्व इव्हेंट तयार करतात: कोणाला पाठवले गेले, कोणी जखमी झाले, कोणीतरी बदली ...

CMS वापरून, डेटा डेटाबेसमध्ये प्रवेश करतो. यानंतर, डेटाबेस ऐका/सूचना यंत्रणा वापरून API सर्व्हरला याबद्दल सूचित करतो. API सर्व्हर आधीच ही माहिती क्लायंटला पाठवत आहेत. अशा प्रकारे, आमच्याकडे मूलत: काही सर्व्हर डेटाबेसशी कनेक्ट केलेले आहेत आणि डेटाबेसवर कोणतेही विशेष भार नाही, कारण क्लायंट डेटाबेसशी कोणत्याही प्रकारे थेट संवाद साधत नाही:

PostgreSQL: ऐका/सूचना द्या

Postgres मधील Listen/Notify यंत्रणा तुम्हाला इव्हेंट सदस्यांना सूचित करण्याची परवानगी देते की काही इव्हेंट बदलला आहे - डेटाबेसमध्ये काही रेकॉर्ड तयार केले गेले आहेत. हे करण्यासाठी, आम्ही एक साधे ट्रिगर आणि फंक्शन लिहिले:

रेकॉर्ड टाकताना किंवा बदलताना, आम्ही data_updates चॅनेलवर सूचना फंक्शनला कॉल करतो, तिथे टेबलचे नाव आणि बदललेल्या किंवा घातलेल्या रेकॉर्डचा अभिज्ञापक देतो.

क्लायंटसह समक्रमित करणे आवश्यक असलेल्या सर्व सारण्यांसाठी, आम्ही एक ट्रिगर परिभाषित करतो, जो रेकॉर्ड बदलल्यानंतर / अद्यतनित केल्यानंतर, खालील स्लाइडवर दर्शविलेल्या फंक्शनला कॉल करतो.
API या बदलांचे सदस्यत्व कसे घेते?

फॅनआउट यंत्रणा तयार केली जाते - ती क्लायंटला संदेश पाठवते. हे सर्व ग्राहक चॅनेल संकलित करते आणि या चॅनेलद्वारे प्राप्त झालेली अद्यतने पाठवते:

येथे मानक pq लायब्ररी, जी डेटाबेसला जोडते आणि म्हणते की ते चॅनेल (डेटा_अपडेट्स) ऐकू इच्छित आहे, कनेक्शन खुले आहे आणि सर्वकाही ठीक आहे हे तपासते. मी जागा वाचवण्यासाठी त्रुटी तपासणे वगळत आहे (तपासणे धोकादायक नाही).

पुढे, आम्ही असिंक्रोनसपणे टिकर सेट करतो, जो प्रत्येक 15 सेकंदाला एक पिंग पाठवेल आणि आम्ही सदस्यता घेतलेले चॅनेल ऐकण्यास सुरुवात करेल. आम्हाला पिंग मिळाल्यास, आम्ही हे पिंग प्रकाशित करतो. जर आम्हाला काही प्रकारची एंट्री मिळाली, तर आम्ही ही एंट्री या फॅनआउटच्या सर्व सदस्यांसाठी प्रकाशित करतो.

फॅन-आउट कसे कार्य करते?

रशियन भाषेत याचे भाषांतर “स्प्लिटर” असे केले जाते. आमच्याकडे एक वस्तू आहे जी काही अद्यतने प्राप्त करू इच्छिणाऱ्या सदस्यांची नोंदणी करते. आणि या ऑब्जेक्टवर अपडेट येताच, ते हे अपडेट त्याच्या सर्व सदस्यांना वितरित करते. पुरेसे सोपे:

Go मध्ये ते कसे लागू केले जाते:

एक रचना आहे, ती Mutexes वापरून सिंक्रोनाइझ केली जाते. त्यात एक फील्ड आहे जे फॅनआउटच्या कनेक्शनची स्थिती डेटाबेसशी जतन करते, म्हणजे ते सध्या ऐकत आहे आणि अद्यतने प्राप्त करेल, तसेच सर्व उपलब्ध चॅनेलची सूची - नकाशा, ज्याची की चॅनेल आणि रचना आहे मूल्ये (मूलत: ते कोणत्याही प्रकारे वापरले जात नाही).

दोन पद्धती - कनेक्ट केलेले आणि डिस्कनेक्ट केलेले - आम्हाला फॅनआउटला सांगण्याची परवानगी देतात की आमचे बेसशी कनेक्शन आहे, ते दिसून आले आहे आणि बेसशी कनेक्शन तुटले आहे. दुस-या प्रकरणात, तुम्हाला सर्व क्लायंट डिस्कनेक्ट करणे आवश्यक आहे आणि त्यांना सांगणे आवश्यक आहे की ते यापुढे काहीही ऐकू शकत नाहीत आणि ते पुन्हा कनेक्ट झाले कारण त्यांचे कनेक्शन बंद झाले आहे.

एक सदस्यता पद्धत देखील आहे जी चॅनेलला "श्रोत्यांना" जोडते:

एक अनसबस्क्राइब पद्धत आहे, जी क्लायंट डिस्कनेक्ट झाल्यास श्रोत्यांकडून चॅनेल काढून टाकते, तसेच एक प्रकाशन पद्धत आहे, जी तुम्हाला सर्व सदस्यांना संदेश पाठविण्याची परवानगी देते.

प्रश्न: - या चॅनेलद्वारे काय प्रसारित केले जाते?

एमएस: - बदललेले मॉडेल किंवा पिंग प्रसारित केले जाते (मूलत: फक्त एक संख्या, पूर्णांक).

एमएस: - तुम्ही काहीही पाठवू शकता, कोणतीही रचना पाठवू शकता, प्रकाशित करू शकता - ते फक्त JSON मध्ये बदलते आणि तेच.

एमएस: - आम्हाला पोस्टग्रेस कडून एक सूचना प्राप्त होते - त्यात टेबलचे नाव आणि अभिज्ञापक आहे. सारणीचे नाव आणि अभिज्ञापकाच्या आधारावर, आम्हाला आवश्यक असलेले रेकॉर्ड मिळते आणि नंतर आम्ही ही रचना प्रकाशनासाठी पाठवतो.

पायाभूत सुविधा

पायाभूत सुविधांच्या दृष्टीकोनातून हे कसे दिसते? आमच्याकडे 7 हार्डवेअर सर्व्हर आहेत: त्यापैकी एक पूर्णपणे डेटाबेसला समर्पित आहे, इतर सहा आभासी मशीन चालवतात. API च्या 6 प्रती आहेत: API सह प्रत्येक आभासी मशीन वेगळ्या हार्डवेअर सर्व्हरवर चालते - हे विश्वासार्हतेसाठी आहे.

प्रवेशयोग्यता सुधारण्यासाठी आमच्याकडे Keepalived सह दोन फ्रंटएंड स्थापित केले आहेत, जेणेकरून काही घडल्यास, एक फ्रंटएंड दुसरा बदलू शकेल. तसेच - CMS च्या दोन प्रती.

एक सांख्यिकी आयातदार देखील आहे. एक डीबी स्लेव्ह आहे ज्यामधून वेळोवेळी बॅकअप घेतले जातात. पिजन पुशर, एक ऍप्लिकेशन आहे जो क्लायंटना पुश नोटिफिकेशन्स पाठवतो, तसेच पायाभूत सुविधा: Zabbix, Graylog2 आणि Chef.

खरं तर, ही पायाभूत सुविधा अनावश्यक आहे, कारण कमी सर्व्हरसह 100 हजार सेवा दिली जाऊ शकतात. पण लोखंड होते - आम्ही ते वापरले (आम्हाला सांगण्यात आले की ते शक्य आहे - का नाही).

गो चे फायदे

आम्ही या ऍप्लिकेशनवर काम केल्यानंतर, Go चे असे स्पष्ट फायदे समोर आले.

• छान http लायब्ररी. त्याद्वारे तुम्ही बॉक्सच्या बाहेर बरेच काही तयार करू शकता.
• शिवाय, चॅनेल ज्याने आम्हाला क्लायंटना सूचना पाठवण्याची यंत्रणा अगदी सहजपणे लागू करण्याची परवानगी दिली.
• आश्चर्यकारक गोष्ट म्हणजे रेस डिटेक्टरने आम्हाला अनेक गंभीर बग (स्टेजिंग इन्फ्रास्ट्रक्चर) दूर करण्याची परवानगी दिली. स्टेजिंगवर कार्य करणारी प्रत्येक गोष्ट लॉन्च केली जाते, रेस की सह संकलित केली जाते; आणि त्यानुसार, आम्हाला कोणत्या संभाव्य समस्या आहेत हे पाहण्यासाठी आम्ही स्टेजिंग इन्फ्रास्ट्रक्चर पाहू शकतो.
• मिनिमलिझम आणि भाषेची साधेपणा.

आम्ही विकसक शोधत आहोत! कोणाला हवे असल्यास कृपया.

प्रश्न

श्रोत्यांकडून प्रश्न (यापुढे – बी): – मला असे वाटते की आपण फॅन-आउट संदर्भात एक महत्त्वाचा मुद्दा गमावला आहे. जेव्हा तुम्ही क्लायंटला प्रतिसाद पाठवता तेव्हा क्लायंट वाचू इच्छित नसल्यास तुम्ही ब्लॉक करता हे मला समजण्यात बरोबर आहे का?

एमएस: - नाही, आम्ही अवरोधित करत नाही. प्रथम, आमच्याकडे हे सर्व nginx च्या मागे आहे, म्हणजे, हळू क्लायंटसह कोणतीही समस्या नाही. दुसरे म्हणजे, क्लायंटकडे बफर असलेले चॅनेल आहे - खरेतर, आम्ही तेथे शंभर अपडेट्स ठेवू शकतो... जर आम्ही चॅनेलवर लिहू शकत नाही, तर ते ते हटवते. जर आम्हाला चॅनल अवरोधित केले असल्याचे दिसले, तर आम्ही फक्त चॅनेल बंद करू आणि तेच आहे - कोणतीही समस्या उद्भवल्यास क्लायंट पुन्हा कनेक्ट करेल. म्हणून, तत्वतः, येथे कोणतेही अवरोध नाही.

मध्ये: - ऐकण्यासाठी/सूचना देण्यासाठी त्वरित रेकॉर्ड पाठवणे शक्य नाही आणि ओळखकर्ता टेबल नाही?

एमएस: - ऐका/सूचना पाठवलेल्या प्रीलोडवर 8 हजार बाइट्सची मर्यादा आहे. तत्वतः, जर आम्ही थोड्या प्रमाणात डेटा हाताळत असू तर ते पाठवणे शक्य होईल, परंतु मला असे वाटते की हा मार्ग [आम्ही ते करतो] अधिक विश्वासार्ह आहे. पोस्टग्रेसमध्येच मर्यादा आहेत.

मध्ये: - ग्राहकांना त्यांना स्वारस्य नसलेल्या सामन्यांबद्दल अपडेट मिळतात का?

एमएस: - सर्वसाधारणपणे, होय. नियमानुसार, समांतरपणे 2-3 सामने चालू आहेत आणि तरीही क्वचितच. जर एखादा क्लायंट काहीतरी पाहत असेल तर तो सहसा चालू असलेली मॅच पाहत असतो. त्यानंतर, क्लायंटकडे एक स्थानिक डेटाबेस आहे ज्यामध्ये ही सर्व अद्यतने जोडली जातात आणि इंटरनेट कनेक्शनशिवाय देखील, क्लायंट मागील सर्व सामने पाहू शकतो ज्यासाठी त्याच्याकडे अद्यतने आहेत. मूलत:, आम्ही आमचा डेटाबेस सर्व्हरवर क्लायंटच्या स्थानिक डेटाबेससह समक्रमित करतो जेणेकरून तो ऑफलाइन कार्य करू शकेल.

मध्ये: - तुम्ही तुमचे स्वतःचे ORM का बनवले?

अॅलेक्सी (लूक+ च्या विकसकांपैकी एक): - त्या वेळी (ते एक वर्षापूर्वीचे होते) आताच्या तुलनेत कमी ORM होते, जेव्हा त्यापैकी बरेच आहेत. बहुतेक ORM बद्दल माझी आवडती गोष्ट अशी आहे की त्यापैकी बहुतेक रिकाम्या इंटरफेसवर चालतात. म्हणजेच, या ORM मधील पद्धती काहीही स्वीकारण्यास तयार आहेत: एक रचना, एक रचना निर्देशक, एक संख्या, काहीतरी पूर्णपणे असंबद्ध...

आमचे ORM डेटा मॉडेलवर आधारित संरचना तयार करते. मी स्वतः. आणि म्हणून सर्व पद्धती ठोस आहेत, परावर्तन वगैरे वापरू नका. ते स्ट्रक्चर्स स्वीकारतात आणि येणाऱ्या स्ट्रक्चर्स वापरण्याची अपेक्षा करतात.

मध्ये: - किती लोकांनी भाग घेतला?

एमएस: - सुरुवातीच्या टप्प्यावर, दोन लोकांनी भाग घेतला. आम्ही जूनमध्ये कुठेतरी सुरुवात केली आणि ऑगस्टमध्ये मुख्य भाग तयार झाला (पहिली आवृत्ती). सप्टेंबरमध्ये रिलीज झाला होता.

मध्ये: - जिथे तुम्ही SSE चे वर्णन करता तिथे तुम्ही कालबाह्य वापरत नाही. अस का?

एमएस: – खरे सांगायचे तर, SSE अजूनही एक html5 प्रोटोकॉल आहे: SSE मानक ब्राउझरशी संप्रेषण करण्यासाठी डिझाइन केलेले आहे, मला समजते. यात अतिरिक्त वैशिष्ट्ये आहेत ज्यामुळे ब्राउझर पुन्हा कनेक्ट होऊ शकतात (आणि असेच), परंतु आम्हाला त्यांची आवश्यकता नाही, कारण आमच्याकडे असे क्लायंट होते जे कनेक्ट करण्यासाठी आणि माहिती प्राप्त करण्यासाठी कोणतेही तर्क लागू करू शकतात. आम्ही SSE बनवले नाही, तर SSE सारखेच काहीतरी केले. हा स्वतः प्रोटोकॉल नाही.
गरज नव्हती. माझ्या समजल्याप्रमाणे, क्लायंटने कनेक्शन यंत्रणा अगदी सुरवातीपासून लागू केली. त्यांना खरोखर काळजी नव्हती.

मध्ये: - तुम्ही कोणत्या अतिरिक्त उपयुक्तता वापरल्या?

एमएस: - आम्ही सर्वात सक्रियपणे गोव्हेट आणि गोलिंटचा वापर शैली एकत्रित करण्यासाठी तसेच gofmt करण्यासाठी केला. इतर काहीही वापरले नाही.

मध्ये: - तुम्ही डीबग करण्यासाठी काय वापरले?

एमएस: - डीबगिंग मोठ्या प्रमाणावर चाचण्या वापरून केले गेले. आम्ही कोणताही डीबगर किंवा GOP वापरला नाही.

मध्ये: – जेथे Publish फंक्शन लागू केले आहे ती स्लाइड तुम्ही परत करू शकता का? एकल-अक्षर व्हेरिएबल नावे तुम्हाला गोंधळात टाकतात?

एमएस: - नाही. त्यांच्याकडे दृश्यमानतेची "अरुंद" व्याप्ती आहे. ते येथे (या वर्गातील अंतर्गत भाग वगळता) इतरत्र कुठेही वापरले जात नाहीत आणि ते अतिशय संक्षिप्त आहे - यास फक्त 7 ओळी लागतात.

मध्ये: - कसे तरी ते अद्याप अंतर्ज्ञानी नाही ...

एमएस: - नाही, नाही, हे एक वास्तविक कोड आहे! हे शैलीबद्दल नाही. हा फक्त एक उपयुक्ततावादी, खूप लहान वर्ग आहे - वर्गात फक्त 3 फील्ड...

एमएस: - मोठ्या प्रमाणात, क्लायंटसह सिंक्रोनाइझ केलेला सर्व डेटा (सीझन सामने, खेळाडू) बदलत नाही. ढोबळपणे सांगायचे तर, जर आम्ही दुसरा खेळ केला ज्यामध्ये आम्हाला सामना बदलण्याची आवश्यकता आहे, तर आम्ही क्लायंटच्या नवीन आवृत्तीमध्ये सर्वकाही विचारात घेऊ आणि क्लायंटच्या जुन्या आवृत्त्यांवर बंदी घातली जाईल.

मध्ये: - कोणतेही तृतीय-पक्ष अवलंबित्व व्यवस्थापन पॅकेज आहेत का?

एमएस: - आम्ही go dep वापरले.

मध्ये: - अहवालाच्या विषयात व्हिडिओबद्दल काहीतरी होते, परंतु व्हिडिओबद्दल अहवालात काहीही नव्हते.

एमएस: - नाही, माझ्याकडे व्हिडिओबद्दलच्या विषयात काहीही नाही. याला “Look+” असे म्हणतात - ते अनुप्रयोगाचे नाव आहे.

मध्ये: - तुम्ही म्हणाल की ते क्लायंटसाठी प्रवाहित केले आहे? ..

एमएस: - आम्ही व्हिडिओ स्ट्रीमिंगमध्ये सहभागी नव्हतो. हे संपूर्णपणे मेगाफोनने केले होते. होय, मी असे म्हटले नाही की अनुप्रयोग मेगाफोन आहे.

एमएस: – जा – सर्व डेटा पाठवण्यासाठी – स्कोअरवर, मॅच इव्हेंट्सवर, आकडेवारीवर... गो हे ऍप्लिकेशनसाठी संपूर्ण बॅकएंड आहे. क्लायंटला कुठूनतरी खेळाडूसाठी कोणती लिंक वापरायची हे माहित असणे आवश्यक आहे जेणेकरून वापरकर्ता सामना पाहू शकेल. आमच्याकडे तयार केलेल्या व्हिडिओ आणि प्रवाहांचे दुवे आहेत.

काही जाहिराती 🙂

आमच्यासोबत राहिल्याबद्दल धन्यवाद. तुम्हाला आमचे लेख आवडतात का? अधिक मनोरंजक सामग्री पाहू इच्छिता? ऑर्डर देऊन किंवा मित्रांना शिफारस करून आम्हाला समर्थन द्या, $4.99 पासून विकसकांसाठी क्लाउड VPS, एंट्री-लेव्हल सर्व्हरचे एक अद्वितीय अॅनालॉग, जे तुमच्यासाठी आमच्याद्वारे शोधले गेले आहे: VPS (KVM) E5-2697 v3 (6 Cores) 10GB DDR4 480GB SSD 1Gbps बद्दल संपूर्ण सत्य $19 पासून किंवा सर्व्हर कसा शेअर करायचा? (RAID1 आणि RAID10 सह उपलब्ध, 24 कोर पर्यंत आणि 40GB DDR4 पर्यंत).

डेल R730xd ऍमस्टरडॅममधील इक्विनिक्स टियर IV डेटा सेंटरमध्ये 2 पट स्वस्त? फक्त इथेच 2 x इंटेल टेट्राडेका-कोर Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीव्ही $199 पासून नेदरलँड मध्ये! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 पासून! बद्दल वाचा इन्फ्रास्ट्रक्चर कॉर्पोरेशन कसे तयार करावे. डेल R730xd E5-2650 v4 सर्व्हरचा वापर करून 9000 युरो किमतीचा वर्ग?

स्त्रोत: www.habr.com