आपको नगनेक्स के लिए मॉड्यूल बनाने की आवश्यकता क्यों है

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



सामान्य तौर पर, नगनेक्स में सब कुछ मॉड्यूल है जो एक बार किसी द्वारा लिखे गए थे। इसलिए, नगनेक्स के तहत मॉड्यूल लिखना न केवल संभव है, बल्कि आवश्यक भी है। जब यह करना आवश्यक है और क्यों, वसीली सोशनिकोव ( dedokOne ) कई मामलों के उदाहरण पर बताएगा।

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

नोट: लेख वसीली सोशनिकोव की एक रिपोर्ट पर आधारित है। रिपोर्ट को लगातार अपडेट और अपडेट किया जा रहा है। सामग्री में जानकारी काफी तकनीकी है और इसका अधिकतम लाभ उठाने के लिए, पाठकों को औसत स्तर और उससे ऊपर के नगनेक्स कोड के साथ काम करने का अनुभव होना चाहिए।

संक्षेप में nginx के बारे में

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

Nginx.conf में निर्देश भी एक विशिष्ट समस्या को हल करने वाले मॉड्यूल हैं । इसलिए, नेगनेक्स मॉड्यूल में सब कुछ है। add_header ,xy_pass, किसी भी निर्देश - ये मॉड्यूल या मॉड्यूल के संयोजन हैं जो कुछ नियमों के अनुसार काम करते हैं।

Nginx एक ढांचा है जिसमें है: नेटवर्क और फ़ाइल I / O, साझा मेमोरी, कॉन्फ़िगरेशन और स्क्रिप्टिंग। यह निम्न-स्तरीय पुस्तकालयों की एक विशाल परत है, जिस पर आप नेटवर्क ड्राइव के साथ काम करने के लिए कुछ भी कर सकते हैं।

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

अपने खुद के मॉड्यूल क्यों बनाएं

HTTP प्रोटोकॉल को दूसरे प्रोटोकॉल में बदलें। यह मुख्य कारण है जो अक्सर किसी विशेष मॉड्यूल के निर्माण को प्रेरित करता है।

उदाहरण के लिए, memcached_pass मॉड्यूल HTTP को दूसरे प्रोटोकॉल में कनवर्ट करता है, और आप अन्य बाहरी सिस्टम के साथ काम कर सकते हैं। प्रॉक्सी_पास मॉड्यूल आपको HTTP (एस) से एचटीटीपी (एस) तक परिवर्तित करने की अनुमति देता है। एक और अच्छा उदाहरण fastcgi_pass है।

ये सभी फॉर्म के निर्देश हैं: "ऐसे और ऐसे बैकेंड पर जाएं, जहां HTTP नहीं है (लेकिन प्रॉक्सी_पास HTTP के मामले में)।"

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

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

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

सभी प्रकार की सामग्री को परिवर्तित करना। उदाहरण के लिए, rtmp मॉड्यूल आपको केवल rtmp के साथ ही नहीं, बल्कि HLS के साथ भी काम करने की अनुमति देता है। यह मॉड्यूल वीडियो सामग्री के साथ बहुत कुछ कर सकता है।

सामान्य प्राधिकरण बिंदु: एसईपी या एपि गेटवे। यह ऐसा मामला है जब nginx बुनियादी ढांचे के हिस्से के रूप में काम करता है: अधिकृत करता है, मैट्रिक्स एकत्र करता है, निगरानी और ClickStream को डेटा भेजता है। Nginx यहाँ एक बुनियादी ढाँचे के रूप में काम करता है - बैकएंड के लिए एक एकल प्रवेश बिंदु।

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

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

मॉड्यूल बनाने का समय कब है

यह समझने के लिए दो मानदंड हैं कि समय आ गया है।

कार्यक्षमता का सामान्यीकरण। जब आप समझते हैं कि किसी और को आपके उत्पाद की आवश्यकता है, तो आप इसे ओपन सोर्स में योगदान दे रहे हैं, सामान्यीकृत कार्यक्षमता बना रहे हैं, इसे पोस्ट कर रहे हैं और इसका उपयोग करने दे रहे हैं।

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

Nginx वास्तुकला

मैं एक लंबे समय से nginx कोड लिख रहा हूं। मेरे मॉड्यूल के नौ उत्पादन में कताई कर रहे हैं, उनमें से एक ओपन सोर्स में है, और कई के लिए उत्पादन में है। इसलिए, मेरे पास अनुभव और समझ है।

Nginx एक नेस्टिंग डॉल है जिसमें कर्नेल के चारों ओर सब कुछ बनाया गया है।

तो मैं नगीने समझता हूं।

कोर एपोल के ऊपर रैपर हैं।

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

कोर के ऊपर अपस्ट्रीम, HTTP और स्क्रिप्टिंग हैं। स्क्रिप्टिंग से मेरा मतलब है nginx.conf, NJS नहीं। अपस्ट्रीम, HTTP और स्क्रिप्टिंग के ऊपर, HTTP मॉड्यूल पहले से ही निर्मित हैं, जिनके बारे में हम बात करेंगे।



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

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

HTTP मॉड्यूल के एनाटॉमी

भले ही आप C कोड को nginx के अंदर नहीं लिखते हैं, लेकिन इसका उपयोग करें, मुख्य नियम को याद रखें।

नेगनेक्स में, सब कुछ जिम्मेदारी की श्रृंखला का पालन करता है - कोर पैटर्न।

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



एनजेएस और लुआ में कुछ निर्देशों का उपयोग करते समय मॉड्यूल का विकास या, यह मत भूलो कि आपका कोड इस श्रृंखला के निष्पादन को क्रैश कर सकता है।

जिम्मेदारी की श्रृंखला के निकटतम सादृश्य बैश कोड की एक पंक्ति है:

grep -RI pool nginx | awk -F":" '{print $1}' | sort -u | wc -l 

कोड में, सब कुछ काफी सरल है: अगर AWK लाइन के बीच में गिर गया, तो sort और निम्न कमांड निष्पादित नहीं किए जाएंगे। Nginx मॉड्यूल समान रूप से काम करता है, लेकिन सच्चाई nginx में है और आप इसके आसपास प्राप्त कर सकते हैं - कोड को पुनरारंभ करें। लेकिन आपको अपने मॉड्यूल की तरह ही क्रैश और चलाने के लिए तैयार रहना चाहिए, जिसका उपयोग आप कॉन्फिगरेशन में करते हैं, लेकिन इस तथ्य से नहीं।

HTTP मॉड्यूल के प्रकार

HTTP और nginx विभिन्न PHASEs का एक समूह है।

• चरण हैंडलिंग - PHASE हैंडलर ।
• फिल्टर - बॉडी / हेडर्स फिल्टर । यह फ़िल्टरिंग या तो हेडर है या निकायों का अनुरोध करता है।
• समीपता । विशिष्ट प्रॉक्सी मॉड्यूल प्रॉक्सी_पास, फास्टसीजी_पास, मेम्केड_पास हैं।
• विशिष्ट लोड संतुलन के लिए मॉड्यूल - लोड बैलेंसर्स । यह सबसे अछूता प्रकार के मॉड्यूल हैं, उन्हें ज्यादा विकसित नहीं किया जा रहा है। एक उदाहरण केतमा चाश मॉड्यूल है, जो आपको बैकएंड के लिए अनुरोधों को वितरित करने के लिए नेग्नेक्स के अंदर सुसंगत हैशिंग करने की अनुमति देता है।

मैं इनमें से प्रत्येक प्रकार और उनके उद्देश्य के बारे में बताऊंगा।

चरण संचालकों

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



अंतिम, अंतिम हैंडलर कंटेंट चरण है जिसमें मांग के आधार पर सामग्री वितरित की जाती है।

तरीका हमेशा यह होता है: अनुरोध - हैंडलर्स की एक श्रृंखला - आउटपुट सामग्री।

NGINX स्रोतों से मॉड्यूल के डेवलपर्स के लिए उपलब्ध चरण:

 typedef enum { NGX_HTTP_POST_READ_PHASE = 0, NGX_HTTP_SERVER_REWRITE_PHASE, NGX_HTTP_FIND_CONFIG_PHASE, NGX_HTTP_REWRITE_PHASE, NGX_HTTP_POST_REWRITE_PHASE, NGX_HTTP_PREACCESS_PHASE, NGX_HTTP_ACESS_PHASE, NGX_HTTP_POST_ACESS_PHASE, NGX_HTTP_PRECONTENT_PHASE, NGX_HTTP_CONTENT_PHASE, NGX_HTTP_LOG_PHASE, } ngx_http_phases; 

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

मुख्य एक ACCESS_PHASE है। एक्सेस के संदर्भ में अनुरोध के निष्पादन की जांच करने के लिए, अपने प्राधिकरण को nginx में जोड़ना विशेष रूप से उपयोगी है।

अगले महत्वपूर्ण चरण जिनका मैं अक्सर शोषण करता हूं वे पूर्ववर्ती और सामग्री के चरण हैं। PRECONTENT_PHASE आपको क्लाइंट के प्रतिसाद के रूप में भेजी जाने वाली सामग्री के बारे में मीट्रिक एकत्र करने की अनुमति देता है। CONTENT_PHASE आपको किसी चीज़ के आधार पर अपनी अनूठी सामग्री तैयार करने की अनुमति देता है।

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

मैं समझाऊंगा कि यह कष्टप्रद क्यों है। मान लीजिए कि आप लॉगिंग चरण में nginx और Kafka को पार करना चाहते हैं। इस चरण में, सब कुछ पहले ही पूरा हो चुका है: सामग्री, स्थिति, सभी डेटा का एक परिकलित आकार है, लेकिन आप इसे उप-वर्ग में नहीं कर सकते। वे वहां काम नहीं करते हैं। आपको काफ्का को डेटा भेजने के लिए लॉगिंग चरण में नंगे सॉकेट पर लिखना होगा।

बॉडी / हेडर्स फिल्टर

दो प्रकार के फिल्टर हैं: बॉडी फिल्टर और हेडर फिल्टर।

बॉडी फ़िल्टर का एक उदाहरण है- gzip फ़िल्टर मॉड्यूल। बॉडी फिल्टर की आवश्यकता क्यों है? कल्पना करें कि आपके पास एक निश्चित प्रॉक्सी_पास है, और आप किसी तरह सामग्री को बदलना चाहते हैं या उसका विश्लेषण करना चाहते हैं। ऐसे में आपको बॉडी फिल्टर का इस्तेमाल करना चाहिए।

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

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

वैसे, बॉडी फ़िल्टर में और हैडर फ़िल्टर में उप-उपलब्धियाँ उपलब्ध हैं, आप आंतरिक पहचान को अतिरिक्त स्थान पर भी भेज सकते हैं।

प्रतिनिधि

यह सबसे जटिल और विवादास्पद प्रकार है जो आपको बाहरी सिस्टम के लिए प्रॉक्सी अनुरोधों की अनुमति देता है, उदाहरण के लिए, HTTP को दूसरे प्रोटोकॉल में परिवर्तित करें । उदाहरण: प्रॉक्सी_पास, रेडिस_पास, टेंट_पास।

प्रॉक्सी एक इंटरफ़ेस है जिसे nginx कोर डेवलपर्स ने लिखने के प्रॉक्सी मॉड्यूल को आसान बनाने का प्रस्ताव दिया है। यदि यह शास्त्रीय तरीके से किया जाता है, तो इस तरह के एक प्रॉक्सी PHASES हैंडलर, फिल्टर के लिए, Balancers निष्पादित किया जाएगा। हालाँकि, यदि आप जिस प्रोटोकॉल को HTTP में बदलना चाहते हैं, वह किसी तरह क्लासिक्स से अलग है, तो बड़ी समस्याएं शुरू हो जाती हैं। प्रॉक्सी एपीआई जो नगनेक्स देता है, बस उपयुक्त नहीं है - आपको खरोंच से इस प्रॉक्सी मॉड्यूल का आविष्कार करना होगा।

इस तरह के एक मॉड्यूल का एक अच्छा उदाहरण postgres_pass है। यह निग्नेक्स को PostgreSQL के साथ संवाद करने की अनुमति देता है। मॉड्यूल उस इंटरफ़ेस का उपयोग नहीं करता है जो कि nginx में बिल्कुल विकसित किया गया था - इसका अपना रास्ता है।

प्रॉक्सी याद रखें, लेकिन अधिमानतः नहीं लिखें। प्रॉक्सी लिखने के लिए, आपको दिल से सभी नगेंक्स को सीखना होगा - यह बहुत लंबा और कठिन है।

बैलेंसर्स लोड करें

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

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

C मॉड्यूल

आगे C- मॉड्यूल के विकास पर मेरी पूरी तरह से व्यक्तिपरक राय होगी। शुरू करने के लिए - मेरे व्यक्तिपरक नियम।

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

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

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

सही मेमोरी पूल का उपयोग करें। इसे हमेशा ध्यान में रखें, भले ही आपको नगनेक्स के साथ बहुत अनुभव हो। नग्नेक्स के लिए एक नौसिखिया सी मॉड्यूल डेवलपर की एक विशिष्ट गलती गलत पूल प्राप्त करना है।

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

इसके अलावा, इस तरह की त्रुटियों को शुरू करना बेहद मुश्किल है। Valgrind ("syshniks" समझ जाएगा) स्लैब आवंटन के साथ काम नहीं करता है - यह एक अजीब तस्वीर दिखाएगा।

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

आप मल्टी-थ्रेडिंग कर सकते हैं, लेकिन, एक नियम के रूप में, यह केवल इसे बदतर बनाता है। यदि आप ऐसी वास्तुकला में I / O को अवरुद्ध करने का उपयोग करते हैं, तो हर कोई इस अवरुद्ध टुकड़े की प्रतीक्षा कर रहा होगा।

मैंने जो कहा, उसे मैं समझूंगा।

मॉड्यूल nginx.conf निर्देशों के साथ शुरू होता है

तय करें कि आपके निर्देश को किस दिशा में रहना चाहिए: मुख्य, सर्वर, एचटीटीपी, स्थान, स्थान।

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

नगीनेक्स में सभी निर्देश अलग-अलग संदर्भों में और अलग-अलग दायरे में रहते हैं। Add_header निर्देश HTTP-स्तर पर, स्थान-स्तर पर, स्थान-यदि-स्तर पर काम कर सकता है। यह आमतौर पर प्रलेखन में वर्णित है।

समझें कि आपका निर्देश किस स्तर पर काम कर सकता है, जहां निर्देश निष्पादित किया गया है: PHASE हैंडलर, बॉडी / हैडर फ़िल्टर।

यह महत्वपूर्ण है क्योंकि nginx में कॉन्फिग जम गया है। अधिवेशन द्वारा, जब आप ऊपर कहीं और add_header लिखते हैं, तो यह मान नीचे add_header में सुचारू हो जाता है, जो आपके पास पहले से ही है। तदनुसार, आप दो हेडर जोड़ेंगे। यह किसी भी निर्देश पर लागू होता है।

यदि आप कुछ होस्ट पोर्ट निर्दिष्ट करते हैं, तो इसके विपरीत - सॉकेट्स का पूल। इसे एक बार इंगित किया जाना चाहिए।

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

अच्छा उदाहरण:

 location /my_location/ { add_header “My-Header” “my value”; } 

यहाँ add_header को केवल स्थान पर जोड़ा गया है। एक ही add_header ऊपर कहीं हो सकता है, और सब कुछ बस इसके विपरीत होगा। यह एक प्रलेखित और समझने योग्य व्यवहार है।

इस बारे में सोचें कि निर्देश के कार्यान्वयन में क्या बाधा हो सकती है।

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

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

Nginx कोड शैली

जब आपने उत्पाद बनाया, तो याद रखें कि कोई इसका समर्थन करेगा। कोड शैली nginx के बारे में मत भूलना।

अपने nginx मॉड्यूल को लिखने से पहले, अपने आप को स्रोत से परिचित कराएं: एक और दूसरा ।

यदि भविष्य में आप नगनेक्स मॉड्यूल के विकास को लेते हैं, तो आप नगीनेक्स स्रोतों से अच्छी तरह से वाकिफ होंगे। कोई दस्तावेज नहीं होने के कारण आप उनसे प्यार करेंगे। आप nginx निर्देशिका संरचना को अच्छी तरह से सीखेंगे, Grep का उपयोग करना सीख सकते हैं, संभवतः Sed, जब आपको कुछ टुकड़े nginx से अपने मॉड्यूल में स्थानांतरित करने की आवश्यकता होती है।

मेमोरी पूल

ताल का सही उपयोग किया जाना चाहिए। उदाहरण के लिए, "r-> कनेक्शन-> पूल! = R-> पूल"। किसी भी मामले में आप स्मृति पूल कॉन्फ़िगरेशन का उपयोग नहीं कर सकते हैं जब प्रसंस्करण अनुरोध, यह तब तक प्रफुल्लित होगा जब तक कि नग्नेक्स पुनरारंभ नहीं हो जाता।

वस्तु के जीवनकाल को समझें। मान लीजिए कि अनुरोध पुनरावृत्ति में वास्तव में यह पाइपलाइन है। इस पूल में आप बहुत सी चीजें रख सकते हैं और कमरा बना सकते हैं। कनेक्शन सैद्धांतिक रूप से अनिश्चित काल तक रह सकता है - इसमें वास्तव में महत्वपूर्ण चीज को जगह देना बेहतर है।

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

Valgrind के प्रशंसकों के लिए एक हैक है जो आपको Valgrind का उपयोग करके nginx-pool को डीबग करने की अनुमति देता है। यह महत्वपूर्ण है अगर आपके पास nginx पर बहुत सी कोड है, क्योंकि स्मृति के साथ काम करने में एक अनुभवी डेवलपर भी गलती कर सकता है।

अवरोधक I / O

यहां सब कुछ सरल है - अवरुद्ध I / O का उपयोग न करें।

अन्यथा, कम से कम रख-रखाव कनेक्शन के साथ समस्याएं होंगी, लेकिन अधिकतम के रूप में, सब कुछ बहुत लंबे समय तक काम करेगा।

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

लेकिन सी-मॉड्यूल का एक विकल्प है - एनजेएस और लुआ।

जब आपको सी-मॉड्यूल विकसित करने की आवश्यकता नहीं है

इस साल मुझे एनजेएस पर काम करने का मेरा पहला अनुभव था, मुझे इस पर एक व्यक्तिपरक छाप मिली, और मुझे एहसास भी हुआ कि वहां क्या गायब था, ताकि सब कुछ ठीक हो जाए। मैं अपने अनुभव के बारे में बात करना चाहूंगा कि नूनेक्स के तहत लूआ पर काम करना, और, इसके अलावा, लूआ में मौजूद समस्याओं को साझा करना।

Lua / LuaJit अनिवार्य है

Nginx Lua का उपयोग नहीं करता है, लेकिन LuaJit का। लेकिन यह Lua नहीं है, क्योंकि Lua पहले से ही दो संस्करणों को उन्नत कर चुका है, और LuaJit अतीत में कहीं फंस गया है। लेखक व्यावहारिक रूप से लुजिट का विकास नहीं करता है - वह अक्सर कांटे में रहता है। सबसे वर्तमान कांटा LuaJit2 है । यह उसी OpenResty में अजीब स्थितियों को जोड़ता है।

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

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

कई तैयार पुस्तकालयों का उपयोग करने में असमर्थता । Lua शुरू में अवरुद्ध है, इसलिए Lua और LuaJit पर अधिकांश पुस्तकालय अवरुद्ध I / O का उपयोग करते हैं। इस तथ्य के कारण कि निग्नेक्स अवरुद्ध नहीं है, नगीनक्स के अंदर तैयार पुस्तकालयों का उपयोग करना असंभव है जो किसी भी अवरुद्ध I या O का उपयोग करते हैं। यह नगीनक्स को धीमा कर देगा।

LuaJit का उपयोग करने के कारण मॉड्यूल का उपयोग करने के कारणों के समान हैं:

• जटिल मॉड्यूल के प्रोटोटाइप;
• HMAC, प्राधिकरणों के लिए SHA की गणना;
• बैलेंसर्स ;
• छोटे अनुप्रयोग: हेडर हैंडलर, रीडायरेक्ट के नियम;
• nginx.conf के लिए कंप्यूटिंग चर।

LuaJit का उपयोग न करना कहां बेहतर है?

मुख्य नियम: लुआ पर एक विशाल निकाय की प्रक्रिया नहीं है - यह काम नहीं करता है।

लुआ पर सामग्री के लिए हैंडलर भी काम नहीं करते हैं । कुछ if तर्क को कम करने की कोशिश करें। एक साधारण बैलेंसर काम करेगा, लेकिन लुआ पर एक साइडबार बहुत खराब काम करेगा।

साझा मेमोरी या कचरा कलेक्टर आएगा। लुआ के साथ साझा मेमोरी का उपयोग न करें - कचरा कलेक्टर जल्दी और गारंटी के साथ पूरे मस्तिष्क को उत्पादन में ले जाएगा।

बहुत सारे रख-रखाव वाले यौगिकों के साथ कोरटाइन का उपयोग न करें । लॉजिट गारबेज कलेक्टर के अंदर कोराटीन और भी अधिक कचरा उत्पन्न करता है, जो खराब है।

यदि आप पहले से ही LuaJit का उपयोग कर रहे हैं, तो याद रखें:

• स्मृति की निगरानी के बारे में;
• गारबेज कलेक्टर के काम की निगरानी और अनुकूलन पर;
• गारबेज कलेक्टर कैसे काम करता है, इसके बारे में, यदि आपने LuaJit के लिए एक जटिल आवेदन लिखा है, क्योंकि आपको कुछ नया जोड़ना है।

NJS

जब मैं एनजीआईएनएक्स कॉन्फिडेंस में था, तो उन्होंने मुझे आश्वस्त किया कि सी में कोड लिखना अच्छा नहीं होगा। मुझे लगा कि मुझे कोशिश करनी होगी, और यही मुझे मिला।

प्राधिकरण। यह काम करता है, कोड सरल है, यह गति को प्रभावित नहीं करता है - सब कुछ महान है। मेरे द्वारा शुरू किया गया मेरा छोटा प्रोटोटाइप कोड की 10 लाइनें है। लेकिन ये 10 लाइनें s3 के साथ प्राधिकरण करती हैं।

Nginx.conf के लिए कंप्यूटिंग चर। एनजेएस का उपयोग करके कई चर की गणना की जा सकती है। नेग्नेक्स के अंदर, यह शांत है। लुआ में इस तरह की सुविधा है, लेकिन एक कचरा कलेक्टर है, इसलिए यह इतना अच्छा नहीं है।

हालांकि, सब कुछ इतना अच्छा नहीं है। एनजेएस पर वास्तव में शांत करने के लिए, वह कुछ चीजों को याद करता है।

साझा की गई मेमोरी । मैंने साझा मेमोरी को पैच किया, यह मेरा अपना कांटा है, इसलिए अब यह पर्याप्त है।

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

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

सी-मॉड्यूल । मुझे NJS के विस्तार की इच्छा थी।

अंतभाषण

अपने खुद के मॉड्यूल क्यों बनाएं? सामान्य और व्यावसायिक समस्याओं को हल करने के लिए।

मुझे C में मॉड्यूल कब लागू करने की आवश्यकता है? यदि कोई अन्य विकल्प नहीं हैं। उदाहरण के लिए, एक भारी भार, सामग्री का सम्मिलन या हार्डवेयर पर बुनियादी बचत। फिर सी में इसकी गारंटी दी जानी चाहिए। ज्यादातर मामलों में, लुआ या एनजेएस उपयुक्त है। लेकिन आपको हमेशा आगे की सोचनी चाहिए।

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

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

HighLoad ++ 2019 में, वासिली सोशनिकोव ने nginx मॉड्यूल के विषय को जारी रखा और NJS के बारे में अधिक बात की , LuaJit और C के साथ तुलना को नहीं भूलना।

वेबसाइट पर रिपोर्ट की पूरी सूची देखें, और अत्यधिक लोड सिस्टम के डेवलपर्स के लिए सबसे बड़े सम्मेलन में 7 और 8 नवंबर को देखें। न्यूज़लेटर और टेलीग्राम चैनल में हमारे नए विचारों का पालन करें।