Node.js स्केलिंग के लिए 12 युक्तियाँ

नेटफ्लिक्स, रेडिट, वॉलमार्ट और ईबे जैसी कंपनियों पर तैनात आवेदनों के सबूत के रूप में, Node.js पहले से ही वैश्विक स्तर पर सफलतापूर्वक काम कर रहा है। हालांकि, स्केलिंग करते समय समस्याओं का अपना सेट होता है; एकल कोड आधार पर काम करने वाले लोगों को स्केल करने के दृष्टिकोण से, इसलिए बादल में ऊर्ध्वाधर और क्षैतिज स्केलिंग के दृष्टिकोण से। Reddit और Netflix जैसी कंपनियों के लिए काम करते समय Node.js स्केलिंग के साथ अपने व्यक्तिगत अनुभव के अलावा, मैंने Microsoft Azure में काम करने वाले कुछ विशेषज्ञों के साथ बात की और आपकी कंपनी में Node.js को स्केल करने के लिए आपके लिए कुछ टिप्स लेकर आया।

एक गुणवत्ता लिखें Node.js

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

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

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

परीक्षण लिखें

डेवलपर्स के लिए टेस्ट हमेशा एक मुश्किल मुद्दा रहा है। कुछ दृढ़ता से परीक्षण-संचालित विकास में विश्वास करते हैं, जबकि अन्य शायद ही कभी परीक्षण लिखते हैं। लेकिन एक बीच का मैदान है:

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

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

स्टेटलेस डिज़ाइन

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

सांख्यिकी: विकास के लिए - Node.js, उत्पादन के लिए - CDN

मैं कैसे चाहूंगा कि कंपनियां इस त्रुटि में एक त्रुटि देखें। अपने वेब एप्लिकेशन (विशेष रूप से वेबपैक-देव-सर्वर या पार्सल के देव सर्वर जैसे कुछ के माध्यम से) से अपनी स्थैतिक संपत्ति की सेवा करना एक उत्कृष्ट डेवलपर अनुभव है क्योंकि यह कोड लिखते समय परिचय चक्र को छोटा करता है। हालाँकि, आपको Node.js. के माध्यम से कभी भी अपने स्टैटिक्स की सेवा नहीं देनी चाहिए इसे CDN के माध्यम से अलग से भेजना चाहिए, जैसे कि Azure CDN।

Node.js के साथ स्टेटिक रिटर्न अनावश्यक रूप से धीमा है क्योंकि CDN अधिक बिखरे हुए हैं और इसलिए शारीरिक रूप से अंतिम उपयोगकर्ता के करीब हैं, और CDN सर्वर छोटे संसाधनों के लिए अत्यधिक अनुकूलित हैं। नोड के साथ स्टैटिक्स को बनाए रखना भी अनुचित रूप से महंगा है, क्योंकि Node.js सर्वर समय CDN सर्वर समय की तुलना में बहुत अधिक महंगा है।

जल्दी तैनाती शुरू करें, अधिक बार तैनात करें

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

वैसे, विज़ुअल स्टूडियो कोड आपको इस तरह की समस्या को हल करने की अनुमति देता है । यह आपको एक क्लिक के साथ अपने एप्लिकेशन को सीधे Azure पर तैनात करने की अनुमति देता है। यह सत्यापित करने का एक सरल पर्याप्त तरीका है कि किसी अन्य वातावरण में तैनात करने में कोई समस्या नहीं है।

एक बार में 2 सर्वरों को तैनात करें

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

लाइनों से डरो मत

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

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

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

स्केलिंग के लिए माइक्रोसर्विस

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

कंटेनरों का उपयोग करें

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

कुबेरनेट्स एक जटिल जानवर हो सकता है, लेकिन एक जानवर जो एक जटिल समस्या को हल करता है। यदि आप एक अनुभवहीन DevOps जादूगर हैं, तो आपको कठिनाई हो सकती है, इसलिए मैं ड्राफ्ट के साथ शुरू करने की सलाह देता हूं। यदि आप जावास्क्रिप्ट परियोजनाओं के लिए योमन से परिचित हैं, तो आप ड्राफ्ट का मूल्यांकन एक समान उपकरण के रूप में कर सकते हैं, लेकिन कुबेरनेट परियोजनाओं के लिए: एक उपकरण जो आपकी परियोजना के लिए एक वायरफ्रेम बनाता है। वहां से, आप आर्किटेक्चर के अतिरिक्त टुकड़ों को स्थापित करने के लिए हेल्म टूल का उपयोग कर सकते हैं, जिन्हें आपको कुबेटीज़ के लिए लगभग दोपहर के समय npm की तरह (उदा। Nginx, अधिक Node.js, MongoDB, Kafka सर्वर, आदि) बनाने की आवश्यकता है।

जैसे ही आप कुबेरनेट्स पारिस्थितिकी तंत्र को समझते हैं, अब से, क्लाउड में तैनात करना बच्चों का खेल बन जाएगा।

मैट्रिक्स लीजिए

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

इन संकेतकों को इकट्ठा करने के कई तरीके हैं। नई अवशेष और AppDynamics जैसी सेवाएं आपको अपने आवेदन को बेहतर बनाने के बारे में अमूल्य जानकारी प्रदान करेंगी।

यदि आप एज़्योर के साथ काम करते हैं, तो एप्लिकेशन इनसाइट्स भी इस आवश्यकता का सामना करती हैं, और यह भी CI / CD जैसे अन्य टूल में प्लग इन करना आसान है।

CI / CD आपको इतने दर्द से बचाएगा

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

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

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

कई ओपन सोर्स वेंडर और प्रोजेक्ट्स इन जरूरतों को संबोधित करते हैं। जेनकिंस, ट्रैविस और सर्किलसीआई सीआई के लिए बेहतरीन विकल्प हैं। Azure की अपनी CI / CD सेवा है जिसे Azure पाइपलाइन कहा जाता है, और यह उपयोग करने के लिए बहुत सहज है, और फिर से, यह आसानी से एकीकृत Azure पारिस्थितिकी तंत्र से जुड़ जाता है।

राज़ रखो

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

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

आपके ध्यान के योग्य एक और उपकरण एज़्योर की वॉल्ट है । कुंजी तिजोरी के बारे में क्या अच्छा है, भले ही Microsoft आपकी कुंजियों को नहीं पढ़ सकता है (केवल आप उन्हें डिक्रिप्ट कर सकते हैं), Azure आपके लॉग का ट्रैक रखेगा और आपकी कुंजियों के किसी भी संदिग्ध उपयोग को ट्रैक करने के लिए आपको किसी भी समझौते के प्रति सचेत करेगा।

निष्कर्ष

Node.js, किसी भी अन्य मंच की तरह, स्केल किए जाने की आवश्यकता है। और, किसी भी अन्य मंच की तरह, इसके अपने कार्य हैं और स्केलिंग की ख़ासियत है, जो जानने लायक हैं और जिन्हें बड़ी परियोजनाओं को डिज़ाइन करते समय ध्यान में रखा जाना चाहिए।

मूल लेख: "स्केल टिप्स को Node.js" ( En )।

मैं टिप्पणियों में सुझाव देता हूं कि आप Node.js. को स्केल करने के लिए सुझाव दे सकते हैं यह सुनना दिलचस्प होगा।