NGINX कडून आधुनिक अनुप्रयोग विकसित करण्यासाठी तत्त्वे. भाग 1

नमस्कार मित्रांनो. अभ्यासक्रम सुरू होण्याच्या अपेक्षेने PHP बॅकएंड विकसक, परंपरेने आपल्यासोबत उपयुक्त सामग्रीचे भाषांतर सामायिक करा.

सॉफ्टवेअर अधिकाधिक दैनंदिन कामे सोडवते आणि अधिकाधिक गुंतागुंतीचे होत जाते. मार्क अँड्रेसनने एकदा म्हटल्याप्रमाणे, ते जग वापरते.

परिणामी, गेल्या काही वर्षांत अॅप्लिकेशन्स विकसित आणि वितरित करण्याच्या पद्धतीत नाटकीय बदल झाला आहे. हे टेक्टोनिक स्केलचे बदल होते ज्यामुळे तत्त्वांचा संच झाला. ही तत्त्वे टीम बिल्डिंग, डिझाइनिंग, डेव्हलपिंग आणि शेवटच्या वापरकर्त्यांपर्यंत तुमचा अॅप्लिकेशन वितरीत करण्यासाठी उपयुक्त ठरली आहेत.

तत्त्वे खालीलप्रमाणे सारांशित केली जाऊ शकतात: अनुप्रयोग लहान, वेब-आधारित आणि विकासक-केंद्रित आर्किटेक्चर असावा. ही तीन तत्त्वे लक्षात घेऊन, तुम्ही एक मजबूत, एंड-टू-एंड अॅप्लिकेशन तयार करू शकता जे अंतिम वापरकर्त्यापर्यंत जलद आणि सुरक्षितपणे वितरित केले जाऊ शकते आणि ते सहजपणे वाढवता येण्याजोगे आणि विस्तारण्यायोग्य आहे.

प्रत्येक प्रस्तावित तत्त्वामध्ये अनेक पैलू आहेत ज्यावर आम्ही प्रत्येक तत्त्व अंतिम उद्दिष्टासाठी कसे योगदान देते हे दाखवण्यासाठी चर्चा करू, जे विश्वसनीय ऍप्लिकेशन्सचे जलद वितरण आहे जे देखरेख आणि वापरण्यास सोपे आहे. त्याचा अर्थ काय आहे हे स्पष्ट करण्यासाठी आम्ही त्यांच्या विरुद्ध तत्त्वांशी संबंधित तत्त्वे पाहू, म्हणा, "तुम्ही वापरत असल्याची खात्री करा लहानपणाचे तत्व».

आम्हाला आशा आहे की हा लेख तुम्हाला आधुनिक ऍप्लिकेशन्स तयार करण्यासाठी प्रस्तावित तत्त्वे वापरण्यास प्रोत्साहित करेल, जे सतत वाढणाऱ्या तंत्रज्ञान स्टॅकच्या संदर्भात डिझाइन करण्यासाठी एकसंध दृष्टीकोन प्रदान करेल.

ही तत्त्वे लागू करून, तुम्हाला सॉफ्टवेअर डेव्हलपमेंटमधील नवीनतम ट्रेंडचा लाभ घेताना दिसेल, ज्यात समाविष्ट आहे DevOps अनुप्रयोगांच्या विकासासाठी आणि वितरणासाठी, कंटेनरचा वापर (उदाहरणार्थ, गोदी कामगार) आणि कंटेनर ऑर्केस्ट्रेशन फ्रेमवर्क (उदाहरणार्थ, कुबेरनेट्स), मायक्रोसर्व्हिसेसचा वापर (मायक्रोसर्व्हिस आर्किटेक्चरसह एनजीएनएक्स и नेटवर्क कम्युनिकेशन आर्किटेक्चर मायक्रोसर्व्हिस ऍप्लिकेशन्ससाठी.

आधुनिक अनुप्रयोग म्हणजे काय?

आधुनिक अनुप्रयोग? आधुनिक स्टॅक? "आधुनिक" म्हणजे नक्की काय?

बहुतेक विकसकांना आधुनिक अनुप्रयोगात काय समाविष्ट आहे याची फक्त सामान्य कल्पना असते, म्हणून ही संकल्पना स्पष्टपणे परिभाषित करणे आवश्यक आहे.

एक आधुनिक अॅप एकाधिक क्लायंटला समर्थन देते, मग ते React JavaScript लायब्ररी वापरकर्ता इंटरफेस असो, Android किंवा iOS मोबाइल अॅप किंवा दुसर्‍या API शी कनेक्ट करणारे अॅप असो. आधुनिक ऍप्लिकेशनमध्ये ग्राहकांची अनिश्चित संख्या सूचित होते ज्यासाठी तो डेटा किंवा सेवा प्रदान करतो.

आधुनिक अनुप्रयोग विनंती केलेला डेटा आणि सेवांमध्ये प्रवेश करण्यासाठी API प्रदान करतो. API अपरिवर्तनीय आणि स्थिर असावे आणि विशिष्ट क्लायंटच्या विशिष्ट विनंतीसाठी विशेषतः लिहिलेले नसावे. API HTTP(S) वर उपलब्ध आहे आणि GUI किंवा CLI मध्ये उपलब्ध असलेल्या सर्व कार्यक्षमतेमध्ये प्रवेश प्रदान करते.

डेटा JSON सारख्या सामान्यतः स्वीकृत, इंटरऑपरेबल फॉरमॅटमध्ये उपलब्ध असणे आवश्यक आहे. एपीआय स्वच्छ, संघटित पद्धतीने वस्तू आणि सेवा उघड करते, जसे की RESTful API किंवा GraphQL एक सभ्य इंटरफेस प्रदान करते.

मॉडर्न अॅप्लिकेशन्स आधुनिक स्टॅकवर तयार केले जातात आणि मॉडर्न स्टॅक हा स्टॅक आहे जो अनुक्रमे अशा अॅप्लिकेशनला सपोर्ट करतो. हा स्टॅक विकसकाला HTTP इंटरफेस आणि स्पष्ट API एंडपॉइंट्ससह सहजपणे अनुप्रयोग तयार करण्यास अनुमती देतो. निवडलेला दृष्टिकोन तुमच्या अर्जाला JSON फॉरमॅटमध्ये डेटा सहज प्राप्त करण्यास आणि पाठविण्यास अनुमती देईल. दुसऱ्या शब्दांत, आधुनिक स्टॅक बारा-फॅक्टर ऍप्लिकेशनच्या घटकांशी संबंधित आहे सूक्ष्म सेवा.

या प्रकारच्या स्टॅकच्या लोकप्रिय आवृत्त्या यावर आधारित आहेत जावा, python ला, नोड, रुबी, कृपया PHP и Go. मायक्रोसर्व्हिस आर्किटेक्चर एनजीएनएक्स नमूद केलेल्या प्रत्येक भाषेत लागू केलेल्या आधुनिक स्टॅकचे उदाहरण दर्शवते.

कृपया लक्षात घ्या की आम्ही केवळ मायक्रोसर्व्हिस दृष्टिकोनाचा पुरस्कार करत नाही. तुमच्यापैकी बरेच जण मोनोलिथ्ससह काम करत आहेत ज्यांना विकसित करणे आवश्यक आहे, तर इतर SOA ऍप्लिकेशन्ससह काम करत आहेत जे मायक्रोसर्व्हिस ऍप्लिकेशन बनण्यासाठी विस्तारत आहेत आणि विकसित होत आहेत. तरीही इतर सर्व्हरलेस ऍप्लिकेशन्सकडे वाटचाल करत आहेत आणि काही वरील संयोजनांची अंमलबजावणी करत आहेत. लेखात वर्णन केलेली तत्त्वे या प्रत्येक प्रणालीला फक्त काही किरकोळ बदलांसह लागू होतात.

तत्त्वे

आधुनिक ऍप्लिकेशन आणि आधुनिक स्टॅक म्हणजे काय हे आम्हाला आता सामान्य समजले आहे, ही वेळ आली आहे आर्किटेक्चर आणि विकास तत्त्वांमध्ये डुबकी मारण्याची जी तुम्हाला आधुनिक ऍप्लिकेशन विकसित करण्यात, अंमलात आणण्यासाठी आणि राखण्यात चांगली मदत करेल.

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

दुसरे तत्व हे आहे की आम्ही विकासकाची उत्पादकता वाढवू शकतो आणि त्यांना ते विकसित करत असलेल्या वैशिष्ट्यांवर लक्ष केंद्रित करण्यास मदत करू शकतो, तसेच अंमलबजावणी दरम्यान त्यांना पायाभूत सुविधा आणि CI/CD चिंतांपासून मुक्त करतो. तर, थोडक्यात, आमचा दृष्टिकोन विकासकांवर लक्ष केंद्रित केले.

शेवटी, आपल्या अनुप्रयोगाबद्दल सर्व काही नेटवर्कशी कनेक्ट केलेले असणे आवश्यक आहे. गेल्या 20 वर्षांमध्ये, नेटवर्क अधिक जलद आणि अनुप्रयोग अधिक जटिल झाल्यामुळे आम्ही नेटवर्कच्या भविष्याकडे चांगली प्रगती केली आहे. आम्ही आधीच पाहिल्याप्रमाणे, एक आधुनिक अनुप्रयोग अनेक भिन्न क्लायंटद्वारे नेटवर्कवर वापरला जाणे आवश्यक आहे. आर्किटेक्चरमध्ये नेटवर्क विचार लागू करण्याचे महत्त्वपूर्ण फायदे आहेत जे चांगले आहेत लहानपणाचे तत्व आणि दृष्टिकोनाची संकल्पना, विकसक देणारं.

अनुप्रयोगाची रचना आणि अंमलबजावणी करताना तुम्ही ही तत्त्वे लक्षात ठेवल्यास, तुम्हाला तुमच्या उत्पादनाच्या विकास आणि वितरणामध्ये निर्विवाद फायदा होईल.

या तीन तत्त्वांचा अधिक तपशीलवार विचार करूया.

लहानपणाचे तत्व

मानवी मेंदूला एकाच वेळी मोठ्या प्रमाणात माहिती समजणे कठीण आहे. मानसशास्त्रामध्ये, संज्ञानात्मक भार हा शब्द मेमरीमध्ये माहिती टिकवून ठेवण्यासाठी आवश्यक असलेल्या एकूण मानसिक प्रयत्नांना सूचित करतो. डेव्हलपरवरील संज्ञानात्मक भार कमी करणे ही एक प्राथमिकता आहे कारण यामुळे त्यांना संपूर्ण ऍप्लिकेशनचे सध्याचे जटिल मॉडेल आणि त्यांच्या डोक्यात विकसित केलेली वैशिष्ट्ये ठेवण्याऐवजी समस्या सोडवण्यावर लक्ष केंद्रित करणे शक्य होते.

खालील कारणांमुळे अर्ज विघटित होतात:

• विकासकांवर कमी संज्ञानात्मक भार;
• चाचणीचे प्रवेग आणि सरलीकरण;
• अनुप्रयोगातील बदलांची जलद वितरण.

विकसकांवरील संज्ञानात्मक भार कमी करण्याचे अनेक मार्ग आहेत आणि येथेच लहानपणाचे तत्त्व लागू होते.

त्यामुळे संज्ञानात्मक भार कमी करण्याचे तीन मार्ग आहेत:

1. नवीन वैशिष्ट्य विकसित करताना त्यांना विचारात घ्यायची वेळ कमी करा - वेळ फ्रेम जितकी कमी असेल तितका संज्ञानात्मक भार कमी होईल.
2. कोडचे प्रमाण कमी करा ज्यावर एक-वेळ काम केले जाते - कमी कोड - कमी भार.
3. अर्जामध्ये वाढीव बदल करण्याची प्रक्रिया सुलभ करा.

विकास कालावधी कमी करणे

चला त्या दिवसांकडे जाऊ या जेव्हा कार्यपद्धती waterfall विकास प्रक्रियेसाठी मानक होते आणि अनुप्रयोग विकसित करण्यासाठी किंवा अद्यतनित करण्यासाठी सहा महिने ते दोन वर्षांचा कालावधी सामान्य होता. सामान्यतः, अभियंते प्रथम संबंधित दस्तऐवज जसे की उत्पादन आवश्यकता (PRD), सिस्टम संदर्भ दस्तऐवज (SRD), आर्किटेक्चर ब्लूप्रिंट वाचतात आणि या सर्व गोष्टी एकत्रितपणे एका संज्ञानात्मक मॉडेलमध्ये एकत्र करण्यास सुरवात करतात, त्यानुसार त्यांनी कोड केले. आवश्यकता आणि परिणामी, आर्किटेक्चर बदलले म्हणून, संपूर्ण टीमला संज्ञानात्मक मॉडेलच्या अद्यतनांबद्दल माहिती देण्यासाठी गंभीर प्रयत्न करावे लागले. अशा प्रकारचा दृष्टीकोन, सर्वात वाईट म्हणजे, फक्त काम अर्धांगवायू करू शकतो.

अनुप्रयोग विकास प्रक्रियेतील सर्वात मोठा बदल म्हणजे चपळ पद्धतीचा परिचय. पद्धतीच्या मुख्य वैशिष्ट्यांपैकी एक agile एक पुनरावृत्ती विकास आहे. या बदल्यात, यामुळे अभियंत्यांवरील संज्ञानात्मक भार कमी होतो. डेव्हलपमेंट टीमला एका लांब सायकलमध्ये ऍप्लिकेशनची अंमलबजावणी करण्याची आवश्यकता असण्याऐवजी, agile दृष्टीकोन आपल्याला थोड्या प्रमाणात कोडवर लक्ष केंद्रित करण्यास अनुमती देते ज्याची द्रुतपणे चाचणी आणि तैनात केली जाऊ शकते, तसेच अभिप्राय देखील प्राप्त होतो. अॅपचा संज्ञानात्मक भार सहा महिन्यांपासून दोन वर्षांच्या कालावधीत बदलला आहे ज्यामध्ये दोन आठवड्यांच्या ऍड किंवा वैशिष्ट्यातील बदलांसाठी मोठ्या प्रमाणात चष्मा आहेत आणि मोठ्या अॅपच्या अधिक अस्पष्ट समजला लक्ष्य करते.

एका मोठ्या ऍप्लिकेशनमधून दोन आठवड्यांच्या स्प्रिंटमध्ये पूर्ण करता येणार्‍या विशिष्ट छोट्या वैशिष्ट्यांवर लक्ष केंद्रित करणे, पुढील स्प्रिंटच्या आधी एकापेक्षा जास्त वैशिष्ट्ये लक्षात न घेता, हा एक महत्त्वपूर्ण बदल आहे. यामुळे आम्हाला सतत चढ-उतार होत असलेले संज्ञानात्मक भार कमी करताना विकास उत्पादकता वाढवता आली.

पद्धतीत agile अंतिम ऍप्लिकेशन मूळ संकल्पनेची थोडी सुधारित आवृत्ती असणे अपेक्षित आहे, त्यामुळे विकासाचा शेवटचा मुद्दा अस्पष्ट असणे आवश्यक आहे. केवळ प्रत्येक विशिष्ट स्प्रिंटचे परिणाम स्पष्ट आणि अचूक असू शकतात.

लहान कोडबेस

संज्ञानात्मक भार कमी करण्याची पुढील पायरी म्हणजे कोडबेस कमी करणे. नियमानुसार, आधुनिक ऍप्लिकेशन्स प्रचंड आहेत - एक मजबूत, एंटरप्राइझ ऍप्लिकेशन हजारो फायली आणि कोडच्या शेकडो हजारो ओळींचा समावेश असू शकतो. फायली कशा प्रकारे आयोजित केल्या जातात यावर अवलंबून, कोड आणि फाइल्समधील दुवे आणि अवलंबित्व स्पष्ट असू शकतात किंवा त्याउलट. वापरलेल्या लायब्ररींवर आणि डीबगिंग साधने लायब्ररी/पॅकेज/मॉड्यूल आणि सानुकूल कोडमध्ये किती फरक करतात यावर अवलंबून, डीबगिंग कोडची अंमलबजावणी देखील समस्याप्रधान असू शकते.

अॅप्लिकेशनच्या कोडचे एक कार्यरत मानसिक मॉडेल तयार करण्यासाठी प्रभावी वेळ लागू शकतो आणि विकासकावर पुन्हा एकदा मोठा संज्ञानात्मक भार टाकू शकतो. हे विशेषत: मोनोलिथिक कोड बेससाठी खरे आहे, जेथे कोड मोठ्या प्रमाणात आहे, त्यातील कार्यात्मक घटकांमधील परस्परसंवाद स्पष्टपणे परिभाषित केलेला नाही आणि लक्ष वेधून घेतलेल्या वस्तूंचे पृथक्करण अनेकदा अस्पष्ट होते कारण कार्यात्मक सीमांचा आदर केला जात नाही.

अभियंत्यांवरील संज्ञानात्मक भार कमी करण्याचा एक प्रभावी मार्ग म्हणजे मायक्रोसर्व्हिस आर्किटेक्चरकडे जाणे. मायक्रोसर्व्हिस दृष्टिकोनामध्ये, प्रत्येक सेवा वैशिष्ट्यांच्या एका संचावर लक्ष केंद्रित करते; सेवेचा अर्थ सहसा परिभाषित आणि समजण्यासारखा असतो. सेवेच्या सीमा देखील स्पष्ट आहेत - लक्षात ठेवा की सेवेशी संप्रेषण API द्वारे केले जाते, त्यामुळे एका सेवेद्वारे व्युत्पन्न केलेला डेटा सहजपणे दुसर्‍या सेवेकडे जाऊ शकतो.

इतर सेवांसह परस्परसंवाद सामान्यतः काही वापरकर्ता सेवा आणि काही प्रदाता सेवांपुरते मर्यादित असते जे साधे आणि स्वच्छ API कॉल वापरतात, जसे की REST वापरणे. याचा अर्थ अभियंतावरील संज्ञानात्मक भार गंभीरपणे कमी झाला आहे. सेवा परस्परसंवाद मॉडेल समजून घेणे आणि अनेक सेवांमध्ये व्यवहार यासारख्या गोष्टी कशा होतात हे समजून घेणे हे सर्वात मोठे आव्हान आहे. परिणामी, मायक्रोसर्व्हिसेसचा वापर कोडचे प्रमाण कमी करून, स्पष्ट सेवा सीमा परिभाषित करून आणि वापरकर्ते आणि प्रदाते यांच्यातील संबंधांची समज प्रदान करून संज्ञानात्मक भार कमी करतो.

लहान वाढीव बदल

तत्त्वाचा शेवटचा घटक लहानपणा बदल व्यवस्थापन आहे. विकासकांसाठी कोड बेस (कदाचित त्यांचा स्वतःचा, जुना कोड) पाहणे आणि "हे बकवास आहे, आम्हाला ते सर्व पुन्हा लिहिणे आवश्यक आहे" असे म्हणणे हा एक विशिष्ट मोह आहे. कधी कधी हा योग्य निर्णय असतो, तर कधी नाही. हे जागतिक मॉडेल बदलाचा भार विकास संघावर टाकते, ज्यामुळे मोठ्या प्रमाणात संज्ञानात्मक भार येतो. अभियंत्यांनी स्प्रिंट दरम्यान ते जे बदल करू शकतात त्यावर लक्ष केंद्रित करणे चांगले आहे, जेणेकरून ते आवश्यक कार्यक्षमता वेळेवर आणू शकतील, जरी हळूहळू. अंतिम उत्पादन पूर्व-नियोजित उत्पादनासारखे असले पाहिजे, परंतु क्लायंटच्या गरजेनुसार काही बदल आणि चाचणीसह.

कोडच्या मोठ्या भागांचे पुनर्लेखन करताना, काहीवेळा बदल पटकन वितरित करणे शक्य नसते कारण इतर सिस्टम अवलंबित्व कार्यात येतात. बदलांचा प्रवाह नियंत्रित करण्यासाठी, तुम्ही वैशिष्ट्य लपविण्याचा वापर करू शकता. तत्वतः, याचा अर्थ असा आहे की कार्यक्षमता उत्पादनात आहे, परंतु ती पर्यावरणीय व्हेरिएबल सेटिंग्ज (env-var) किंवा इतर काही कॉन्फिगरेशन यंत्रणा वापरून उपलब्ध नाही. जर कोडने सर्व गुणवत्ता नियंत्रण प्रक्रिया पार केल्या असतील, तर ते सुप्त अवस्थेत उत्पादनात समाप्त होऊ शकते. तथापि, ही रणनीती केवळ तेव्हाच कार्य करते जेव्हा वैशिष्ट्य अखेरीस सक्षम केले असेल. अन्यथा, ते केवळ कोडमध्ये गोंधळ घालेल आणि एक संज्ञानात्मक भार जोडेल ज्याचा सामना विकासकाला उत्पादक होण्यासाठी करावा लागेल. बदल व्यवस्थापन आणि स्वतःमधील वाढीव बदल विकासकांच्या संज्ञानात्मक वर्कलोडला आटोपशीर ठेवण्यास मदत करतात.

अतिरिक्त कार्यक्षमतेची साधी ओळख करूनही अभियंत्यांना अनेक अडचणींवर मात करावी लागते. व्यवस्थापनाच्या बाजूने, संघावरील अनावश्यक ओझे कमी करणे शहाणपणाचे ठरेल जेणेकरून ते मुख्य कार्यात्मक घटकांवर लक्ष केंद्रित करू शकेल. तुमच्या विकास कार्यसंघाला मदत करण्यासाठी तुम्ही तीन गोष्टी करू शकता:

1. पद्धत वापरा agileकालमर्यादा मर्यादित करण्यासाठी ज्यामध्ये संघाने मुख्य वैशिष्ट्यांवर लक्ष केंद्रित केले पाहिजे.
2. तुमचा अर्ज एकाधिक मायक्रोसर्व्हिसेस म्हणून लागू करा. हे अंमलात आणल्या जाऊ शकणार्‍या वैशिष्ट्यांची संख्या मर्यादित करेल आणि कामावर संज्ञानात्मक भार ठेवणार्‍या सीमांना बळकट करेल.
3. मोठ्या आणि अनाठायी बदलांना प्राधान्य द्या, कोडचे छोटे तुकडे बदला. बदल अंमलात आणण्यासाठी वैशिष्ट्य लपविण्याचा वापर करा, जरी ते जोडल्यानंतर लगेच दिसणार नाहीत.

तुम्ही तुमच्या कामात लहानपणाचे तत्त्व लागू केल्यास, तुमचा कार्यसंघ अधिक आनंदी होईल, आवश्यक वैशिष्ट्ये लागू करण्यावर अधिक लक्ष केंद्रित करेल आणि गुणात्मक बदल जलदपणे घडवून आणण्याची अधिक शक्यता आहे. परंतु याचा अर्थ असा नाही की काम अधिक क्लिष्ट होऊ शकत नाही, काहीवेळा, त्याउलट, नवीन कार्यक्षमतेच्या परिचयासाठी अनेक सेवांमध्ये बदल करणे आवश्यक आहे आणि ही प्रक्रिया मोनोलिथिक आर्किटेक्चरमधील समानतेपेक्षा अधिक कठीण असू शकते. कोणत्याही परिस्थितीत, लहानपणाचा दृष्टीकोन घेण्याचे फायदे फायदेशीर आहेत.

पहिल्या भागाचा शेवट.

लवकरच आम्ही अनुवादाचा दुसरा भाग प्रकाशित करू, आणि आता आम्ही तुमच्या टिप्पण्यांची वाट पाहत आहोत आणि तुम्हाला आमंत्रित करतो खुला दिवस, जे आज 20.00 वाजता होईल.

स्त्रोत: www.habr.com