ग्रिगोरी पेत्रोव: रूबी में एक नेटवर्क के साथ काम करना

28 सितंबर को एवरोन रूबिरसिया देवराले सम्मेलन में, ग्रिगोरी पेत्रोव बात करेंगे कि माइक्रोसर्विसेज कैसे संवाद करते हैं। आज के साक्षात्कार में, इवान सोलोविओव ने ग्रिगोरी के साथ अपने आगामी भाषण के विषय के बारे में बात की और न केवल उसके बारे में बात की।



अपने बारे में बताइए, आप इवरोन में क्या कर रहे हैं?

मैं डेवलपर संबंधों में शामिल हूं - यह DevRel और Technology इंजीलवादी, एक डेवलपर के बीच कुछ है जो सम्मेलनों में बोल सकता है। रॉबिन हुड की तरह काम करें: कंपनी के भीतर विकास टीमों के साथ संवाद करें, वे जो करते हैं उससे विभिन्न दिलचस्प चीजें एकत्र करें और सम्मेलनों में इसके बारे में बात करें। रूबी रूस पहले सम्मेलनों में से एक होगी जहां मैं कंपनी की ओर से बोलूंगा।

मैं आपको विभिन्न पायथन सम्मेलनों के आयोजकों में से एक के रूप में जानता हूं। मुझे बताओ कि तुम रूबी की दुनिया में कैसे आए?

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

आपकी रिपोर्ट कंपनी के भीतर विकास टीमों से कितनी उधार ली जाएगी? मुझे पता है कि आपने कई भाषाओं में लिखा है: रूबी, पायथन, पीएचपी, टाइपस्क्रिप्ट, जावास्क्रिप्ट, सी ++ और न केवल।

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

डेवलपर्स के साथ आपका बहुत संवाद है। रूबी में एक नेटवर्क के साथ काम करना आपको कितना विशिष्ट लगता है?

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

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

रूबी की शक्ति क्या है? सबसे पहले, DSL में, डोमेन विशिष्ट भाषा। जब हम ग्रिड के बारे में बात करते हैं, तो रूबी उस क्षेत्र में सबसे अच्छा खेलती है जहां यह सबसे मजबूत है। जब हम GraphQL का उपयोग करते हैं, तो इसका मतलब है कि GraphQL का उपयोग करने के लिए पुस्तकालय हर जगह हैं। रूबी में, वे स्कीमा को परिभाषित करने के लिए बहुत अच्छे डीएसएल सिंटैक्स का उपयोग करेंगे। और इन DSL सिंटैक्स और DSLR ORM सिंटैक्स के बीच ActiveRecord में एकीकरण। यह वही है जो हम रूबी से उम्मीद कर सकते हैं। इसी समय, हमारे पास कोई भी अतुल्यकालिक ऑपरेशन (इंतजार) नहीं होगा, हम प्रक्रियाओं द्वारा स्केल किए जाएंगे और हमारे पास सर्वर की आवश्यकताएं होंगी।

आपकी रिपोर्ट में कई इंटरैक्शन प्रोटोकॉल बताए गए हैं। वही JSON: API और इसी तरह। आप आगे के विकास को किस तरीके से देखते हैं, क्या हम सभी ग्राफकॉल में स्लाइड करेंगे?

बहुत गूंजता हुआ सवाल। मेरी राय में, यह इस तथ्य से शुरू हुआ कि ग्रिड धीमा है। शुरुआत में आवेदन सरल हैं। एक नियम के रूप में, सभी अनुप्रयोग, रूबी, पायथन और नोड दोनों, संचार के लिए नियमित HTTP एंडपॉइंट का उपयोग करते हैं। अंदर वे किसी तरह के पेलोड का उपयोग करते हैं। पहले XML, अब JSON। वे पहले कुछ महीनों या वर्षों के लिए अच्छा कर रहे हैं, जैसे कि वे भाग्यशाली थे। अगला, व्यवसाय जटिल प्रश्न पूछना शुरू करता है। उदाहरण के लिए, आपको कुछ उपयोगकर्ताओं और प्रत्येक उपयोगकर्ता के लिए उन कंपनियों की सूची प्राप्त करने की आवश्यकता है जिनमें वह काम करता है। यहां यह समस्या उत्पन्न होती है: यदि आप केवल समापन बिंदु का उपयोग करते हैं, तो यह कई दसियों या सैकड़ों अनुरोध होंगे, और ग्रिड इत्मीनान से है: अनुरोध, प्रतिक्रिया, खोए हुए पैकेट। यह राक्षसी रूप से धीमा होगा और बहुत अधिक डेटा को नेटवर्क पर प्रसारित करना होगा। आवश्यक डेटा से 100 गुना अधिक। हमारा सिस्टम ध्वस्त हो जाता है, क्योंकि बड़े व्यापारिक स्वचालन सिस्टम ऐसे अनुरोधों के तहत ढह जाते हैं, जो 10 वर्षों में राक्षसों में विकसित होते हैं, जहां मिनट, घंटे इंटरफ़ेस से जटिल प्रश्न हो सकते हैं। इस समय, बैकएंड पर डेटाबेस समान अनुरोधों के एक समूह का काम करेगा, और समान अनुरोधों का एक गुच्छा पूरे नेटवर्क में पीछा करेगा। हम इसे विभिन्न तरीकों से हल करने की कोशिश करते हैं।

ऐसी समस्याओं के वास्तविक उदाहरण दें?

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

दूसरी बड़ी समस्या यह है कि अगर हम बैकएंड से बहुत अधिक डेटा प्राप्त करना चाहते हैं तो क्या करें। उदाहरण के लिए, पांच हजार उपयोगकर्ता या 10mb में लॉग। यह सब एक http अनुरोध-प्रतिक्रिया के साथ करने के लिए डरावना है। क्योंकि यदि मेष ढह जाता है, तो अनुरोध को पूरी तरह से दोहराया जाना होगा, और यह हमेशा के लिए रह सकता है। फेसबुक पर वापस आना: उन्होंने ग्राफक, ग्रिड पर बैसाखी बनाई। और फिर अन्य लोगों ने HTTP / 2 किया, जो ग्रिड की समस्या को हल करता है। HTTP / 2 एक अतुल्यकालिक कनेक्शन बनाता है, जिसके भीतर हम कई छोटे अनुरोध कर सकते हैं। HTTP / 2 लड़ता है, अगर बैकएंड पर डेटाबेस के लिए प्रश्नों की संख्या को अनुकूलित करने के लिए ग्राफकलाइन सर्वर में ज्यादा जादू नहीं है। और बात में, हम रूबी इस जादू के लिए क्या पेशकश करेंगे, इस बारे में बात करेंगे। HTTP / 2 के साथ, GraphQL की जरूरत नहीं हो सकती है। हम अपने समापन बिंदु पर 100 HTTP / 2 अनुरोध कर सकते हैं, और बाइट्स के दृष्टिकोण से यह एक बड़ा ओवरहेड नहीं होगा यदि हम ग्राफ़िकल का उपयोग करते हैं। Google प्रोटोकॉल बफ़र्स और gRPC तीसरे सिरे से इस मुद्दे पर आते हैं। वे मुख्य रूप से HTTP / 2 बाइनरी ट्रांसपोर्ट प्रोटोकॉल का उपयोग करते हैं, वे एपीआई के लिए एक निश्चित योजना प्रदान करते हैं। यहाँ वे सामान्य REST के साथ प्रतिस्पर्धा करते हैं।

व्यवहार में, JSON का उपयोग करने वाली अधिकांश कंपनियों में, प्रोग्रामर Vasya बैठता है और इस JSON को अपने हाथों से लिखता है। छह महीने बाद, वासिया को पता चलता है कि तारीख और समय को सौ अलग-अलग तरीकों से प्रेषित किया जा सकता है। डर शुरू! लेकिन अगर अच्छे डेवलपर्स कंपनी में बैठते हैं, तो वे न केवल JSON लिखते हैं, बल्कि कुछ प्रकार के मानक का उपयोग करते हैं। OpenAPI या JSON स्कीमा का उपयोग करना, ये सभी दिलचस्प चीजें जो gRPC के साथ प्रतिस्पर्धा करती हैं। यह पूरा आधुनिक चिड़ियाघर कुछ आवाज़ों की समस्याओं को हल करता है। और भविष्य में इस चिड़ियाघर का क्या होगा, मैं बिल्कुल भी अनुमान नहीं लगा सकता। लेकिन मैं डेवलपर्स को इस मुद्दे पर आने और चर्चा करने के लिए आमंत्रित करता हूं: आने वाले वर्ष में हमें क्या इंतजार है, 3, 5, 10 और अब बलों का स्वभाव क्या है।

एक प्रोग्रामिंग भाषा के रूप में रूबी के भविष्य के बारे में बात करते हैं?

भविष्य की भविष्यवाणी करना कठिन है। मैं वास्तव में रूबी में अच्छे प्रकार देखना चाहूंगा। रूबी 3 अब प्रकार के कार्यान्वयन की शुरुआत में है। मैं चाहूंगा कि यह वाक्यविन्यास सुंदर हो। मैंने प्रस्तावों को देखा, मेरा गंजा स्पॉट उनके पास से दूर था। बहुत, बहुत ही वाक्यविन्यास वाक्य रचना जो कोई उपयोग नहीं करेगा।

आप ऐसा क्यों सोचते हैं?

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

रूबी में और क्या देखना चाहेंगे?

पिछले कुछ वर्षों में, मैंने कोरटाइन के साथ बहुत से एसिंक्स को देखा है। मुझे वास्तव में यह पसंद है क्योंकि कोरटाइन के साथ async कोड को पढ़ना आसान है। यह समझने योग्य है, आपको सरल वाक्य रचना में जटिल चीजों को रटना करने की अनुमति देता है। यह नवीनतम पायथन में अच्छी तरह से लागू किया गया है और जावास्क्रिप्ट में अच्छी तरह से लागू किया गया है। मैं वास्तव में रूबी के लिए कुछ ऐसा लाना चाहूंगा ... दरअसल, रूबी के पास फाइबर है। यह नोड की तरह कुछ जोड़ने के लिए अच्छा होगा ताकि आप फाइबर या कुछ अन्य आदिम का उपयोग करके अतुल्यकालिक रूबी अनुप्रयोगों को लिख सकें। और हुड के तहत, यह स्वयं ग्रिड के साथ काम करने के लिए libuv या कुछ अन्य ऑपरेटिंग सिस्टम प्राइमेटिव्स का उपयोग करेगा।

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

वापस प्रकारों के लिए। यह संभवतः प्रकारों का क्रमिक परिचय होगा, क्रमिक टंकण?

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

आप सम्मेलन में युकीहिरो मात्सुमोतो से क्या सवाल पूछना चाहते हैं?

मैं 4 वर्षों से जापानी का अध्ययन कर रहा हूं, और मेरा जापानी शायद उसे "धन्यवाद" कहने के लिए पर्याप्त है। मैं प्रशिक्षण दूंगा!

रूबिरसिया में मिलते हैं!

रजिस्टर , 15 सितंबर के बाद अगली मूल्य वृद्धि की उम्मीद है, 700 प्रतिभागी पहले से ही हमारे साथ हैं।

और हमें समर्थन करने वाली कंपनियों के लिए पारंपरिक धन्यवाद:

आयोजक - एवरोन
सामान्य साझेदार - शीर्षताल
गोल्ड पार्टनर - गेट
सिल्वर पार्टनर्स - जेटब्रेन्स , बुकमेट और कैशवगन
कांस्य भागीदार - InSales