परिचय आधुनिक अर्थव्यवस्था में, सॉफ्टवेयर का निर्माण एक संपूर्ण उद्योग है। एक ओर, यह व्यवसायों को सभी प्रक्रियाओं को स्वचालित और डिजिटल बनाने में मदद करता है, और दूसरी ओर, यह लाभ कमाता है और आभासी संपत्ति बनाता है। वर्तमान में, आर एंड डी अधिक जटिल हो गया है, प्रोग्रामर की संख्या लगातार बढ़ रही है, और आईटी कार्य अधिक जटिल होते जा रहे हैं। इन कारणों से नई सॉफ्टवेयर विकास पद्धतियों और वास्तुकला के प्रकारों का उदय हुआ है। आधुनिक वेब अनुप्रयोग बहु-कार्यात्मक हैं और डिजिटल परिवर्तन से सॉफ़्टवेयर की आवश्यकताएँ बढ़ जाती हैं। आवेदन होना चाहिए: आसानी से स्केलेबल, लचीला और क्रॉस-प्लेटफ़ॉर्म, और उपयोगकर्ता कार्यों के लिए परिवर्तनशील। कार्य प्रबंधक इन आवश्यकताओं को ऐसे सॉफ़्टवेयर के विकास के चरण में निर्धारित करते हैं। सबसे पहले, आधुनिक व्यवसाय के लिए सॉफ्टवेयर बनाने के लिए आपको सॉफ्टवेयर विकास प्रक्रिया का गंभीरता से अध्ययन करना चाहिए और सही वास्तुकला का चयन करना चाहिए। सॉफ्टवेयर विकास में वास्तुकला का विकल्प एक नियम के रूप में, पहले सभी अनुप्रयोगों को एक अखंड वास्तुकला के आधार पर विकसित किया गया था। आइए एक नजर डालते हैं कि मोनोलिथ एप्लिकेशन क्या है। मोनोलिथिक ऐप्स समग्र रूप से विकसित किए जाते हैं। अनुरोधों को संसाधित करने का तर्क एक ही प्रक्रिया के अंदर रखा गया है। मोनोलिथ वेब ऐप्स को मॉड्यूल और ब्लॉक के रूप में संरचित किया जा सकता है। उपयोग की जाने वाली प्रोग्रामिंग भाषा के आधार पर अलग-अलग वर्गों, कार्यों आदि का उपयोग किया जाता है। लेकिन मॉड्यूल के बीच संबंध बहुत मजबूत हैं। यह निम्नलिखित निष्कर्ष की ओर जाता है: किसी भी मॉड्यूल को बदलने से पूरे एप्लिकेशन के कामकाज पर बहुत प्रभाव पड़ेगा। उदाहरण के लिए, हम एलएमएस (लर्निंग मैनेजमेंट सिस्टम) के लिए एक विशिष्ट वेब ऐप पर विचार कर सकते हैं। इस सॉफ़्टवेयर में तीन-स्तरीय आर्किटेक्चर है, जिसमें शामिल हैं: प्रयोक्ता इंटरफ़ेस; सॉफ़्टवेयर व्यवसाय तर्क और डेटा एक्सेस के लिए सर्वर-साइड घटक; डेटाबेस। ऐसे एप्लिकेशन के व्यावसायिक कार्य बहुत भिन्न होते हैं। इसमें निम्नलिखित ब्लॉक शामिल हैं: "पाठ्यक्रम और प्रशिक्षण", "पाठ्यक्रम सूची", "कंपनी की संगठनात्मक संरचना", "घटनाओं का कैलेंडर", "रिपोर्ट", "संदेश", "समाचार", आदि। हालांकि, वे सभी एक एकल अखंड ब्लॉक में संयुक्त हैं और एक सर्वर पर स्थित हैं। इस तरह के एप्लिकेशन को स्केल करना और बदलना काफी मुश्किल है। आइए अखंड वास्तुकला के नुकसान पर प्रकाश डालें: यहां तक कि वेब ऐप में एक छोटा सा बदलाव पूरे सॉफ्टवेयर के एक नए संस्करण की असेंबली और तैनाती की ओर जाता है। आप केवल पूरे एप्लिकेशन को स्केल कर सकते हैं। एक अलग ब्लॉक को स्केल करना असंभव है। यदि कोई एप्लिकेशन मॉड्यूल विफल हो जाता है, तो परिणामस्वरूप पूरे एप्लिकेशन का संचालन बाधित हो सकता है। विकास उपकरण हमेशा चयनित तकनीकी स्टैक तक ही सीमित होते हैं। योग्य डेवलपर्स की एक बड़ी टीम के प्रबंधन में असुविधा। प्रत्येक डेवलपर को ऐप की सभी कार्यक्षमता को समझना चाहिए, न कि केवल उसके मॉड्यूल को। कोई भी अद्यतन सॉफ़्टवेयर की संपूर्ण कार्यक्षमता को प्रभावित करता है। यह अपडेट के बाद एप्लिकेशन के विफल होने का खतरा पैदा करता है। इसलिए, अद्यतनों के केवल दुर्लभ रिलीज़ किए जाते हैं। डेटाबेस में कोई भी परिवर्तन पूरे एप्लिकेशन के कामकाज को प्रभावित कर सकता है और कोड में बदलाव की आवश्यकता होती है। यदि यह एक सामान्य उपयोगकर्ता को कुछ व्यक्तिगत कौशल सिखाने के लिए एक छोटा सा मुफ्त कार्यक्रम है, और यहां तक कि शायद ही कभी अपडेट किया जाता है, तो इस तरह के विकास के लिए एक मोनोलिथिक वास्तुकला काफी उपयुक्त है। अगर हम कॉर्पोरेट सॉफ्टवेयर (उदाहरण के लिए, एलएमएस) के बारे में बात कर रहे हैं, और यहां तक कि अक्सर अपडेट किए जाते हैं, तो एक माइक्रोसर्विस आर्किटेक्चर चुनना आवश्यक है। सॉफ्टवेयर विकास के लिए इष्टतम दृष्टिकोण है। एक माइक्रोसर्विस आर्किटेक्चर में, वेब एप्लिकेशन को विशिष्ट इंटरफेस के साथ छोटे और स्वायत्त घटकों (माइक्रोसर्विसेज) में विभाजित किया जाता है। इस तरह के आर्किटेक्चर ने क्लाउड कंप्यूटिंग के क्षेत्र में अपना आवेदन पाया है। माइक्रोसर्विस आर्किटेक्चर माइक्रोसर्विस और मोनोलिथिक आर्किटेक्चर में क्या अंतर है? माइक्रोसर्विस आर्किटेक्चर में, वेब ऐप को छोटे और खराब इंटरकनेक्टेड घटकों के एक सेट के रूप में विकसित किया जाता है, जिसे माइक्रोसर्विसेज कहा जाता है। माइक्रोसर्विसेज एक दूसरे से लगभग स्वतंत्र रूप से विकसित, तैनात और रखरखाव किए जाते हैं। उदाहरण के लिए, एलएमएस के लिए एक वेब एप्लिकेशन। प्रत्येक माइक्रोसर्विस का उद्देश्य केवल अपने विशिष्ट व्यावसायिक कार्य को हल करना है, इसका डेटाबेस है, और एपीआई के माध्यम से अन्य माइक्रोसर्विसेज के साथ संपर्क है। इस प्रकार, एलएमएस वेब ऐप के लिए निम्नलिखित माइक्रोसर्विसेज विकसित करना आवश्यक होगा: "पाठ्यक्रम और प्रशिक्षण", "पाठ्यक्रम कैटलॉग", "कंपनी की संगठनात्मक संरचना", "घटनाओं का कैलेंडर", "रिपोर्ट", "संदेश", "समाचार", आदि। लेकिन यह ध्यान दिया जाना चाहिए कि एक अन्य प्रकार की वास्तुकला है - एक सेवा-उन्मुख वास्तुकला (SOA)। कभी-कभी यह माइक्रोसर्विस के साथ भ्रमित होता है। ऐसा लगता है कि माइक्रोसर्विस आर्किटेक्चर और SOA के बीच का अंतर इतना स्पष्ट नहीं है। लेकिन माइक्रोसर्विसेज और SOA के बीच अंतर हैं। यह एंटरप्राइज़ सर्विस बस (ESB) की भूमिका से संबंधित है। SOA एक कंपनी-व्यापी वास्तुकला है। इसका लक्ष्य कंपनी की वेब सेवाओं की सहभागिता और एकीकरण का मानकीकरण करना है। माइक्रोसर्विस आर्किटेक्चर का उद्देश्य एक विशिष्ट एप्लिकेशन विकसित करना है। निम्नलिखित टेम्पलेट SOA से संबंधित हैं: CORBA, वेब सेवाएँ, संदेश कतार, ESB, आदि। नीचे हम वेब एप्लिकेशन विकसित करने के लिए माइक्रोसर्विसेज के फायदों के बारे में विस्तार से बताएंगे। माइक्रोसर्विस आर्किटेक्चर के मुख्य लाभ हम एक अखंड वास्तुकला की तुलना में माइक्रोसर्विसेज के लाभों का मूल्यांकन करेंगे। आवेदन परिनियोजन में सरलता और स्वतंत्रता। माइक्रोसर्विसेज के मामले में, आप केवल एक एप्लिकेशन मॉड्यूल को तैनात कर सकते हैं। उदाहरण के लिए, एलएमएस के मामले में, आप केवल एक मॉड्यूल ("इवेंट कैलेंडर") को तैनात कर सकते हैं, बाकी एप्लिकेशन घटकों को अपरिवर्तित छोड़कर। यदि आपको "रिपोर्ट" मॉड्यूल में कोड को फिर से लिखने की आवश्यकता है, तो बहुत अधिक अनुमति प्राप्त करने की कोई आवश्यकता नहीं है। यह घटक ("रिपोर्ट") एक अलग और स्वतंत्र माइक्रोसर्विस है। मापनीयता: सटीकता और दक्षता। सबसे पहले, यह निर्धारित करने की आवश्यकता है कि किन माइक्रोसर्विसेज को लगातार मापनीयता की आवश्यकता होगी, और कौन सी नहीं। मॉड्यूल जिन्हें अक्सर स्केल करने की आवश्यकता नहीं होती है, उन्हें कमजोर सर्वर पर रखा जा सकता है, और अक्सर स्केलेबल को अन्य सभी सॉफ़्टवेयर से अलग से स्केल किया जा सकता है। अनुप्रयोग लचीलापन में वृद्धि। मॉड्यूल के बीच तर्कसंगत ऐप डिज़ाइन और स्वतंत्र कनेक्शन बनाने से निम्नलिखित लाभ मिलते हैं: मॉड्यूल में से किसी एक की विफलता पूरे सॉफ़्टवेयर की विफलता का कारण नहीं बनती है। उदाहरण के लिए, यदि "संदेश" मॉड्यूल विफल हो गया है, तो उपयोगकर्ता को इस ब्लॉक की अस्थायी अनुपलब्धता के बारे में एक सूचना प्राप्त होगी। अन्य सभी एप्लिकेशन ब्लॉक काम करेंगे। टेक स्टैक चयन। प्रत्येक माइक्रोसर्विस को विकसित करके, आप सबसे उपयुक्त तकनीकी स्टैक चुन सकते हैं। टीमों के प्रबंधन में लचीलापन। उदाहरण के लिए, टीम नंबर 1 "कोर्स कैटलॉग", टीम नंबर 2 - "घटनाओं का कैलेंडर", और टीम नंबर 3 - "समाचार" सेवा विकसित करती है। इसलिए नए विशेषज्ञ के लिए तेजी से काम करना आसान होता है। लंबे समय तक पूरे एप्लिकेशन की कार्यक्षमता का अध्ययन करना आवश्यक नहीं है, यह एक विशिष्ट माइक्रोसर्विस के लिए तकनीकी स्टैक सीखने के लिए पर्याप्त है। कार्यक्षमता का पुन: उपयोग करने की क्षमता (विभिन्न उद्देश्यों के लिए और विभिन्न तरीकों से)। अनावश्यक सेवाओं को बदलना या हटाना जल्दी और आसानी से हल हो जाता है। उदाहरण के लिए, यदि कोई विशिष्ट ग्राहक एलएमएस में "समाचार" ब्लॉक का उपयोग नहीं करेगा, तो इस मॉड्यूल को सभी सॉफ़्टवेयर में वैश्विक परिवर्तनों के बिना आसानी से हटाया जा सकता है। प्रत्येक माइक्रोसर्विस अपने डेटाबेस का उपयोग करता है। यह तथ्य डेटा मॉडल की स्वतंत्रता की ओर जाता है। उदाहरण के लिए, यदि किसी प्रोग्रामर ने एक विशेष सेवा में डेटा मॉडल बदल दिया है, तो यह अन्य सेवाओं के कामकाज को प्रभावित नहीं करेगा। जैसा कि हम देख सकते हैं, माइक्रोसर्विस आर्किटेक्चर के महत्वपूर्ण फायदे हैं और डेवलपर्स को अधिक से अधिक आकर्षित करते हैं। हालांकि, सॉफ्टवेयर विकास के लिए एक आर्किटेक्चर चुनने से पहले, उसे माइक्रोसर्विसेज के नुकसान को देखना चाहिए। हम नीचे सूचीबद्ध करेंगे। माइक्रोसर्विसेज के नुकसान माइक्रोसर्विसेज की प्रणाली वितरित की जाती है। एक ओर, यह सॉफ्टवेयर के काम में एक फायदा है। दूसरी ओर, यदि बहुत अधिक माइक्रोसर्विसेज हैं और उनमें से प्रत्येक अन्य सेवाओं के लिए अनुरोध करता है, तो परिणामी प्रतिक्रिया समय बढ़ जाएगा, और "विफलता के बिंदु" दिखाई देंगे। इस समस्या को हल करने के दो तरीके हैं: कॉल विवरण बदलना, जिससे उनकी संख्या में कमी आ सकती है; अतुल्यकालिक की शुरूआत, कॉल समानांतर में की जाती है, परिणामस्वरूप, यह इस तथ्य की ओर जाता है कि अंतिम प्रतिक्रिया समय सभी का सबसे धीमा समय है, न कि सभी देरी का कुल समय। विकास प्रक्रिया की निरंतर जटिलता, जो प्रोग्रामर की योग्यता के लिए बढ़ती आवश्यकताओं की ओर ले जाती है। एक माइक्रोसर्विस आर्किटेक्चर में, एकीकरण प्रक्रियाओं और निरंतर वितरण प्रक्रियाओं की भूमिका महान है। और इसीलिए परीक्षण और सेवाओं को स्वचालित किए बिना बहुत सारी प्रक्रियाओं को संभालना काफी मुश्किल है। इन कारकों के लिए कंपनी में DevOps के कार्यान्वयन और सिस्टम इंजीनियरों, परीक्षकों, तकनीकी सहायता आदि के साथ डेवलपर्स के निकट सहयोग की आवश्यकता होती है। माइक्रोसर्विस आर्किटेक्चर में विकेंद्रीकरण माइक्रोसर्विसेज की स्थिरता के साथ समस्याएं पैदा करता है। उदाहरण के लिए, एक मोनोलिथिक एप्लिकेशन में, एक लेनदेन में कई बदलाव किए जा सकते हैं, लेकिन डेटा स्थिरता बनाए रखते हुए विफलता होने पर वापस रोल करना भी संभव है। माइक्रोसर्विसेज का उपयोग करते समय, निम्न स्थिति संभव है: सेवाओं में से एक के खराब होने की स्थिति में, अन्य माइक्रोसर्विस प्रत्युत्तर देना बंद कर देती है। इस मामले में, यह डेवलपर की प्राथमिकताओं की बात है: आप घटकों की उपलब्धता को प्राथमिकता दे सकते हैं (एक सेवा की विफलता के मामले में, अन्य काम करना जारी रखेंगे)। सामान्य तौर पर, डेवलपर्स को सेवाओं की निरंतरता और उनकी उपलब्धता के बीच संतुलन खोजना चाहिए, और यह बहुत सावधानी से किया जाना चाहिए। निष्कर्ष वेब एप्लिकेशन विकसित करने के लिए एक माइक्रोसर्विस आर्किटेक्चर चुनने से पहले, डेवलपर्स को इसके फायदे और नुकसान दोनों का मूल्यांकन करना चाहिए। आखिरकार, आर्किटेक्चर का गलत चुनाव भविष्य में सॉफ्टवेयर के प्रदर्शन और कार्यक्षमता को प्रभावित कर सकता है। यदि माइक्रोसर्विस आर्किटेक्चर का गलत तरीके से उपयोग किया जाता है, तो डेवलपर्स को बड़ी समस्याएं हो सकती हैं जो माइक्रोसर्विसेज के सभी लाभों को नकार देती हैं। लेख के अगले भाग में, हम उन तकनीकी उपकरणों पर विचार करेंगे, जो एक डेवलपर जो सॉफ्टवेयर विकास में एक माइक्रोसर्विस आर्किटेक्चर का उपयोग करने जा रहा है, उसे मास्टर होना चाहिए।
