मिखाइल सालोसिन। गोलाङ भेटघाट । लुक+ एप्लिकेसनको ब्याकइन्डमा गो प्रयोग गर्दै

मिखाइल सालोसिन (यसपछि - एमएस): - नमस्ते सबै! मेरो नाम माइकल हो। म MC2 सफ्टवेयरमा ब्याकएन्ड विकासकर्ताको रूपमा काम गर्छु, र म लुक+ मोबाइल एपको ब्याकइन्डमा Go प्रयोग गर्ने बारे कुरा गर्नेछु।

यहाँ कसैलाई हक्की मन पर्छ?

त्यसपछि यो अनुप्रयोग तपाइँको लागि हो। यो एन्ड्रोइड र आईओएसका लागि हो र विभिन्न खेलकुद घटनाहरू अनलाइन र रेकर्ड गरिएका प्रसारणहरू हेर्न प्रयोग गरिन्छ। अनुप्रयोगले विभिन्न तथ्याङ्कहरू, पाठ प्रसारणहरू, सम्मेलनहरूको लागि तालिकाहरू, टूर्नामेंटहरू र प्रशंसकहरूका लागि उपयोगी अन्य जानकारी समावेश गर्दछ।

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

विकासमा के उपयोग गर्नुभयो ?

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

हामीले PostgreSQL डाटाबेसको रूपमा प्रयोग गर्यौं। सम्पादक इन्टरफेस ActiveAdmin रत्न प्रयोग गरेर Ruby on Rails मा लेखिएको थियो। तथ्याङ्क प्रदायकबाट तथ्याङ्कहरू आयात गर्ने पनि रुबीमा लेखिएको छ।

प्रणाली API परीक्षणहरूको लागि, हामीले पाइथन एकाइ परीक्षण प्रयोग गर्यौं। Memcached API भुक्तानी कलहरू थ्रोटल गर्न प्रयोग गरिन्छ, "शेफ" कन्फिगरेसन नियन्त्रण गर्न प्रयोग गरिन्छ, Zabbix आन्तरिक प्रणाली तथ्याङ्कहरू सङ्कलन र निगरानी गर्न प्रयोग गरिन्छ। Graylog2 लगहरू सङ्कलनको लागि हो, स्लेट ग्राहकहरूको लागि API कागजात हो।

प्रोटोकल चयन

हामीले सामना गरेको पहिलो समस्या: हामीले ब्याकइन्ड र मोबाइल क्लाइन्टहरू बीचको अन्तरक्रियाको लागि निम्न बुँदाहरूमा आधारित प्रोटोकल छनौट गर्न आवश्यक छ...

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

यसको आधारमा, हामीसँग दुई प्रोटोकल विकल्पहरू थिए:

1. वेबसकेटहरू। तर हामीलाई ग्राहकबाट सर्भरमा च्यानलहरू आवश्यक पर्दैन। हामीले केवल सर्भरबाट क्लाइन्टमा अद्यावधिकहरू पठाउन आवश्यक छ, त्यसैले वेबसकेट एक अनावश्यक विकल्प हो।
2. सर्भर-पठाइएको घटनाक्रम (SSE) ठीकै आयो! यो एकदम सरल छ र मूलतया हामीलाई चाहिने सबै कुरा सन्तुष्ट गर्दछ।

सर्भर-पठाइएको घटनाहरू

यो कुरा कसरी काम गर्छ भन्ने बारे केही शब्दहरू...

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

डाटा ग्राहकहरु संग सहमत ढाँचा मा पठाउन सकिन्छ। हाम्रो मामलामा, हामीले यसलाई यस फारममा पठाएका छौं: परिवर्तन गरिएको संरचनाको नाम (व्यक्ति, खेलाडी) घटना क्षेत्रमा पठाइयो, र JSON नयाँ, परिवर्तन गरिएका फिल्डहरू प्लेयरको लागि डेटा फिल्डमा पठाइयो।

अब कुरा गरौं कसरी अन्तरक्रिया आफैले काम गर्दछ।

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

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

प्रत्यक्ष जडान कसरी सेवा गरिन्छ?

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

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

नतिजाको रूपमा, अब हाम्रो पिंग एउटै च्यानलबाट आउँछ जुन अपडेट आउँछ।

तदनुसार, त्यहाँ एउटा मात्र टाइमर छ जुन प्रत्येक 15 सेकेन्डमा एक पटक टिक्छ।

यहाँ धेरै सहायक कार्यहरू छन् - हेडर, पिङ र संरचना आफैं पठाउने। त्यो हो, तालिकाको नाम (व्यक्ति, म्याच, सिजन) र यस प्रविष्टिको बारेमा जानकारी यहाँ पठाइन्छ:

अद्यावधिकहरू पठाउने संयन्त्र

अब थोरै परिवर्तनहरू कहाँबाट आउँछन्। हामीसँग धेरै व्यक्तिहरू, सम्पादकहरू छन्, जसले वास्तविक समयमा प्रसारण हेर्छन्। तिनीहरूले सबै घटनाहरू सिर्जना गर्छन्: कसैलाई पठाइयो, कोही घाइते भयो, कुनै प्रकारको प्रतिस्थापन ...

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

PostgreSQL: सुन्नुहोस्/सूचना गर्नुहोस्

Postgres मा सुन्नुहोस्/सूचना संयन्त्रले तपाईंलाई घटनाहरूमा सदस्यहरूलाई सूचित गर्न अनुमति दिन्छ कि केही घटना परिवर्तन भएको छ - डाटाबेसमा केही रेकर्ड सिर्जना गरिएको छ। यो गर्न, हामीले एक साधारण ट्रिगर र प्रकार्य लेख्यौं:

रेकर्ड सम्मिलित वा परिवर्तन गर्दा, हामी data_updates च्यानलमा सूचना प्रकार्यलाई कल गर्छौं, त्यहाँ तालिकाको नाम र रेकर्डको पहिचानकर्ता जुन परिवर्तन वा सम्मिलित गरिएको थियो।

क्लाइन्टसँग सिङ्क्रोनाइज गरिनु पर्ने सबै तालिकाहरूको लागि, हामी ट्रिगर परिभाषित गर्छौं, जसले रेकर्ड परिवर्तन / अद्यावधिक गरेपछि तलको स्लाइडमा संकेत गरिएको प्रकार्यलाई कल गर्दछ।
API ले यी परिवर्तनहरूमा कसरी सदस्यता लिन्छ?

एक Fanout संयन्त्र सिर्जना गरिएको छ - यसले ग्राहकलाई सन्देशहरू पठाउँछ। यसले सबै ग्राहक च्यानलहरू सङ्कलन गर्दछ र यी च्यानलहरू मार्फत प्राप्त अद्यावधिकहरू पठाउँछ:

यहाँ मानक pq पुस्तकालय, जुन डाटाबेसमा जडान हुन्छ र यसले च्यानल (डेटा_अपडेटहरू) सुन्न चाहन्छ भनी जडान खुला छ र सबै ठीक छ भनी जाँच गर्दछ। म ठाउँ बचत गर्न त्रुटि जाँच छोड्दै छु (जाँच गर्नु खतरनाक छैन)।

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

फ्यान-आउट कसरी काम गर्छ?

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

यसलाई Go मा कसरी लागू हुन्छ:

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

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

त्यहाँ एक सदस्यता विधि पनि छ जसले च्यानललाई "श्रोताहरू" मा थप्छ:

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

प्रश्न: - यो च्यानल मार्फत के प्रसारित हुन्छ?

सुश्री: - मोडेल जुन परिवर्तन भएको छ वा पिंग प्रसारण गरिएको छ (अनिवार्य रूपमा केवल एक संख्या, पूर्णांक)।

सुश्री: - तपाइँ केहि पठाउन सक्नुहुन्छ, कुनै पनि संरचना पठाउन सक्नुहुन्छ, यसलाई प्रकाशित गर्नुहोस् - यो JSON मा परिणत हुन्छ र यो हो।

सुश्री: - हामीले Postgres बाट सूचना प्राप्त गर्छौं - यसले तालिकाको नाम र पहिचानकर्ता समावेश गर्दछ। तालिकाको नाम र पहिचानकर्ताको आधारमा, हामीले हामीलाई आवश्यक रेकर्ड पाउँछौं, र त्यसपछि हामी यो संरचना प्रकाशनको लागि पठाउँछौं।

आधारभूत संरचना

पूर्वाधारको दृष्टिकोणबाट यो कस्तो देखिन्छ? हामीसँग 7 हार्डवेयर सर्भरहरू छन्: ती मध्ये एउटा पूर्ण रूपमा डाटाबेसमा समर्पित छ, अन्य छवटा भर्चुअल मेसिनहरू चलाउँछन्। त्यहाँ API को 6 प्रतिलिपिहरू छन्: API को साथ प्रत्येक भर्चुअल मेसिन एक अलग हार्डवेयर सर्भरमा चल्छ - यो विश्वसनीयताको लागि हो।

पहुँच सुधार गर्न हामीसँग Keepalived संग दुईवटा फ्रन्टएन्डहरू छन्, ताकि यदि केहि भयो भने, एउटा फ्रन्टएन्डले अर्कोलाई प्रतिस्थापन गर्न सक्छ। साथै - CMS को दुई प्रति।

त्यहाँ तथ्याङ्क आयातकर्ता पनि छ। त्यहाँ एक DB स्लेभ छ जसबाट ब्याकअपहरू आवधिक रूपमा बनाइन्छ। त्यहाँ पिजन पुशर छ, एउटा अनुप्रयोग जसले ग्राहकहरूलाई पुश सूचनाहरू पठाउँदछ, साथै पूर्वाधारका चीजहरू: Zabbix, Graylog2 र Chef।

वास्तवमा, यो पूर्वाधार अनावश्यक छ, किनभने 100 हजार कम सर्भरहरूसँग सेवा गर्न सकिन्छ। तर त्यहाँ फलाम थियो - हामीले यसलाई प्रयोग गरे (हामीलाई भनिएको थियो कि यो सम्भव छ - किन छैन)।

Go का फाइदाहरू

हामीले यो एप्लिकेसनमा काम गरिसकेपछि, Go को यस्ता स्पष्ट फाइदाहरू देखा पर्‍यो।

• कूल http पुस्तकालय। यसको साथ तपाईं बक्स बाहिर धेरै धेरै सिर्जना गर्न सक्नुहुन्छ।
• साथै, च्यानलहरू जसले हामीलाई ग्राहकहरूलाई सूचनाहरू पठाउनको लागि एक संयन्त्रलाई सजिलै कार्यान्वयन गर्न अनुमति दियो।
• अद्भुत कुरा रेस डिटेक्टरले हामीलाई धेरै महत्वपूर्ण बगहरू (स्टेजिङ इन्फ्रास्ट्रक्चर) हटाउन अनुमति दियो। स्टेजिङमा काम गर्ने सबै चीजहरू सुरू गरिएको छ, रेस कुञ्जीसँग कम्पाइल गरिएको छ; र हामी, तदनुसार, हामीसँग के सम्भावित समस्याहरू छन् भनेर हेर्न स्टेजिङ पूर्वाधार हेर्न सक्छौं।
• न्यूनतमता र भाषाको सरलता।

हामी विकासकर्ताहरू खोजिरहेका छौं! कसैलाई चाहनु हुन्छ भने ।

तपाईंका प्रश्नहरू

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

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

IN: - यो तुरुन्तै सुन्न / सूचित गर्न रेकर्ड पठाउन सम्भव छैन, र पहिचानकर्ता तालिका होइन?

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

IN: - के ग्राहकहरूले उनीहरूलाई रुचि नभएका मिलानहरूमा अद्यावधिकहरू प्राप्त गर्छन्?

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

IN: - तपाईंले आफ्नो ORM किन बनाउनुभयो?

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

हाम्रो ORM ले डाटा मोडेलमा आधारित संरचनाहरू उत्पन्न गर्छ। म आफै। र त्यसैले सबै विधिहरू ठोस छन्, प्रतिबिम्ब, आदि प्रयोग नगर्नुहोस्। तिनीहरू संरचनाहरू स्वीकार गर्छन् र आउने संरचनाहरू प्रयोग गर्ने आशा गर्छन्।

IN: - कति जना सहभागी भए ?

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

IN: - जहाँ तपाइँ SSE को वर्णन गर्नुहुन्छ, तपाइँ टाइमआउट प्रयोग गर्नुहुन्न। त्यो किन हो?

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

IN: - तपाईंले के अतिरिक्त उपयोगिताहरू प्रयोग गर्नुभयो?

सुश्री: - हामीले सबैभन्दा सक्रिय रूपमा govet र golint को शैलीलाई एकीकृत बनाउन प्रयोग गर्यौं, साथै gofmt। अरु केही प्रयोग भएन ।

IN: - तपाईंले डिबग गर्न के प्रयोग गर्नुभयो?

सुश्री: - डिबगिङ धेरै हदसम्म परीक्षण प्रयोग गरी गरिएको थियो। हामीले कुनै पनि डिबगर वा GOP प्रयोग गरेका छैनौं।

IN: - के तपाइँ स्लाइड फिर्ता गर्न सक्नुहुन्छ जहाँ प्रकाशन प्रकार्य लागू गरिएको छ? के एकल-अक्षर चल नामहरूले तपाईंलाई भ्रमित पार्छ?

सुश्री: - छैन। तिनीहरूसँग दृश्यताको एकदम "साँघुरो" दायरा छ। तिनीहरू यहाँ बाहेक अरू कतै प्रयोग गरिएको छैन (यस वर्गको आन्तरिकहरू बाहेक), र यो धेरै कम्प्याक्ट छ - यसले केवल 7 लाइनहरू लिन्छ।

IN: - कतै यो अझै पनि सहज छैन ...

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

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

IN: - त्यहाँ कुनै तेस्रो-पक्ष निर्भरता व्यवस्थापन प्याकेजहरू छन्?

सुश्री: - हामीले गो डिप प्रयोग गर्यौं।

IN: – रिपोर्टको विषयवस्तुमा भिडियोको बारेमा केहि थियो, तर भिडियोको बारेमा रिपोर्टमा केहि थिएन।

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

IN: - तपाईले भन्नुभयो कि यो ग्राहकहरु लाई स्ट्रिम गरिएको छ? ..

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

सुश्री: - जानुहोस् - सबै डेटा पठाउनको लागि - स्कोरमा, खेल घटनाहरूमा, तथ्याङ्कहरूमा... गो अनुप्रयोगको लागि सम्पूर्ण ब्याकइन्ड हो। ग्राहकले खेलाडीको लागि कुन लिङ्क प्रयोग गर्ने भनेर कतैबाट थाहा हुनुपर्छ ताकि प्रयोगकर्ताले म्याच हेर्न सक्छ। हामीसँग तयार गरिएका भिडियोहरू र स्ट्रिमहरूको लिङ्कहरू छन्।

केही विज्ञापनहरू 🙂

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

डेल R730xd 2x एम्स्टर्डमको इक्विनिक्स टियर IV डाटा सेन्टरमा सस्तो छ? यहाँ मात्र 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV $199 बाट नेदरल्याण्ड मा! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 बाट! बारे पढ्नुहोस् पूर्वाधार कर्पोरेशन कसरी निर्माण गर्ने। डेल R730xd E5-2650 v4 सर्भरहरूको प्रयोगको साथ एक पैसाको लागि 9000 यूरो मूल्यको वर्ग?

स्रोत: www.habr.com