😉 👍🏿 ☝🏿 मिखाइल सालोसिन। गोलंग मीटअप। वॉच + एप्लिकेशन के बैकेंड में गो का उपयोग करना 👳🏿 🌶️ 🗽

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

क्या कोई हॉकी की तरह मौजूद है?

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

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

विकास में क्या इस्तेमाल किया गया था?

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

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

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

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

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

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

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

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

सर्वर-प्रेषित ईवेंट

यह चीज़ कैसे काम

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

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

अब इस बारे में कि बातचीत कैसे काम करती है।

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

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

लाइव कनेक्शन कैसे परोसा जाता है?

सबसे पहले, हम एक चैनल बनाते हैं जिसमें एक बफर के साथ अपडेट आएगा।
उसके बाद, हम अपडेट प्राप्त करने के लिए इस चैनल की सदस्यता लेते हैं।
सही हेडर सेट करें ताकि क्लाइंट को पता चले कि सब कुछ ठीक है।
ping. timestamp .
, . timestamp, , .

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

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

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

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

अद्यतन भेजने के लिए तंत्र

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

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

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

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

रिकॉर्ड सम्मिलित करते या बदलते समय, हम data_updates चैनल पर सूचना फ़ंक्शन को कॉल करते हैं, तालिका का नाम और उस रिकॉर्ड के पहचानकर्ता को स्थानांतरित करते हैं जो वहां परिवर्तित या डाला गया था।

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

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

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

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

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

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

यह गो पर कैसे लागू किया जाता है:

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

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

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

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

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

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

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

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

भूमिकारूप व्यवस्था

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

हमारे पास दो दृष्टिकोण हैं, जिन तक पहुंच को बेहतर बनाने के लिए Keepalived स्थापित किया गया है, ताकि एक मामले में एक दृश्य दूसरे को प्रतिस्थापित कर सके। सीएमएस की एक और दो प्रतियां।

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

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

गो के पेशेवरों

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

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

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

प्रशन

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

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

प्रश्न: - क्या आप तुरंत रिकॉर्ड सुन सकते हैं / सूचित कर सकते हैं, पहचानकर्ता तालिका नहीं?

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

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

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

Q: - आपने अपना ORM क्यों बनाया?

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

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

Q: - कितने लोगों ने भाग लिया?

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

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

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

Q: - आपने किन अतिरिक्त उपयोगिताओं का उपयोग किया है?

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

Q: - आपने किसके साथ डेब्यू किया?

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

Q: - क्या आप वह स्लाइड वापस कर सकते हैं जहाँ प्रकाशित फ़ंक्शन कार्यान्वित किया जाता है? एकल-पत्र चर नाम आपको परेशान नहीं करते हैं?

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

प्रश्न: - किसी तरह यह अभी भी सहज नहीं है ...

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

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

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

MS: - हमने इस्तेमाल किया dep।

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

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

एटी:- आपने कहा कि आप ग्राहकों को स्ट्रीमिंग कर रहे हैं? ..

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

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

विज्ञापन का एक सा :)

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

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

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