NGINX से आधुनिक अनुप्रयोगों के विकास के सिद्धांत। भाग 1

नमस्कार दोस्तों। "बैकएंड PHP डेवलपर" पाठ्यक्रम के शुभारंभ की प्रत्याशा में, हम परंपरागत रूप से आपके साथ उपयोगी सामग्री का अनुवाद साझा करते हैं।

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



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

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



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

हमें उम्मीद है कि यह लेख आपको आधुनिक अनुप्रयोगों के निर्माण के लिए प्रस्तावित सिद्धांतों का उपयोग करने के लिए प्रोत्साहित करेगा जो कि एक बढ़ती प्रौद्योगिकी स्टैक के संदर्भ में डिजाइन के लिए एक एकीकृत दृष्टिकोण प्रदान करेंगे।

इन सिद्धांतों को लागू करने से, आप अपने आप को नवीनतम सॉफ़्टवेयर डेवलपमेंट ट्रेंड्स का लाभ उठा पाएंगे, जिसमें DevOps के लिए विकासशील और अनुप्रयोगों को वितरित करना, कंटेनर ( डॉकर की तरह) और कंटेनर ऑर्केस्ट्रेशन के लिए चौखटे (जैसे कुबेरनेट्स ) का उपयोग करना शामिल है, microservices का उपयोग करके ( NGINX माइक्रोसैटे आर्किटेक्चर सहित) और microservice अनुप्रयोगों के लिए नेटवर्क संचार वास्तुकला ।

आधुनिक अनुप्रयोग क्या है?

आधुनिक अनुप्रयोग? आधुनिक स्टैक? वास्तव में "आधुनिक" का क्या अर्थ है?

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

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

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

डेटा को सामान्य रूप से स्वीकार्य, संगत प्रारूप में सुलभ होना चाहिए, जैसे कि JSON। एपीआई वस्तुओं और सेवाओं को एक स्पष्ट, संगठित तरीके से प्रदान करता है, उदाहरण के लिए, Restful API या GraphQL एक सभ्य इंटरफ़ेस प्रदान करता है।

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

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

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

सिद्धांतों

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

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

दूसरा सिद्धांत यह है कि हम डेवलपर्स के उत्पादकता में वृद्धि कर सकते हैं, जो उन्हें विकसित होने वाले कार्यों पर ध्यान केंद्रित करने में मदद करते हैं, जबकि उन्हें बुनियादी ढांचे और CI / CD के बारे में चिंता से मुक्त करते हैं। इसलिए, संक्षेप में, हमारा दृष्टिकोण डेवलपर्स पर केंद्रित है ।

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

यदि अनुप्रयोग के विकास और कार्यान्वयन के दौरान आप इन सिद्धांतों के प्रति सचेत रहेंगे, तो आपको अपने उत्पाद के विकास और वितरण में एक निर्विवाद लाभ होगा।

आइए इन तीन सिद्धांतों को अधिक विस्तार से देखें।

छोटेपन का सिद्धांत

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



निम्नलिखित कारणों से आवेदन विघटित हो जाते हैं:

• डेवलपर्स पर संज्ञानात्मक भार में कमी;
• परीक्षण को गति दें और सरल करें;
• आवेदन में परिवर्तन का तेजी से वितरण।

डेवलपर्स पर संज्ञानात्मक बोझ को कम करने के कई तरीके हैं, और यह वह जगह है जहां लघुता का सिद्धांत खेल में आता है।

तो, संज्ञानात्मक भार को कम करने के तीन तरीके हैं:

1. किसी नए फ़ंक्शन को विकसित करते समय उन्हें उस समय सीमा को ध्यान में रखना चाहिए - जब समय सीमा कम होती है, तो संज्ञानात्मक भार कम होता है।
2. उस कोड की मात्रा कम करें जिस पर एक बार का काम किया जाता है - कम कोड - कम लोड।
3. आवेदन में वृद्धिशील परिवर्तन करने की प्रक्रिया को सरल बनाएं।

विकास की समय सीमा कम करें

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

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

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

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

छोटे कोडबेस

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

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

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

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

छोटे वृद्धिशील परिवर्तन

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

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

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

1. उस समय सीमा को सीमित करने के लिए agile कार्यप्रणाली का उपयोग करें जिसके भीतर एक टीम को प्रमुख कार्यों पर ध्यान केंद्रित करना चाहिए।
2. अपने आवेदन को कई माइक्रोसॉफ़्ट के रूप में लागू करें। यह कार्यान्वित होने वाली सुविधाओं की संख्या को सीमित करेगा और काम के दौरान संज्ञानात्मक भार रखने वाली सीमाओं को मजबूत करेगा।
3. बड़े और भारी परिवर्तन को रोकें, कोड के छोटे टुकड़ों को बदलें। परिवर्तनों को लागू करने के लिए छिपाने की सुविधा का उपयोग करें, भले ही वे जोड़ने के तुरंत बाद दिखाई न दें।

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

पहले भाग का अंत।

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