जब HTTP मानक पर्याप्त नहीं है। अंतरिक्ष यात्री प्रतिबद्ध है

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

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

• वेबदव संसाधनों तक पहुंचने का एक विस्तार है। मानक विधियों के अलावा, HTTP को अतिरिक्त विधियों जैसे LOCK, PROPPATCH, आदि के लिए समर्थन की आवश्यकता होती है।
• कैलडव कैलेंडर प्रकार की घटनाओं के साथ काम करने के लिए एक वेबदाव एक्सटेंशन है। उच्च स्तर की संभावना वाला यह प्रोटोकॉल आपके स्मार्टफ़ोन के अनुप्रयोगों में है: कैलेंडर, अपॉइंटमेंट आदि को सिंक्रनाइज़ करने के लिए।

और सूची यही तक सीमित नहीं है। यदि आप HTTP विधियों की रजिस्ट्री को देखते हैं, तो आप देखेंगे कि केवल RFC मानकों द्वारा वर्णित HTTP विधियाँ वर्तमान में 39 हैं। और कितने अधिक मामले HTTP पर स्व-लिखित प्रोटोकॉल है। तो गैर-मानक HTTP विधियों के लिए समर्थन काफी सामान्य है। यह अक्सर ऐसा भी होता है कि आपके द्वारा उपयोग किया जाने वाला ढांचा ऐसे तरीकों का समर्थन नहीं करता है। यहां ExpressJS के लिए स्टैक ओवरफ्लो पर एक चर्चा है। और यहाँ बवंडर के लिए टिड्डो पर पुल अनुरोध है। खैर, चूंकि माइक्रोफ़ोन अक्सर स्प्रिंग के हल्के विकल्प के रूप में तैनात होता है - यह स्प्रिंग के लिए भी यही समस्या है।

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

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

समाधान एक: माथे

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

http { upstream other_PROPPATCH { server ...; } upstream other_REPORT { server ...; } server { location /service { proxy_method POST; proxy_pass http://other_$request_method; } } } 

क्या कहना है? हम गैर-मानक तरीकों के लिए nginx को हमारी ज़रूरत की प्रॉक्सी तक पहुंचने के लिए बाध्य कर सकते हैं, जबकि nginx की क्षमता का उपयोग विधि को बदलने के लिए करते हैं: अर्थात, हम POST विधि के माध्यम से एक्सेस करेंगे, और Micronaut इसे संभाल सकते हैं।

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

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

दोनों विकल्प बहुत सुंदर नहीं हैं, इसलिए यह विचार आया: क्यों न सही उद्देश्य के लिए माइक्रोनॉट को ठीक किया जाए, सभी के लिए इतना निश्चित है कि इस तरह के संपादन न केवल हमारे लिए उपयोगी होंगे। यही है, मैं कुछ इस तरह चाहता था:

 @CustomMethod("PROPFIND") public String process( // Provide here HttpRequest or something else, as standard micronaut methods ) { } 

और मैंने इस कार्य को सहर्ष किया, लेकिन अंत में क्या हुआ?

समाधान दो: चलो सब कुछ फिर से लिखना!

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

यहां सबसे मुश्किल काम DefaultUriRouter के साथ था, क्योंकि यह माना जाता था कि सेट को ठीक किया गया था और संभव तरीकों के लिए पथ सूचियों की एक सरणी बनाई गई थी। इसे नए कार्यान्वयन के लिए छोड़ना पड़ा। लेकिन सामान्य तौर पर, सब कुछ काफी सरल निकला। ध्यान दें कि आपको २४० लाइनों को जोड़ना था और ११६ को हटाना था।

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

समाधान तीन: विकसित रूप से कार्य करें

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

मूल संपादन इस तथ्य पर आधारित थे कि HttpRequest इंटरफ़ेस में एक गेटमेथोड विधि थी, जिसका उपयोग फ़िल्टरिंग के लिए किया गया था। वह लौट आया, जैसा कि आप अनुमान लगा सकते हैं, एनम। इसलिए, डिफ़ॉल्ट विधि getHttpMethodName इंटरफ़ेस में जोड़ा गया था, जो डिफ़ॉल्ट रूप से एनम मान का नाम देता है। फिर उन्होंने पाया कि पथ मिलान में मूल विधि का उपयोग कहां किया गया था, और वहां इसे नई विधि के लिए कॉल द्वारा प्रतिस्थापित किया गया था। और फिर, नेट्टी सर्वर के लिए इंटरफ़ेस के कार्यान्वयन में, HTTP विधि के वास्तविक मूल्य का उपयोग करने के लिए इंटरफ़ेस विधि को फिर से परिभाषित किया गया था।

इसमें एक ऐसी गड़बड़ी थी जिसे चर्चा में देखा जा सकता है, और यह माइक्रोनॉट के घोषित ग्राहकों की चिंता करता है। वे एन्टी वैल्यू के नाम का उपयोग नेटी के लिए HttpMethod वर्ग के एक उदाहरण के लिए करते हैं। यदि आप इस वर्ग में मान विधि के लिए प्रलेखन को देखते हैं, तो आप देखेंगे कि कैश्ड मान मानक विधियों के लिए वापस आ जाएगा, और गैर-मानक तरीकों के लिए, कक्षा का एक नया उदाहरण हर बार वापस किया जाएगा। यही है, अगर आपके पास हाईलोड है और आप एक लाख बार गैर-मानक HTTP विधि के साथ सर्वर की ओर रुख करते हैं, तो आप एक साथ एक मिलियन ऑब्जेक्ट बनाएंगे। बेशक, आधुनिक जीसी को इसका सामना करना चाहिए, लेकिन फिर भी मैं उस तरह से अतिरिक्त ऑब्जेक्ट नहीं बनाना चाहता। तब यह विचार कैशिंग के लिए ConcurrentHashMap.computeIfAbsent का उपयोग करने के लिए आया था, लेकिन यहां यह इतना आसान नहीं है: समस्या जावा 8 के दोष में है, जिसके कारण रिकॉर्डिंग करते समय भी मामला अवरुद्ध हो जाएगा। परिणामस्वरूप, हमने एक मध्यवर्ती निर्णय लिया:

• मानक तरीकों के लिए, हम उदाहरण कैशिंग का उपयोग करते हैं, जो कि नेट्टी प्रदान करता है (वास्तव में, जैसा कि पहले था)।
• गैर-मानक तरीकों के लिए, नए उदाहरण बनने दें। जो लोग गैर-मानक तरीके चुनते हैं, उन्हें यह सुनिश्चित करना चाहिए कि कचरा कलेक्टर वस्तुओं के निर्माण को पचाने में सक्षम हो सकते हैं (हम, उदाहरण के लिए, शेनानडो का उपयोग करें)।

निष्कर्ष

अंत में क्या कहा जा सकता है?

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

पुनश्च

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