आप मजाक कर रहे होंगे, मिस्टर डाहल, या क्यों Node.js वेब सर्वर के विकास का ताज है

Node.js एक ऐसी चीज़ है जिसके चारों ओर बहुत अधिक शोर, बड़बड़ाहट और गुस्से के शोर हैं। उसी समय, मेरी टिप्पणियों के अनुसार, लोगों के दिमाग में Node.js को तय करने के बारे में निम्नलिखित विचार है: "यह एक ऐसी चीज है जो आपको सर्वर पर जावास्क्रिप्ट लिखने की अनुमति देती है और Google क्रोम से जावास्क्रिप्ट इंजन का उपयोग करती है।" जीभ के प्रशंसकों ने उत्साह से कहा: “आह! यह सच हो गया! ", विरोधियों ने अपने दाँत पीस लिए:" ठीक है, अभी भी हमारे पास सर्वरों पर प्रोटोटाइप और डायनामिक टाइपिंग के साथ इस बकवास के लिए पर्याप्त नहीं है! " और एक साथ वे ब्लॉग और मंचों में भाले तोड़ने के लिए दौड़े।



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





तो Node.js क्या है? आधिकारिक वेबसाइट पर एक शिलालेख है: "V8 जावास्क्रिप्ट के लिए ई / ओ की घटना"। बहुत सार्थक नहीं, है ना? ठीक है, चलो "एक साइकिल का आविष्कार" करने की कोशिश करते हैं और "सोचते हैं" इस कुख्यात "इवेंटेड I / O के लिए V8 जावास्क्रिप्ट"। बेशक, हम कोई कोड नहीं लिखेंगे (खराब रयान अभी भी ऐसा करना था), लेकिन बस निष्कर्ष की एक श्रृंखला बनाने की कोशिश करें जो हमें Node.js बनाने के विचार की ओर ले जाएगी और इसे कैसे व्यवस्थित किया जाना चाहिए।

इसे सरल, मूर्ख बनाए रखें

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







इसलिए, हमारे पास सबसे सरल वेब सर्वर का एक मॉडल है - एक प्रोग्राम जो ब्राउज़र क्लाइंट से अनुरोध प्राप्त करता है, उन्हें संसाधित करता है और प्रतिक्रिया देता है।

समानांतर ब्रह्मांड

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







एक रूप या किसी अन्य में, यह दृष्टिकोण आज के कई लोकप्रिय वेब सर्वरों (उदाहरण के लिए, अपाचे और आईआईएस ) द्वारा पीछा किया जाता है। यह मॉडल लागू करने के लिए अपेक्षाकृत सरल है और एक ही समय में आज सबसे छोटे और मध्यम आकार के वेब संसाधनों की जरूरतों को पूरा कर सकता है।



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

अनंतता की सीमा नहीं है!

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



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







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

चलो एक साथ आते हैं

लेकिन (हमेशा एक "एक लेकिन" होता है), इससे पहले कि हम इस विचार से शुरू करते हैं कि एक प्रतिक्रिया उत्पन्न करने से एक ग्राहक के साथ संवाद करने की तुलना में कम समय का परिमाण होता है। और यह आंशिक रूप से सच है। फिर भी, कभी-कभी एक प्रतिक्रिया उत्पन्न करना एक जटिल और जटिल कार्य हो सकता है, जिसमें एक डिस्क के साथ पढ़ना और लिखना शामिल हो सकता है, डेटाबेस के साथ काम करना (जो दूरस्थ सर्वर पर भी स्थित हो सकता है)। खैर, यह पता चला है कि हम वास्तव में मूल समस्या पर लौट आए हैं। व्यवहार में, इसे निम्नानुसार हल किया जाता है: सिस्टम को दो भागों में विभाजित किया जाता है - फ्रंट-एंड और बैक-एंड । फ्रंट-एंड एक सर्वर है जिसके साथ क्लाइंट सीधे संवाद करता है। एक नियम के रूप में, यह एक अतुल्यकालिक घटना मॉडल वाला एक सर्वर है, जो ग्राहकों के साथ संचार को जल्दी से स्थापित कर सकता है और उन्हें अनुरोध के परिणाम दे सकता है (उदाहरण के लिए, nginx)। बैक-एंड एक सर्वर है जिसमें एक अवरुद्ध I / O मॉडल (उदाहरण के लिए, अपाचे) है, जिसके लिए सामने वाला क्लाइंट के लिए एक प्रतिक्रिया के निर्माण को दर्शाता है, ठीक उसी तरह जैसे कि I / O सबसिस्टम के साथ होता है। इस तरह के फ्रंट-एंड को " रिवर्स प्रॉक्सी " भी कहा जाता है, क्योंकि वास्तव में यह एक सामान्य प्रॉक्सी सर्वर है , लेकिन उसी सर्वर वातावरण में स्थापित होता है, जिस सर्वर पर यह रिडायरेक्ट करता है।



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

और रीपर, और श्वेत, और पाइप पर इगेट (ऐसा प्रतीत होता है, जावास्क्रिप्ट को इसके साथ क्या करना है?)

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



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



जाहिर है, शुरुआत के लिए, हमें एक रनटाइम वातावरण की आवश्यकता होती है, जिनमें से मुख्य आवश्यकताएं प्रतिक्रिया पीढ़ी कोड और एसिंक्रोनस इनपुट / आउटपुट के तेजी से निष्पादन हैं। आधुनिक प्रोग्रामिंग भाषा क्या घटना मॉडल के अनुरूप है, सभी वेब डेवलपर्स के लिए जाना जाता है और एक ही समय में तेजी से और तेजी से विकासशील कार्यान्वयन है? जवाब स्पष्ट है - यह जावास्क्रिप्ट है। इसके अलावा, हमारे पास Google से हमारे निपटान जावास्क्रिप्ट इंजन V8 है , जो एक बहुत ही उदार बीएसडी-लाइसेंस के तहत वितरित किया गया है। V8 कई पहलुओं में सुंदर है: सबसे पहले, यह JIT संकलन और कई अन्य अनुकूलन तकनीकों का उपयोग करता है, और दूसरी बात, यह एक अच्छी तरह से निर्मित, विचारशील और सक्रिय रूप से विकसित सॉफ्टवेयर उत्पाद का एक उदाहरण है (आमतौर पर मैं V8 को वास्तव में उच्च-गुणवत्ता का एक उदाहरण देता हूं। काम पर सहयोगियों के लिए सी ++ कोड)। इन सभी कामेच्छा पुस्तकालय में जोड़ें, जो हमें आसानी से ईवेंट लूप को व्यवस्थित करने और मतदान तंत्र के लिए एक उच्च-स्तरीय आवरण प्रदान करने की अनुमति देगा (इसलिए हमें विभिन्न ऑपरेटिंग सिस्टम के लिए इसके कार्यान्वयन की सुविधाओं के बारे में चिंता करने की ज़रूरत नहीं है)। हमें तेज एसिंक्रोनस फ़ाइल I / O के लिए libeio लाइब्रेरी की भी आवश्यकता है। खैर, इस पर हमारे रनटाइम को तैयार माना जा सकता है।



और, निश्चित रूप से, हमें एक मानक पुस्तकालय की आवश्यकता है जिसमें सभी मूल I / O संचालन और कार्यों के लिए जावास्क्रिप्ट रैपर होंगे जिनके बिना आप वेब विकास में नहीं जा सकते हैं (उदाहरण के लिए, HTTP हेडर और URL पार्स करना, हैश की गिनती करना, DNS- संकल्प करना, आदि)।







यह शायद हमें बधाई देने के लायक है - हम सिर्फ एक बहुत तेज सर्वर की अवधारणा के साथ आए थे - Node.js.

मैं सिर्फ कह रहा हूं '

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

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