नोड में एक मोनोलिथ में 9 साल

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

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

• सबसे पहले, हमारे मोनोलिथ पहले से ही 9 साल पुराना है।
• दूसरे, उन्होंने अपना पूरा जीवन हाईलोड के तहत बिताया (अब यह प्रति घंटे 23 मिलियन अनुरोध है)।
• और NaN में, हम अपने मोनोलिथ को Node.JS पर लिखते हैं, जो पिछले 9 वर्षों में मान्यता से परे बदल गया है। हां, हमने 2010 में नोड पर लिखना शुरू किया, हम बहादुर के उन्माद के लिए एक गीत गाते हैं!

इसलिए हमारे पास बहुत सी विशिष्टता और वास्तविक अनुभव हैं। रुचि रखते हैं? चलो चलते हैं!

अस्वीकरण समय

यह प्रस्तुति केवल इसके लेखक के निजी विचार को दर्शाती है। यह OneTwoTrip की स्थिति के साथ मेल खा सकता है, या यह संयोग नहीं हो सकता है। कितना भाग्यशाली है। मैं कंपनी की टीमों में से एक के एक तकनीकी विशेषज्ञ के रूप में काम करता हूं और अपने स्वयं के अलावा किसी के विचार को उद्देश्य या व्यक्त करने का नाटक नहीं करता हूं।

अस्वीकरण दो

यह लेख ऐतिहासिक घटनाओं का वर्णन करता है, और इस समय सब कुछ पूरी तरह से गलत है, इसलिए चिंतित न हों।

0. यह कैसे हुआ

Google में शब्द "microservice" की क्वेरी प्रवृत्ति :

सब कुछ बहुत सरल है - नौ साल पहले कोई भी माइक्रोसर्ज के बारे में नहीं जानता था। इसलिए हमने लिखना शुरू किया, जैसे बाकी सब - एक मोनोलिथ में।

1. मोनोलिथ में दर्द

यहाँ मैं उन समस्या स्थितियों का वर्णन करूँगा जो हमने इन 9 वर्षों के दौरान की हैं। उनमें से कुछ को हल किया गया था, कुछ को हैक द्वारा दरकिनार कर दिया गया था, कुछ बस प्रासंगिकता खो गए थे। लेकिन उनमें से स्मृति, युद्ध के दाग की तरह, मुझे कभी नहीं छोड़ेगी।

1.1 कनेक्टेड घटकों को अद्यतन करना

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

1.2 नई प्रौद्योगिकियों के लिए प्रवासन

क्या आप एक्सप्रेस चाहते हैं? लिंटर? परीक्षण या मोक के लिए एक और ढांचा? सत्यापनकर्ता को अपडेट करें या कम से कम दर्ज करें? Node.js अपडेट करें? मुझे क्षमा करें। ऐसा करने के लिए, आपको हजारों लाइनों की कोड को संपादित करना होगा।

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

क्या आप सिमेंटिक वर्जनिंग के बारे में पुराना मजाक जानते हैं?

सिमेंटिक संस्करण के वास्तविक शब्दार्थ:

मेजर = एक ब्रेकिंग चेंज
मामूली = एक मामूली तोड़ने वाला परिवर्तन
पैच = थोड़ा-सा टूटता हुआ परिवर्तन

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

१.३ जारी करना

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

1. रिलीज हो रहा है और एकीकरण परीक्षण आधे दिन में गुजरते हैं
2. तब यह एक दिन के लिए मंच पर सावधानीपूर्वक निगरानी में है (10% उपयोगकर्ताओं के लिए)
3. तब और भी अधिक चौकस पर्यवेक्षण के तहत उत्पादन पर एक और दिन निहित है।
4. और उसके बाद ही हम उसे गुरु में हरी ज्योति देते हैं।

चूंकि हम अपने सहयोगियों से प्यार करते हैं और शुक्रवार को रिलीज नहीं करते हैं, इसलिए इसका मतलब यह है कि रिलीज सप्ताह में लगभग 1.5-2 बार मास्टर के पास जाती है। जो इस तथ्य की ओर जाता है कि रिलीज में 60 कार्य या अधिक हो सकते हैं। इस तरह की राशि के कारण मर्ज संघर्ष, अचानक सहक्रियात्मक प्रभाव, लॉग विश्लेषण पर क्यूए का पूर्ण कार्यभार और अन्य दुख होते हैं। सामान्य तौर पर, हमारे लिए एक मोनोलिथ जारी करना बहुत मुश्किल था।

1.4 बहुत सारे कोड

ऐसा लगता है कि कोड की राशि मौलिक महत्व की नहीं होनी चाहिए। लेकिन ... वास्तव में नहीं। वास्तविक दुनिया में यह है:

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

1.5 अनुपलब्ध कोड स्वामी

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

1.6 डिबगिंग की कठिनाई

स्मृति बह रही है? सीपीयू की खपत बढ़ी? लौ ग्राफ बनाना चाहते थे? मुझे क्षमा करें। एक मोनोलिथ में, इतनी सारी चीजें एक ही समय में होती हैं कि समस्या को स्थानीय बनाना मुश्किल हो जाता है। उदाहरण के लिए, यह समझने के लिए कि उत्पादन में रोल करते समय 60 में से कौन सा कार्य संसाधन की वृद्धि का कारण बनता है (हालांकि यह स्थानीय रूप से परीक्षण और मचान के वातावरण पर पुन: पेश नहीं किया जाता है) लगभग अवास्तविक है।

1.7 एक ढेर

एक तरफ, यह अच्छा है जब सभी डेवलपर्स एक ही भाषा "बोलते" हैं। जेएस के मामले में, यह पता चला है कि फ्रंटेंड डेवलपर्स के साथ बैकेंड भी एक दूसरे को समझते हैं। लेकिन ...

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

1.8 खुशी के बारे में विभिन्न विचारों के साथ कई टीमें

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

2. मोनोलिथ के फायदे

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

२.१ आसान तैनात

जब आपके पास एक सेवा है, तो इसे उठाना और परीक्षण करना एक दर्जन सेवाओं की तुलना में बहुत आसान है। सच है, यह प्लस केवल प्रारंभिक चरण में प्रासंगिक है - उदाहरण के लिए, आप परीक्षण वातावरण को बढ़ा सकते हैं, और विकसित किए गए लोगों को छोड़कर, सभी सेवाओं का उपयोग कर सकते हैं। या कंटेनरों से। या जो भी हो।

2.2 कोई डेटा ट्रांसफर ओवरहेड नहीं

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

२.२ एक सभा

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

3. एक मोनोलिथ के काल्पनिक लाभ

यहां मैंने उन सभी चीजों को लिया, जिन्हें आमतौर पर प्लसस माना जाता है, लेकिन मेरे दृष्टिकोण से वे नहीं हैं।

3.1 कोड - यह दस्तावेज है

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

3.2 पुस्तकालयों, सेवाओं और एपीआई के अलग-अलग संस्करण नहीं हैं। कोई अलग रिपोजिटरी नहीं हैं।

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

3.3 आसान निगरानी

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

3.4 सामान्य मानकों का पालन करना आसान है

हां। लेकिन, जैसा कि मैंने पहले से ही खुशी के विचार के साथ बहुत सी टीमों के बारे में पैराग्राफ में लिखा था - मानकों को या तो अधिमानतः लगाया जाता है, या इसके अभाव में लगभग कमजोर हो जाता है।

3.5 कोड दोहराव की कम संभावना

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

4. माइक्रोसर्विस के पेशेवरों

अब मैं लिखूंगा कि प्रवास के बाद हमें क्या मिला। फिर, ये वास्तविक स्थिति से वास्तविक निष्कर्ष हैं।

4.1 आप एक विषम संरचना बना सकते हैं

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

4.2 आप कई लगातार रिलीज कर सकते हैं

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

4.3 स्वतंत्र परीक्षण करना आसान

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

4.4 नई सुविधाओं को लागू करने और परीक्षण करने में आसान

अब हम प्रयोग के लिए खुले हैं। किसी भी ढांचे, ढेर, पुस्तकालय - आप सब कुछ कोशिश कर सकते हैं, और यदि सफल हो, तो आगे बढ़ें।

4.5 आप कुछ भी अपडेट कर सकते हैं

आप इंजन, पुस्तकालयों के संस्करण को अपडेट कर सकते हैं, लेकिन कुछ भी! एक छोटी सी सेवा के हिस्से के रूप में, सभी ब्रेकिंग परिवर्तनों को खोजना और ठीक करना मिनटों की बात है। और सप्ताह नहीं, जैसा कि पहले था।

4.6 और आप अपडेट नहीं कर सकते

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

5 माइक्रोसर्विस की विपक्ष

बेशक, मरहम में एक मक्खी पूरी नहीं थी, और बस बैठने और भुगतान करने का एक सही समाधान काम नहीं करता था। हमने क्या सामना किया:

5.1 डेटा विनिमय और स्पष्ट लॉगिंग के लिए बस की आवश्यकता है।

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

5.2 डेवलपर्स क्या कर रहे हैं, इसका ध्यान रखें।

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

5.3 आपको इसे प्रबंधित करने के लिए एक अच्छी DevOps टीम की आवश्यकता है।

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

5.4 आप एक प्रचार को पकड़ने और अपने आप को पैर में गोली मारने की कोशिश कर सकते हैं।

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

मोनोलिथ में 6 खाकी

कुछ हैक्स जिन्होंने हमें एक मोनोलिथ में रहने की अनुमति दी है, वे थोड़े बेहतर और थोड़े लंबे हैं।

6.1 अस्तर

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

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

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

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

6.2 इकाई परीक्षण में सुधार

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

1. शुरुआत के लिए, हमने मल्टीथ्रेडेड परीक्षण चलाना शुरू कर दिया। यैंडेक्स में बहु-थ्रेडेड मोचा का एक संस्करण है, लेकिन हमारे साथ यह बंद नहीं हुआ, इसलिए उन्होंने खुद को एक सरल आवरण लिखा। टेस्ट डेढ़ गुना तेजी से किए जाने लगे।
2. फिर हम 0.12 नोड्स से 8 वें स्थान पर चले गए (हाँ, यह प्रक्रिया एक अलग रिपोर्ट में आ रही है)। जैसा कि लग सकता है अजीब है, इसने उत्पादन पर उत्पादकता में कोई मौलिक लाभ नहीं दिया, लेकिन परीक्षण 20% तेजी से किया जाने लगा।
3. और फिर हम परीक्षणों को डिबग करने और उन्हें व्यक्तिगत रूप से अनुकूलित करने के लिए बैठ गए। जिसने गति में सबसे बड़ी वृद्धि दी।

सामान्य तौर पर, वर्तमान में, यूनिट परीक्षण प्रीप हुक में चलते हैं और 10 सेकंड में काम करते हैं, जो काफी आरामदायक है और आपको उत्पादन से बिना किसी बाधा के उन्हें चलाने की अनुमति देता है।

6.3 विरूपण साक्ष्य वजन को हल्का करना

मोनोलिथ विरूपण साक्ष्य ने अंततः 400 मेगाबाइट तक ले लिया। इस तथ्य को ध्यान में रखते हुए कि यह प्रत्येक प्रतिबद्ध के लिए बनाया गया है, कुल वॉल्यूम काफी बड़ा हो गया है। डायरिया मॉड्यूल, माड्यूलियन मॉड्यूल का एक कांटा, हमें इसमें मदद करता है। हमने कलाकृतियों से इकाई परीक्षणों को हटा दिया और इसे विभिन्न कचरा जैसे कि रीडमी फाइलें, पैकेजों के अंदर के परीक्षण, और इसी तरह साफ किया। लाभ वजन का लगभग 30% था!

6.4 निर्भरता कैशिंग

पूर्व में, एनपीएम का उपयोग करके निर्भरताएं स्थापित करने में इतना समय लगा कि आप न केवल कॉफी पी सकते हैं, बल्कि उदाहरण के लिए, पिज्जा सेंकना भी कर सकते हैं। इसलिए, सबसे पहले हमने npm-cache मॉड्यूल का उपयोग किया, जिसे कांटा गया और थोड़ा समाप्त हो गया। इसने आपको एक साझा नेटवर्क ड्राइव पर निर्भरता को स्टोर करने की अनुमति दी, जिसमें से अन्य सभी बिल्ड इसे ले लेंगे।

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

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

6.5 रिलीज के आदेश का वितरण।

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

6.6 मृत कोड हटाना

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

7 मोनोलिथ कट

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

मैं एक और विकल्प प्रस्तावित करता हूं, जो मुझे अधिक काम करने वाला लगता है, और जिसे हमारे साथ लागू किया गया था:

1. हम माइक्रोसर्विसेज में नई सेवाओं को लिखना शुरू करते हैं। हम प्रौद्योगिकी चलाते हैं, रेक पर कूदते हैं, हम समझते हैं कि क्या हम इसे बिल्कुल करना चाहते हैं।
2. हम कोड को मॉड्यूल, लाइब्रेरी या जो कुछ भी वहां उपयोग किया जाता है, में निकालते हैं।
3. हम सेवाओं को एक मोनोलिथ से अलग करते हैं।
4. हम सेवाओं से माइक्रोसर्विस को अलग करते हैं। बिना जल्दबाजी और एक बार में।

8 और अंत में

अंत में, मैंने सबसे महत्वपूर्ण बात छोड़ने का फैसला किया।

याद रखें:

• आप Google नहीं हैं
• आप Microsoft नहीं हैं
• आप फेसबुक नहीं हैं
• आप यांडेक्स नहीं हैं
• आप नेटफ्लिक्स नहीं हैं
• आप OneTwoTrip नहीं हैं

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

उपयोगी लिंक:

• वीडियो प्रारूप में मेरी रिपोर्ट
• Node.JS द्वारा mitap से पूर्ण प्लेलिस्ट