🥇मिखाइल सैलोसिन। गोलांग मीटअप। लुक+ एप्लिकेशन के बैकएंड में गो का उपयोग करना

मिखाइल सलोसिन (इसके बाद - एमएस): - नमस्ते! मेरा नाम माइकल है। मैं एमसी2 सॉफ्टवेयर में बैकएंड डेवलपर के रूप में काम करता हूं, और मैं लुक+ मोबाइल एप्लिकेशन के बैकएंड में गो का उपयोग करने के बारे में बात करूंगा।

क्या यहाँ किसी को हॉकी पसंद है?

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

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

आपने विकास में क्या उपयोग किया?

मुख्य भाग गो में लिखा गया था। मोबाइल क्लाइंट जिस एपीआई से संचार करते थे वह गो में लिखा गया था। गो में मोबाइल फोन पर पुश नोटिफिकेशन भेजने की एक सेवा भी लिखी गई थी। हमें अपना स्वयं का ORM भी लिखना था, जिसके बारे में हम किसी दिन बात कर सकते हैं। खैर, कुछ छोटी सेवाएँ गो में लिखी गईं: संपादकों के लिए छवियों का आकार बदलना और लोड करना...

हमने डेटाबेस के रूप में PostgreSQL का उपयोग किया। संपादक इंटरफ़ेस ActiveAdmin रत्न का उपयोग करके रूबी ऑन रेल्स में लिखा गया था। सांख्यिकी प्रदाता से आंकड़े आयात करना भी रूबी में लिखा गया है।

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

प्रोटोकॉल चयन

पहली समस्या जिसका हमें सामना करना पड़ा: हमें निम्नलिखित बिंदुओं के आधार पर बैकएंड और मोबाइल क्लाइंट के बीच बातचीत के लिए एक प्रोटोकॉल चुनने की आवश्यकता थी...

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

इसके आधार पर, हमारे पास दो प्रोटोकॉल विकल्प थे:

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

सर्वर-भेजे गए इवेंट

यह चीज़ कैसे काम करती है इसके बारे में कुछ शब्द...

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

डेटा ग्राहकों के साथ सहमत प्रारूप में भेजा जा सकता है। हमारे मामले में, हमने इसे इस रूप में भेजा: परिवर्तित संरचना (व्यक्ति, खिलाड़ी) का नाम इवेंट फ़ील्ड में भेजा गया था, और खिलाड़ी के लिए नए, परिवर्तित फ़ील्ड के साथ JSON डेटा फ़ील्ड में भेजा गया था।

अब आइए इस बारे में बात करें कि अंतःक्रिया स्वयं कैसे कार्य करती है।

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

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

लाइव कनेक्शन की सेवा कैसे की जाती है?

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

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

परिणामस्वरूप, अब हमारा पिंग उसी चैनल से आता है जिससे अपडेट आता है।

तदनुसार, केवल एक टाइमर है जो हर 15 सेकंड में एक बार टिक करता है।

यहां कई सहायक कार्य हैं - हेडर, पिंग और स्वयं संरचना भेजना। अर्थात्, तालिका का नाम (व्यक्ति, मैच, सीज़न) और इस प्रविष्टि के बारे में जानकारी यहाँ प्रसारित की जाती है:

अपडेट भेजने का तंत्र

अब थोड़ा इस बारे में कि परिवर्तन कहाँ से आते हैं। हमारे पास कई लोग, संपादक हैं, जो वास्तविक समय में प्रसारण देखते हैं। वे सभी घटनाएँ बनाते हैं: किसी को बाहर भेज दिया गया, कोई घायल हो गया, किसी प्रकार का प्रतिस्थापन...

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

PostgreSQL: सुनें/सूचित करें

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

किसी रिकॉर्ड को सम्मिलित या बदलते समय, हम data_updates चैनल पर नोटिफाई फ़ंक्शन को कॉल करते हैं, वहां तालिका का नाम और बदले गए या डाले गए रिकॉर्ड के पहचानकर्ता को पास करते हैं।

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

एक फैनआउट तंत्र बनाया गया है - यह क्लाइंट को संदेश भेजता है। यह सभी ग्राहक चैनलों को एकत्र करता है और इन चैनलों के माध्यम से प्राप्त अपडेट भेजता है:

यहां मानक पीक्यू लाइब्रेरी, जो डेटाबेस से जुड़ती है और कहती है कि वह चैनल (डेटा_अपडेट्स) सुनना चाहता है, जांचता है कि कनेक्शन खुला है और सब कुछ ठीक है। मैं स्थान बचाने के लिए त्रुटि जाँच को छोड़ रहा हूँ (जाँच न करना खतरनाक है)।

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

फैन-आउट कैसे काम करता है?

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

इसे गो में कैसे कार्यान्वित किया जाता है:

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

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

एक सदस्यता विधि भी है जो चैनल को "श्रोताओं" से जोड़ती है:

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

प्रश्न: – इस चैनल के माध्यम से क्या प्रसारित होता है?

एमएस: - जो मॉडल बदल गया है या पिंग प्रसारित हो गया है (अनिवार्य रूप से केवल एक संख्या, पूर्णांक)।

एमएस: - आप कुछ भी भेज सकते हैं, कोई भी संरचना भेज सकते हैं, इसे प्रकाशित कर सकते हैं - यह बस JSON में बदल जाता है और बस इतना ही।

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

इंफ्रास्ट्रक्चर

बुनियादी ढांचे के नजरिए से यह कैसा दिखता है? हमारे पास 7 हार्डवेयर सर्वर हैं: उनमें से एक पूरी तरह से डेटाबेस के लिए समर्पित है, अन्य छह वर्चुअल मशीनें चलाते हैं। एपीआई की 6 प्रतियां हैं: एपीआई वाली प्रत्येक वर्चुअल मशीन एक अलग हार्डवेयर सर्वर पर चलती है - यह विश्वसनीयता के लिए है।

पहुंच में सुधार के लिए हमारे पास कीपलाइव्ड के साथ दो फ्रंटएंड स्थापित हैं, ताकि अगर कुछ होता है, तो एक फ्रंटएंड दूसरे की जगह ले सके। साथ ही सी.एम.एस. की दो प्रतियाँ भी।

एक सांख्यिकी आयातक भी है. एक DB स्लेव है जिससे समय-समय पर बैकअप बनाया जाता है। पिजन पुशर, एक एप्लिकेशन है जो ग्राहकों को पुश नोटिफिकेशन भेजता है, साथ ही बुनियादी ढांचे की चीजें भी भेजता है: ज़ैबिक्स, ग्रेलॉग 2 और शेफ।

वास्तव में, यह बुनियादी ढांचा अनावश्यक है, क्योंकि कम सर्वर के साथ 100 हजार की सेवा की जा सकती है। लेकिन लोहा था - हमने इसका इस्तेमाल किया (हमें बताया गया कि यह संभव है - क्यों नहीं)।

गो के फायदे

जब हमने इस एप्लिकेशन पर काम किया तो गो के ऐसे स्पष्ट फायदे सामने आए।

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

हम डेवलपर्स की तलाश कर रहे हैं! अगर कोई चाहे तो कृपया.

सवाल

दर्शकों से प्रश्न (इसके बाद - बी): - मुझे ऐसा लगता है कि आप फैन-आउट के संबंध में एक महत्वपूर्ण बिंदु से चूक गए हैं। क्या मैं यह समझने में सही हूं कि जब आप किसी ग्राहक को प्रतिक्रिया भेजते हैं, तो यदि ग्राहक पढ़ना नहीं चाहता है तो आप उसे ब्लॉक कर देते हैं?

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

में: - क्या तुरंत सुनने/सूचित करने के लिए एक रिकॉर्ड भेजना संभव नहीं हो सकता है, न कि एक पहचानकर्ता तालिका?

एमएस: - लिसन/नोटिफाई में भेजे जाने वाले प्रीलोड पर 8 हजार बाइट्स की सीमा होती है। सिद्धांत रूप में, यदि हम थोड़ी मात्रा में डेटा के साथ काम कर रहे होते तो इसे भेजना संभव होता, लेकिन मुझे ऐसा लगता है कि यह तरीका [जिस तरह से हम इसे करते हैं] अधिक विश्वसनीय है। सीमाएँ Postgres में ही हैं।

में: - क्या ग्राहकों को उन मैचों के बारे में अपडेट प्राप्त होते हैं जिनमें उनकी रुचि नहीं है?

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

में: – आपने अपना खुद का ORM क्यों बनाया?

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

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

में: – कितने लोगों ने हिस्सा लिया?

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

में: - जहां आप एसएसई का वर्णन करते हैं, वहां आप टाइमआउट का उपयोग नहीं करते हैं। ऐसा क्यों?

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

में: – आपने किन अतिरिक्त उपयोगिताओं का उपयोग किया?

एमएस: - शैली को एकीकृत बनाने के लिए हमने सबसे सक्रिय रूप से गोवेट और गोलिंट का उपयोग किया, साथ ही गोफएमटी का भी। और कुछ भी उपयोग नहीं किया गया.

में: - आपने डिबग करने के लिए क्या उपयोग किया?

एमएस: - डिबगिंग बड़े पैमाने पर परीक्षणों का उपयोग करके की गई थी। हमने किसी डिबगर या जीओपी का उपयोग नहीं किया।

में: – क्या आप उस स्लाइड को वापस कर सकते हैं जहां पब्लिश फ़ंक्शन लागू किया गया है? क्या एकल-अक्षर वाले चर नाम आपको भ्रमित करते हैं?

एमएस: - नहीं। उनके पास दृश्यता का काफी "संकीर्ण" दायरा है। इनका उपयोग यहां के अलावा कहीं और नहीं किया जाता है (इस वर्ग के आंतरिक को छोड़कर), और यह बहुत कॉम्पैक्ट है - इसमें केवल 7 लाइनें लगती हैं।

में: - किसी तरह यह अभी भी सहज नहीं है...

एमएस: - नहीं, नहीं, यह एक वास्तविक कोड है! यह स्टाइल के बारे में नहीं है. यह एक ऐसा उपयोगितावादी, बहुत छोटा वर्ग है - वर्ग के अंदर केवल 3 फ़ील्ड...

एमएस: - कुल मिलाकर, क्लाइंट (सीज़न मैच, खिलाड़ी) के साथ सिंक्रनाइज़ किया गया सारा डेटा नहीं बदलता है। मोटे तौर पर कहें तो, अगर हम एक और खेल बनाते हैं जिसमें हमें मैच बदलने की ज़रूरत है, तो हम क्लाइंट के नए संस्करण में सब कुछ ध्यान में रखेंगे, और क्लाइंट के पुराने संस्करणों पर प्रतिबंध लगा दिया जाएगा।

में: - क्या कोई तृतीय-पक्ष निर्भरता प्रबंधन पैकेज हैं?

एमएस: - हमने गो डिपो का उपयोग किया।

में: - रिपोर्ट के विषय में वीडियो के बारे में कुछ था, लेकिन रिपोर्ट में वीडियो के बारे में कुछ भी नहीं था।

एमएस: - नहीं, मुझे वीडियो के विषय में कुछ भी जानकारी नहीं है। इसे "लुक+" कहा जाता है - यह एप्लिकेशन का नाम है।

में: - आपने कहा कि इसे ग्राहकों के लिए स्ट्रीम किया जाता है?

एमएस: - हम वीडियो स्ट्रीमिंग में शामिल नहीं थे। यह पूरी तरह से मेगफॉन द्वारा किया गया था। हां, मैंने यह नहीं कहा कि एप्लिकेशन मेगाफोन था।

एमएस: - गो - सभी डेटा भेजने के लिए - स्कोर पर, मैच की घटनाओं पर, आंकड़ों पर... गो एप्लिकेशन के लिए संपूर्ण बैकएंड है। क्लाइंट को कहीं न कहीं से पता होना चाहिए कि प्लेयर के लिए किस लिंक का उपयोग करना है ताकि उपयोगकर्ता मैच देख सके। हमारे पास तैयार किए गए वीडियो और स्ट्रीम के लिंक हैं।

कुछ विज्ञापन 🙂

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

एम्स्टर्डम में इक्विनिक्स टियर IV डेटा सेंटर में Dell R730xd 2x सस्ता है? केवल यहां 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 टीवी $199 से नीदरलैंड में! डेल R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 से! के बारे में पढ़ा इन्फ्रास्ट्रक्चर कॉर्प का निर्माण कैसे करें। एक पैसा के लिए 730 यूरो मूल्य के डेल R5xd E2650-4 v9000 सर्वर के उपयोग के साथ वर्ग?

स्रोत: www.habr.com

मिखाइल सलोसिन. गोलांग मीटअप। लुक+ एप्लिकेशन के बैकएंड में गो का उपयोग करना