यह उत्तर अन्य लोगों के लिए पूरक है और बताता है कि यूनिकॉर्न को इसके सामने nginx की आवश्यकता क्यों है ।
टीएल; डॉ । कारण यह है कि यूनिकॉर्न को आमतौर पर नग्नेक्स जैसे रिवर्स प्रॉक्सी के साथ एक साथ तैनात किया जाता है, क्योंकि इसके रचनाकारों ने जानबूझकर इसे डिजाइन किया है, जो सादगी के लिए एक व्यापार बनाता है।
सबसे पहले, यूनिकॉर्न को रिवर्स प्रॉक्सी के बिना तैनात करने से आपको कुछ नहीं रखना है । हालाँकि, यह एक बहुत अच्छा विचार नहीं होगा; आइए देखें क्यों।
यूनिकॉर्न यूनिक्स दर्शन का अनुसरण करता है जो कि एक काम करना है और इसे अच्छी तरह से करना है , और वह है तेज, कम-विलंबता ग्राहकों की सेवा करना (हम देखेंगे कि बाद में इसका क्या मतलब है)। तथ्य यह है कि यूनिकॉर्न तेजी से, कम-विलंबता ग्राहकों के लिए डिज़ाइन किया गया है , यह भी बताता है कि यह धीमी, उच्च-विलंबता ग्राहकों के साथ बहुत अच्छा नहीं है , जो वास्तव में सच है। यह यूनिकॉर्न के कमजोर बिंदुओं में से एक है और यह वह जगह है जहां रिवर्स प्रॉक्सी खेल में आता है: यह यूनिकॉर्न के सामने बैठता है और उन धीमे क्लाइंट्स का ख्याल रखता है (हम देखेंगे कि बाद में कैसा होगा )।
सौभाग्य से, इस तरह के एक रिवर्स प्रॉक्सी पहले से ही मौजूद है और इसे नगीनेक्स कहा जाता है ।
केवल तेजी से ग्राहकों को संभालने का निर्णय, यूनिकॉर्न के डिजाइन को बहुत सरल करता है और तैनाती विभाग पर कुछ अतिरिक्त जटिलता की कीमत पर (बहुत सरल और छोटे कोडबेस की अनुमति देता है।
एक वैकल्पिक निर्णय यूनिकॉर्न को इस तरह से डिजाइन किया जा सकता है कि उसे रिवर्स प्रॉक्सी की आवश्यकता न हो। हालांकि, इसका मतलब है कि यह उन सभी चीजों को करने के लिए अतिरिक्त कार्यक्षमता को लागू करना होगा जो अब nginx करता है, जिसके परिणामस्वरूप एक अधिक जटिल कोडबेस और अधिक इंजीनियरिंग प्रयास होते हैं।
इसके बजाय इसके रचनाकारों ने मौजूदा सॉफ़्टवेयर का लाभ उठाने का निर्णय लिया, जो कि युद्ध-परीक्षण और बहुत अच्छी तरह से डिज़ाइन किया गया और पहले से ही अन्य सॉफ़्टवेयर द्वारा हल की गई समस्याओं पर समय और ऊर्जा बर्बाद करने से बचने के लिए।
लेकिन चलो तकनीकी हो और अपने प्रश्न का उत्तर दें:
यूनिकॉर्न को नगनेक्स के साथ एक साथ तैनात करने की आवश्यकता क्यों है?
यहाँ कुछ प्रमुख कारण दिए गए हैं:
ग्राहकों के लिए यूनिकॉर्न अवरुद्ध I / O का उपयोग करता है
रिवर्स प्रॉक्सी पर निर्भर होने का अर्थ है कि यूनिकॉर्न को गैर-अवरोधक I / O का उपयोग करने की आवश्यकता नहीं है । इसके बजाय यह अवरुद्ध I / O का उपयोग कर सकता है जो प्रोग्रामर के लिए स्वाभाविक रूप से सरल और आसान है।
के रूप में भी डिजाइन दस्तावेज़ कहता है:
[ब्लॉकिंग आई / ओ का उपयोग करना] रूबी दुभाषिया और कम सीस्कॉल के भीतर एक सरल कोड पथ का पालन करने की अनुमति देता है।
हालाँकि, इसके कुछ परिणाम भी हैं:
मुख्य बिंदु # 1: यूनिकॉर्न धीमे ग्राहकों के साथ कुशल नहीं है
(सादगी के लिए, हम 1 यूनिकॉर्न कार्यकर्ता के साथ एक सेटअप मानते हैं)
चूंकि I / O को अवरुद्ध करने के लिए उपयोग किया जाता है, एक गेंडा कार्यकर्ता एक समय में केवल एक ग्राहक की सेवा कर सकता है , इसलिए एक धीमा ग्राहक (यानी एक धीमी कनेक्शन वाला) प्रभावी रूप से कार्यकर्ता को लंबे समय तक व्यस्त रखेगा (एक तेज ग्राहक की तुलना में) )। इस बीच, अन्य ग्राहक बस इंतजार करेंगे जब तक कि कार्यकर्ता फिर से मुक्त न हो जाए (यानी; अनुरोध कतार में ढेर हो जाएंगे)।
इस समस्या को हल करने के लिए, यूनिकॉर्न के सामने एक रिवर्स प्रॉक्सी तैनात है, जो आने वाले अनुरोधों और एप्लिकेशन प्रतिक्रियाओं को पूरी तरह से बफ़र करता है , और फिर उनमें से प्रत्येक को एक बार (उर्फ चम्मच-फीड्स) यूनिकॉर्न और क्लाइंट्स को क्रमशः भेजता है। उस संबंध में, आप कह सकते हैं कि रिवर्स प्रॉक्सी धीमी नेटवर्क क्लाइंट्स से यूनिकॉर्न "ढाल" है।
सौभाग्य से Nginx इस भूमिका के लिए एक महान उम्मीदवार है, क्योंकि इसे कुशलतापूर्वक हजारों सैकड़ों समवर्ती ग्राहकों को संभालने के लिए डिज़ाइन किया गया है।
यह महत्वपूर्ण महत्व है कि रिवर्स प्रॉक्सी एक ही स्थानीय नेटवर्क के भीतर होना चाहिए जैसा कि यूनिकॉर्न (आमतौर पर एक ही भौतिक मशीन में w / यूनिकॉर्न एक यूनिक्स डोमेन सॉकेट के माध्यम से संचार करता है), ताकि नेटवर्क विलंबता को न्यूनतम रखा जाए।
तो ऐसा प्रॉक्सी प्रभावी रूप से एक तेज़ क्लाइंट की भूमिका निभाता है जिसे यूनिकॉर्न को पहली जगह पर सेवा देने के लिए डिज़ाइन किया गया है, क्योंकि यह यूनिकॉर्न के लिए तेजी से अनुरोध करता है और श्रमिकों को कम से कम समय के लिए व्यस्त रखता है (ग्राहक की तुलना में कितना समय लगता है धीमी गति से कनेक्शन के साथ होगा)।
मुख्य बिंदु # 2: गेंडा HTTP / 1.1 रखने-जीवित का समर्थन नहीं करता है
चूंकि यूनिकॉर्न ब्लॉकिंग आई / ओ का उपयोग करता है, इसका मतलब यह भी है कि यह HTTP / 1.1 की-लाइव सुविधा का समर्थन नहीं कर सकता है, क्योंकि धीमे क्लाइंट के लगातार कनेक्शन सभी उपलब्ध यूनिकॉर्न श्रमिकों पर जल्दी से कब्जा कर लेंगे।
इसलिए HTTP कीप-लिवर का लाभ उठाने के लिए, अनुमान लगाएं: रिवर्स प्रॉक्सी का उपयोग किया जाता है।
दूसरी ओर nginx, बस कुछ धागे का उपयोग करके हजारों समवर्ती कनेक्शनों को संभाल सकता है। इसलिए, इसमें समरूपता नहीं है, जैसे कि यूनिकॉर्न के पास सर्वर है (जो अनिवार्य रूप से कार्यकर्ता प्रक्रियाओं की मात्रा तक सीमित है), जिसका अर्थ है कि यह लगातार कनेक्शन को ठीक से संभाल सकता है। यह वास्तव में कैसे काम करता है, इसके बारे में और अधिक जानकारी यहाँ मिल सकती है ।
यही कारण है कि nginx क्लाइंट से जीवित कनेक्शन को स्वीकार करता है और उन्हें आम तौर पर Unix सॉकेट के माध्यम से सादे कनेक्शन पर Unicorn करने के लिए कहता है।
पॉइंट # 3: स्टैटिक फाइल्स को सर्व करने में यूनिकॉर्न बहुत अच्छा नहीं है
फिर से, स्थिर फ़ाइलों की सेवा एक ऐसी चीज़ है जो यूनिकॉर्न कर सकता है लेकिन कुशलतापूर्वक करने के लिए डिज़ाइन नहीं किया गया है।
दूसरी तरफ, नांजेक्स जैसे रिवर्स प्रॉक्सिस हालांकि इस पर बहुत बेहतर हैं (यानी। sendfile(2)और कैशिंग)।
अधिक
वहाँ अन्य अंक जो में दिए गए हैं कर रहे हैं दर्शन दस्तावेज़ (देखें "रिवर्स प्रॉक्सी के माध्यम से बेहतर प्रदर्शन" )।
नगीनेक्स की कुछ बुनियादी विशेषताओं को भी देखें ।
हम देखते हैं कि मौजूदा सॉफ़्टवेयर (यानी। नॅग्नेक्स) का लाभ उठाते हुए और "एक काम कर रहे हैं और इसे अच्छी तरह से करते हैं" के यूनिक्स दर्शन का पालन करते हुए, यूनिकॉर्न रैक ऐप्स की सेवा में कुशल होने के लिए एक सरल डिजाइन और कार्यान्वयन का पालन करने में सक्षम है (जैसे। अपने रेल एप्लिकेशन)।
अधिक जानकारी के लिए यूनिकॉर्न के दर्शन और डिजाइन दस्तावेजों का संदर्भ लें, जो यूनिकॉर्न के डिजाइन के पीछे के विकल्पों के बारे में अधिक विस्तार से बताते हैं और क्यों नाइनएक्स को यूनिकॉर्न के लिए एक अच्छा रिवर्स-प्रॉक्सी माना जाता है।
