सभी को नमस्कार! मेरा नाम मैक्सिम राइंडिन है, मैं गेट-बिलिंग और इन्फ्रास्ट्रक्चर में दो टीमों का टीम लीड हूं। मैं उत्पाद वेब विकास के बारे में बात करना चाहता हूं, जिसे हम गेट पर मुख्य रूप से गो का उपयोग करते हैं। मैं आपको बताऊंगा कि 2015-2017 में हमने इस भाषा पर स्विच किया, हमने इसे बिल्कुल क्यों चुना, संक्रमण के दौरान हमें क्या समस्याएं आईं और हमें क्या समाधान मिला। और मैं आपको अगले लेख में वर्तमान स्थिति के बारे में बताऊंगा।

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

हम कैसे जाने के लिए आया था

2011 में, कंपनी का मुख्य उत्पाद रूबी ऑन रेल्स पर एक अखंड अनुप्रयोग था, क्योंकि उस समय यह रूपरेखा बहुत लोकप्रिय थी। रूबी पर तेजी से विकसित और लॉन्च किए गए व्यवसायों के सफल उदाहरण थे, इसलिए यह व्यवसाय में सफलता के साथ जुड़ा था। कंपनी विकसित हो रही थी, नए ड्राइवर और उपयोगकर्ता हमारे पास आए, भार बढ़ता गया। और पहली समस्याएं सामने आने लगीं।

कार के स्थान को प्रदर्शित करने के लिए क्लाइंट एप्लिकेशन के लिए, और ताकि इसकी गति एक चिकनी वक्र की तरह दिखे, ड्राइवरों को अक्सर अपने निर्देशांक भेजने चाहिए। इसलिए, ड्राइवरों से निर्देशांक प्राप्त करने के लिए जिम्मेदार समापन बिंदु लगभग हमेशा सबसे अधिक भरा हुआ था। और रूबी ऑन रेल्स में वेब सर्वर फ्रेमवर्क ने इसका बहुत बुरा काम किया। नए एप्लिकेशन सर्वर को जोड़ना, जो महंगा और अक्षम है, केवल बड़े पैमाने पर करना संभव था। परिणामस्वरूप, हमने एक अलग सेवा में निर्देशांक का कार्यात्मक संग्रह निकाला, जो मूल रूप से जेएस में लिखा गया था। थोड़ी देर के लिए, इससे समस्या हल हो गई। हालाँकि, जैसे-जैसे लोड बढ़ता गया, जब हम 80 हजार RPM तक पहुँच गए, Node.js पर सेवा ने हमें बचाना बंद कर दिया।

फिर हमने एक हैकथॉन घोषित किया। कंपनी के सभी कर्मचारियों को एक दिन में एक प्रोटोटाइप लिखने का अवसर मिला, जो ड्राइवरों के निर्देशांक को इकट्ठा करना था। यहाँ उस सेवा के दो संस्करणों के मानदंड हैं: ठेस पर चल रहा है और गो पर फिर से लिखा गया है।


लगभग सभी मामलों में, गो पर सेवा ने सर्वोत्तम परिणाम दिखाए। Node.js पर सेवा ने एक क्लस्टर का उपयोग किया, यह एक मशीन के सभी कोर का उपयोग करने के लिए एक तकनीक है। अर्थात्, प्रयोग एक प्लस या माइनस ईमानदार था। हालाँकि, Node.js को एकल-थ्रेडेड रनटाइम का नुकसान है, लेकिन इसका परिणामों पर कोई प्रभाव नहीं पड़ता है।

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

नतीजतन, हमने गो को मुख्य विकास भाषाओं में से एक के रूप में अपनाने का फैसला किया।

हमारे उत्पाद विकास की विशेषताएं

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

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

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

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

हम समस्याओं का समाधान करते हैं

ढांचा

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

हमने बीगो का उपयोग करने की कोशिश की, जैसे कि रूबी ऑन रेल्स में, सर्वर-साइड रेंडरिंग करने के लिए। हालाँकि, सर्वर पर प्रदान किया गया पृष्ठ वास्तव में हमें खुश नहीं करता था। मुझे एक घटक को फेंकना पड़ा, और आज बीगो बैकेंड से केवल JSON का उत्पादन करता है, और सभी रेंडर सामने की तरफ प्रतिक्रिया द्वारा किया जाता है।

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

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

डेटाबेस

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

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

प्रवास

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

 COMMIT; CREATE INDEX CONCURRENTLY huge_index ON huge_table (column_one, column_two); BEGIN; 

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

परीक्षण

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

निगरानी

यदि आपके पास एक उत्पादन सेवा है जिसे लोग एक्सेस कर रहे हैं, तो आपको इसके काम को ट्रैक करने की आवश्यकता है: क्या पांच सौ त्रुटियां हैं या अनुरोधों को जल्दी से संसाधित किया जा रहा है। रूबी ऑन रेल्स की दुनिया में, न्यूरेलिक का उपयोग अक्सर इसके लिए किया जाता है, और हमारे कई डेवलपर्स ने इसे अच्छी तरह से स्वामित्व दिया है। उन्होंने समझा कि उपकरण कैसे काम करता है, जहां देखने के लिए कि क्या कोई समस्या है। NewRelic आपको HTTP के माध्यम से अनुरोधों के प्रसंस्करण समय का विश्लेषण करने, डेटाबेस के लिए धीमी बाहरी कॉल और अनुरोधों की पहचान करने, डेटा प्रवाह की निगरानी करने, बुद्धिमान त्रुटि विश्लेषण और अलर्ट प्रदान करने की अनुमति देता है।

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



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

Apdex चार्ट शीर्ष दाईं ओर प्रदर्शित होता है। नीचे दाईं ओर - प्रसंस्करण अनुरोधों की आवृत्ति।

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

सबसे पहले, हम अनुरोध प्रसंस्करण की अवधि को मापना चाहते थे। यह बीगो द्वारा प्रदान किए गए हुक का उपयोग करके किया गया था।

 beego.InsertFilter("*", beego.BeforeRouter, StartTransaction, false) beego.InsertFilter("*", beego.AfterExec, NameTransaction, false) beego.InsertFilter("*", beego.FinishRouter, EndTransaction, false) 

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


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

 db.Callback().Create().Before("gorm:begin_transaction"). Register("newrelicStart", startSegment) db.Callback().Create().After("gorm:commit_or_rollback_transaction"). Register("newrelicStop", endSegment) 

GORM का उपयोग करते समय डेटाबेस में क्वेरी निष्पादन की अवधि को मापने के लिए, आपको db ऑब्जेक्ट लेने की आवश्यकता होती है। कॉलबैक कहता है कि हम कॉलबैक रजिस्टर करना चाहते हैं। नई इकाई बनाते समय इसे कॉल किया जाना चाहिए - Create करने के Create एक कॉल। तब हम ठीक से इंगित करते हैं कि कॉलबैक कब लॉन्च किया जाए। Before यह begin_transaction तर्क के साथ जिम्मेदार हो: begin_transaction लेन-देन के खुलने के समय कुछ बिंदु है। इसके बाद, newrelicStart नाम के साथ newrelicStart startSegment फ़ंक्शन को पंजीकृत करते हैं, जो बस गो एजेंट को कॉल करता है और डेटाबेस तक पहुंचने के लिए एक नया सेगमेंट खोलता है।

लेनदेन को खोलने से पहले ORM इस फ़ंक्शन को कॉल करेगा, और इस तरह सेगमेंट को खोलेगा। हमें खंड को बंद करने के लिए ऐसा ही करना चाहिए: बस कॉलबैक को लटकाएं।

PostgreSQL के अलावा, हम Redis का उपयोग करते हैं, जो कि चिकना भी नहीं है। इस निगरानी के लिए, हमने एक मानक ग्राहक के ऊपर एक आवरण लिखा, और बाहरी सेवाओं को कॉल करने के लिए भी ऐसा ही किया। यहाँ क्या हुआ:



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

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

निष्कर्ष

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

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

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