माइक्रोसर्विसेज

From Vigyanwiki

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

परिचय

माइक्रोसर्विसेज की कोई परिभाषा नहीं है। उद्योग में समय के साथ सर्वसम्मत दृष्टिकोण विकसित हुआ है। अधिकांशतः उद्धृत की जाने वाली कुछ परिभाषित विशेषताओं में सम्मिलित हैं:

  • माइक्रोसर्विस आर्किटेक्चर में सेवाएं अधिकांशतः प्रक्रिया होती हैं जो एचटीटीपी जैसे प्रौद्योगिकी-अज्ञेय संचार प्रोटोकॉल का उपयोग करके लक्ष्य को पूरा करने के लिए कंप्यूटर नेटवर्क पर संचार करती हैं।[2][3][4]
  • सेवाएँ व्यावसायिक क्षमताओं के आस-पास व्यवस्थित की जाती हैं।[5]
  • सेवाओं को विभिन्न प्रोग्रामिंग भाषाओँ , डेटाबेस , हार्डवेयर और सॉफ़्टवेयर वातावरणों का उपयोग करके कार्यान्वित किया जा सकता है, जो इस बात पर निर्भर करता है कि कौन सा सबसे उपयुक्त है।[6]
  • सेवाएँ आकार में छोटी, संदेश-सक्षम, संदर्भों से घिरी हुई, स्वायत्त रूप से विकसित, स्वतंत्र रूप से परिनियोजन योग्य,[7][6] विकेंद्रीकृत और स्वचालन और अनुप्रयोग रिलीज स्वचालित हैं।[7]

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

  • सतत वितरण सॉफ्टवेयर विकास प्रक्रिया के लिए स्वयं को ऋण देता है। अनुप्रयोग के छोटे से हिस्से में परिवर्तन के लिए केवल एक या कुछ ही सेवाओं के पुनर्निर्माण और पुनर्वितरण की आवश्यकता होती है।[10]
  • फाइन-ग्रेन्ड इंटरफेस (स्वतंत्र रूप से नियुक्ति योग्य सेवाओं के लिए), व्यवसाय-संचालित विकास (जैसे डोमेन-संचालित डिजाइन) जैसे सिद्धांतों का पालन करता है।[11]

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

इतिहास

माइक्रोसर्विसेज शब्द की उत्पत्ति के संबंध में कई प्रमाण हैं। 2004 में विचार काम करता है के उपाध्यक्ष रहते हुए, फ्रेड जॉर्ज ने प्रोटोटाइप आर्किटेक्चर पर काम करना प्रारंभ किया, जिसे उन्होंने जेफ बे के नाम पर बेसियन सिद्धांत कहा है।[15]

2005 के प्रारंभ में, पीटर रॉजर्स ने वेब सेवा एज सम्मेलन में प्रस्तुति के समय माइक्रो-वेब सेवा शब्द का प्रारंभ किया। पारंपरिक सोच के विरुद्ध और एसओएपी एसओए आर्किटेक्चर प्रचार वक्र की ऊंचाई पर उन्होंने प्रतिनिधि राज्य हस्तांतरण-सेवाओं के लिए तर्क दिया और सम्मेलन प्रस्तुति की स्लाइड #4 पर, उन्होंने चर्चा की कि सॉफ्टवेयर घटक माइक्रो-वेब-सर्विसेज हैं।[16] उन्होंने कहा कि माइक्रो-सर्विसेज पाइपलाइन (यूनिक्स) जैसी पाइपलाइनों ( डब्ल्यूडब्ल्यूडब्ल्यू यूनिक्स = ट्रू लूज कपलिंग से मिलती है) का उपयोग करके बनाई गई हैं। सेवाएं सेवाओं को कॉल कर सकती हैं। कॉम्प्लेक्स सेवा असेंबली सरल यूआरआई इंटरफेस के पीछे अमूर्त हैं। कोई भी सेवा, किसी भी ग्रैन्युलैरिटी पर, प्रदर्शित की जा सकती है। उन्होंने वर्णन किया कि कैसे अच्छी तरह से डिज़ाइन किया गया माइक्रोसर्विसेज प्लेटफ़ॉर्म डब्ल्यूडब्ल्यूडब्ल्यू और आरइएसटी सेवाओं के अंतर्निहित वास्तु सिद्धांतों को यूनिक्स जैसी शेड्यूलिंग और पाइपलाइनों के साथ प्रयुक्त करता है जिससे सेवा-उन्मुख आर्किटेक्चर में कट्टरपंथी लचीलापन और उत्तम सरलता प्रदान की जा सके।[17]

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

2007 में, जुवल लोवी ने अपने लेखन[19] और बोलने[20][21] में ऐसे प्रणाली बनाने का आह्वान किया जिसमें हर वर्ग सेवा हो। लोवी ने अनुभव किया कि इसके लिए ऐसी विधि के उपयोग की आवश्यकता है जो सेवाओं के इस तरह के व्यापक उपयोग का समर्थन कर सके, और उन्होंने ऐसा करने के लिए विंडोज संचार फाउंडेशन (डब्ल्यूसीएफ) का विस्तार किया।[22][23] जिससे कक्षाओं के पारंपरिक प्रोग्रामिंग मॉडल को बनाए रखते हुए हर वर्ग को लेना और इसे सेवा के रूप में माना जा सके।

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

मई 2011 में वेनिस के पास आयोजित सॉफ्टवेयर आर्किटेक्ट्स की कार्यशाला ने माइक्रोसर्विस शब्द का उपयोग यह वर्णन करने के लिए किया कि प्रतिभागियों ने सामान्य वास्तुशिल्प शैली के रूप में क्या देखा जो उनमें से कई हाल ही में खोज रहे थे।[24] मई 2012 में, उसी समूह ने सबसे उपयुक्त नाम के रूप में माइक्रोसर्विसेज पर निर्णय लिया। जेम्स लुईस ने उन कुछ विचारों को मार्च 2012 में माइक्रोसर्विसेज - जावा, यूनिक्स वे में क्राको में 33वीं डिग्री में स्थिति का अध्ययन के रूप में प्रस्तुत किया।[25] जैसा कि उसी समय के बारे में फ्रेड जॉर्ज ने किया था।[26] एड्रियन कॉक्रॉफ्ट, नेटफ्लिक्स में क्लाउड प्रणाली्स के पूर्व निदेशक,[27] इस दृष्टिकोण को सुक्ष्म एसओए के रूप में वर्णित किया, वेब-पैमाना पर शैली का नेतृत्व किया, जैसा कि इस लेख में उल्लिखित कई अन्य - जो वाल्नेस, डैन नॉर्थ, इवान बॉटचर और ग्राहम टैक्ले ने किया।[28]

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

फरवरी 2020 में, क्लाउड माइक्रोसर्विसेज मार्केट रिसर्च सूची ने भविष्यवाणी की थी कि वैश्विक माइक्रोसर्विस आर्किटेक्चर व्यापार का आकार 2019 से 2026 तक 21.37% की चक्रवृद्धि वार्षिक वृद्धि दर से बढ़ेगा और 2026 तक 3.1 बिलियन डॉलर तक पहुंच जाएगा।[30]

सेवा ग्रैन्युलैरिटी

माइक्रोसर्विस आर्किटेक्चर को परिभाषित करने में महत्वपूर्ण कदम यह पता लगाना है कि व्यक्तिगत माइक्रोसेवा कितनी बड़ी होनी चाहिए। इसके लिए कोई सहमति या लिटमस परीक्षण नहीं है, क्योंकि सही उत्तर व्यवसाय और संगठनात्मक संदर्भ पर निर्भर करता है।[31] उदाहरण के लिए, अमेज़ॅन (कंपनी) सेवा-उन्मुख वास्तुकला का उपयोग करता है जहां सेवा अधिकांशतः 3 से 10 इंजीनियरों की टीम के साथ 1: 1 मैप करती है।[32] सामान्यतः, शब्दावली इस प्रकार होती है: ऐसी सेवाएँ जो किसी कार्य के लिए समर्पित होती हैं, जैसे किसी विशेष बैकएंड प्रणाली को कॉल करना या किसी विशेष प्रकार की गणना करना, परमाणु सेवाएँ कहलाती हैं। इसी तरह, ऐसी सेवाएं जो आउटपुट को समेकित करने के लिए ऐसी परमाणु सेवाओं को बुलाती हैं, समग्र सेवाएं कहलाती हैं।

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

यदि डोमेन-संचालित डिज़ाइन को उस डोमेन के मॉडलिंग में नियोजित किया जा रहा है जिसके लिए प्रणाली बनाया जा रहा है, तो माइक्रोसर्विस समुच्चय जितना छोटा या सीमित संदर्भ जितना बड़ा हो सकता है।[33]

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

लाभ

किसी अनुप्रयोग को विभिन्न छोटी सेवाओं में विघटित करने के कई लाभ हैं:

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

आलोचना और सरोकार

माइक्रोसर्विसेज दृष्टिकोण कई उद्देश्यों के लिए आलोचना का विषय है:

  • सेवाएँ सूचना अवरोध बनाती हैं।[36]
  • नेटवर्क पर अन्तः-सेवा कॉल की व्यय नेटवर्क विलंबता और संदेश प्रसंस्करण समय की स्थिति में अखंड प्रणाली सेवा प्रक्रिया के अन्दर इन-प्रोसेस कॉल की तुलना में अधिक होती है।[2]
  • परीक्षण और परिनियोजन अधिक जटिल हैं।[37][38]
  • सेवाओं के बीच उत्तरदायित्वों को स्थानांतरित करना अधिक कठिन होता है।[6] इसमें विभिन्न टीमों के बीच संचार सम्मिलित हो सकता है, किसी अन्य भाषा में कार्यक्षमता को पुनः लिखना या इसे अलग मूलभूत ढांचे में फ़िट करना सम्मिलित हो सकता है।[2] चूँकि, माइक्रोसर्विसेज को शेष अनुप्रयोग से स्वतंत्र रूप से नियुक्त किया जा सकता है, किन्तु मोनोलिथ पर काम करने वाली टीमों को एक साथ नियुक्त करने के लिए सिंक्रनाइज़ करने की आवश्यकता होती है।[39]
  • सेवाओं के आकार को प्राथमिक संरचना तंत्र के रूप में देखने से बहुत सारी सेवाएँ हो सकती हैं जब आंतरिक मॉड्यूलरीकरण के विकल्प से सरल डिज़ाइन हो सकता है।[40] इसके लिए अनुप्रयोगों के समग्र आर्किटेक्चर और घटकों के बीच अन्योन्याश्रितताओं को समझने की आवश्यकता है।[41]
  • दो-चरण प्रतिबद्ध प्रोटोकॉल को माइक्रोसर्विसेज-आधारित आर्किटेक्चर में विरोधी-पैटर्न के रूप में माना जाता है क्योंकि इसके परिणामस्वरूप लेन-देन के अन्दर सभी प्रतिभागियों का कड़ा युग्मन होता है। चूँकि, इस विधि की कमी विचित्र नृत्य का कारण बनती है जिसे डेटा स्थिरता बनाए रखने के लिए सभी लेन-देन प्रतिभागियों द्वारा प्रयुक्त किया जाना है।[42]
  • कई सेवाओं का विकास और समर्थन अधिक चुनौतीपूर्ण होता है यदि वे विभिन्न उपकरणों और तकनीकों के साथ निर्मित होते हैं - यह विशेष रूप से समस्या है यदि इंजीनियर बार-बार परियोजनाओं के बीच चलते हैं।[43]
  • सामान्यतः माइक्रोसर्विसेज (एचटीटीपी) के साथ उपयोग किए जाने वाले प्रोटोकॉल को सार्वजनिक-सामना करने वाली सेवाओं के लिए डिज़ाइन किया गया था, और इस तरह यह आंतरिक माइक्रोसर्विसेज के काम करने के लिए अनुपयुक्त है जो अधिकांशतः त्रुटिहीन रूप से विश्वसनीय होना चाहिए।[44]
  • जबकि माइक्रोसर्विसेज के लिए विशिष्ट नहीं है, अपघटन पद्धति अक्सर कार्यात्मक अपघटन का उपयोग करती है, जो सेवाओं की जटिलता को जोड़ते हुए आवश्यकताओं में परिवर्तन को संभाल नहीं पाती है।[44]
  • माइक्रोसर्विस की बहुत अवधारणा भ्रामक है क्योंकि केवल सेवाएँ हैं। कोई सेवा कब शुरू होती है या कब बंद हो जाती है, इसकी कोई ठोस परिभाषा नहीं है।[44]
  • डेटा एकत्रीकरण। एक कार्य प्रणाली का पूरा दृश्य देखने के लिए, माइक्रोसर्विसेज रिपॉजिटरी से डेटा सेट निकालने और उन्हें एक स्कीमा में एकत्र करने की आवश्यकता होती है। उदाहरण के लिए, परिचालन रिपोर्ट बनाने में सक्षम होने के लिए जो एकल माइक्रोसर्विस रिपॉजिटरी का उपयोग करके संभव नहीं है।

संज्ञानात्मक भार

आर्किटेक्चर अतिरिक्त जटिलता और निपटने के लिए नई समस्याओं का परिचय देता है, जैसे कि नेटवर्क विलंबता , संदेश प्रारूप डिजाइन,[45] बैकअप /उपलब्धता/संगति (बीएसी),[46] लोड संतुलन (कंप्यूटिंग) और गलती सहनशीलता।[38] इन सभी समस्याओं का बड़े पैमाने पर समाधान करना होगा।






संज्ञानाात्मक भार

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

प्रौद्योगिकियों

कंप्यूटर माइक्रोसर्विसेज को विभिन्न प्रोग्रामिंग भाषाओं में प्रयुक्त किया जा सकता है और विभिन्न इन्फ्रास्ट्रक्चर का उपयोग कर सकता है। इसलिए, सबसे महत्वपूर्ण प्रौद्योगिकी विकल्प हैं जिस तरह से माइक्रोसर्विसेज एक दूसरे के साथ संवाद करते हैं (सिंक्रोनस, एसिंक्रोनस, यूआई इंटीग्रेशन) और संचार के लिए उपयोग किए जाने वाले प्रोटोकॉल (रेस्टफुल एचटीटीपी, मैसेजिंग, ग्राफक्यूएल...) हैं। पारंपरिक प्रणाली में, प्रोग्रामिंग भाषा जैसे अधिकांश तकनीकी विकल्प पूरे प्रणाली को प्रभावित करते हैं। इसलिए, प्रौद्योगिकियों को चुनने का दृष्टिकोण अत्यधिक अलग है।[49]

ग्रहण फाउंडेशन ने माइक्रोसर्विसेज, एक्लिप्स माइक्रोप्रोफाइल के विकास के लिए विनिर्देश प्रकाशित किया है।[50][51]

सेवा मेश

See also: सेवा मेश

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

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

प्लेटफार्मों की तुलना

माइक्रोसर्विस आर्किटेक्चर को प्रयुक्त करना बहुत जटिल है। ऐसी कई चिंताएँ हैं (नीचे दी गई तालिका देखें) जिन्हें किसी भी माइक्रोसर्विस आर्किटेक्चर को संबोधित करने की आवश्यकता है। नेटफ्लिक्स ने अपने आंतरिक अनुप्रयोगों का समर्थन करने के लिए माइक्रोसर्विस फ्रेमवर्क विकसित किया, और फिर उस ढांचे के कई हिस्सों को किया।[52] इनमें से कई उपकरण स्प्रिंग फ्रेमवर्क के माध्यम से लोकप्रिय हुए हैं - उन्हें स्प्रिंग क्लाउड परियोजना की छतरी के नीचे स्प्रिंग-आधारित उपकरण के रूप में पुनः प्रयुक्त किया गया है।[53] नीचे दी गई तालिका कुबेरनेट्स पारिस्थितिकी तंत्र से स्प्रिंग क्लाउड विश्व के समकक्ष कार्यान्वयन सुविधा की तुलना दिखाती है।[54] स्प्रिंग क्लाउड इकोप्रणाली का उल्लेखनीय पहलू यह है कि वे सभी जावा-आधारित प्रौद्योगिकियां हैं, किन्तु कुबेरनेट्स बहुभाषाविद रनटाइम प्लेटफॉर्म है।

माइक्रोसर्विसेज चिंता स्प्रिंग क्लाउड और नेटफ्लिक्स ओएसएस कुबेरनेट्स
कॉन्फ़िगरेशन प्रबंधन: माइक्रोसर्विस अनुप्रयोग के लिए कॉन्फ़िगरेशन को कोड से बाहर करने और साधारण सेवा कॉल के माध्यम से पुनर्प्राप्त करने योग्य होना चाहिए। स्प्रिंग कॉन्फिग सर्वर, नेटफ्लिक्स आर्कियस दोनों कॉन्फ़िगरेशन के लिए गिट-रिपॉजिटरी-आधारित स्थान का समर्थन करते हैं। आर्कियस कॉन्फ़िगरेशन के डेटा टाइपिंग का समर्थन करता है। कुबेरनेट्स कॉन्फिगमैप्स सेवाओं के माध्यम से ईटीसीडी में संग्रहीत कॉन्फ़िगरेशन को उजागर करता है। कुबेरनेट्स सीक्रेट सेवा-आधारित सुरक्षित परिनियोजन और संवेदनशील कॉन्फ़िगरेशन जानकारी (जैसे पासवर्ड, प्रमाणपत्र, आदि) के उपयोग का समर्थन करता है।
सेवा खोज: माइक्रोसर्विस डोमेन के भीतर काम करने के लिए उपलब्ध सेवा उदाहरणों की सूची बनाए रखें। स्प्रिंग क्लाउड यूरेका ग्राहकों को इसमें पंजीकरण करने की अनुमति देता है, पंजीकृत ग्राहकों के साथ दिल की धड़कन बनाए रखता है, और सेवा नाम से सेवाओं को देखने वाले ग्राहकों के लिए होस्टनाम के लिए सेवा नाम मैप करता है। कुबेरनेट्स सेवाएं क्लस्टर के अन्दर आंतरिक रूप से उपलब्ध सेवाओं के उदाहरणों का परिनियोजन-समय पंजीकरण प्रदान करती हैं। प्रवेश ऐसा तंत्र है जिसके द्वारा क्लस्टर के बाहर ग्राहकों को सेवा प्रदान की जा सकती है।
भार संतुलन: वितरित प्रणाली को पैमाना करने की कुंजी घटक के एक से अधिक उदाहरणों को चलाने में सक्षम हो रही है। लोड को लोड बैलेंसर के माध्यम से उन उदाहरणों में वितरित किया जाना चाहिए। स्प्रिंग क्लाउड रिबन सेवा ग्राहकों को सेवा के उदाहरणों में संतुलन लोड करने की क्षमता प्रदान करता है। कुबेरनेट्स सेवा सेवा को सेवा उदाहरणों में लोड-संतुलित होने की क्षमता प्रदान करती है। यह रिबन जो प्रदान करता है उसके बराबर नहीं है।
एपीआई गेटवे: माइक्रोसर्विसेज द्वारा प्रदान की जाने वाली एपीआई की ग्रैन्युलैरिटी अधिकांशतः सेवा क्लाइंट की आवश्यकता से अलग होती है। एपीआई गेटवे अग्रभागों को प्रयुक्त करता है और प्रॉक्सीइंग, और प्रोटोकॉल अनुवाद, और अन्य प्रबंधन कार्यों जैसी अतिरिक्त सेवाएं प्रदान करता है। स्प्रिंग क्लाउड ज़ूल कॉन्फ़िगरेशन-आधारित एपीआई पहलू प्रदान करता है कुबेरनेट्स सेवा और प्रवेश संसाधन, इस्तियो, एंबेसडर ऐसे समाधान हैं जो उत्तर-दक्षिण (डेटा सेंटर में और बाहर यातायात) के साथ-साथ पूर्व-पश्चिम (डेटा केंद्रों या बादलों या क्षेत्रों में यातायात) एपीआई गेटवे फलन प्रदान करते हैं। ज़ूल को कुबेरनेट्स के साथ भी प्रयुक्त किया जा सकता है, जो व्यक्तिगत सेवा स्तर पर कॉन्फ़िगरेशन प्रदान करता है।
सुरक्षा संबंधी चिंताएँ: कई सुरक्षा चिंताओं को एपीआई गेटवे कार्यान्वयन के लिए धकेल दिया जाता है। वितरित माइक्रोसेवा अनुप्रयोगों के साथ, यह सुरक्षा चक्र को पुनः प्रारंभ नहीं करने और सभी सेवाओं द्वारा साझा किए जाने वाले घटकों में नीति परिभाषा और कार्यान्वयन की अनुमति देने के लिए समझ में आता है। स्प्रिंग क्लाउड सुरक्षा स्प्रिंग क्लाउड ज़ूल के माध्यम से कई सुरक्षा चिंताओं को हल करती है कुबेरनेट्स पारिस्थितिकी तंत्र इस्तियो जैसी सेवा मेश प्रदान करता है, जो अपने एपीआई गेटवे तंत्र के माध्यम से सुरक्षा प्रदान करने में सक्षम हैं।
केंद्रीकृत लॉगिंग: सेवाओं की अधिकता का प्रबंधन करने के लिए केंद्रीकृत लॉग संग्रह और विश्लेषण मूलभूत ढांचा होना महत्वपूर्ण है - जिनमें से कई वितरित विधि से काम कर रहे हैं। ईएलके स्टैक (लोचदार खोज, लॉगस्टैश, किबाना) ईएफके स्टैक (लोचदार खोज, धाराप्रवाह, किबाना)
केंद्रीकृत आव्यूह: केंद्रीकृत क्षेत्र जहां व्यक्तिगत सेवाओं और समग्र प्रणाली के स्वास्थ्य और प्रदर्शन की देखरेख की जा सकती है, उचित संचालन के लिए आवश्यक है। स्प्रिंग स्पेक्टेटर और एटलस हीपस्टर, प्रोमेथियस, और ग्राफाना
वितरित अनुरेखण: प्रति-प्रक्रिया लॉगिंग और मीट्रिक मॉनिटरिंग का अपना स्थान है, लेकिन कोई भी उन जटिल रास्तों का पुनर्निर्माण नहीं कर सकता है जो लेन-देन वितरित प्रणाली में प्रचारित करते हैं। डिस्ट्रीब्यूटेड ट्रेसिंग माइक्रोसर्विसेज प्लेटफॉर्म के लिए आवश्यक उपकरण है। स्प्रिंग क्लाउड स्लीथ हॉकुलर, जैगर
लचीलापन और गलती सहनशीलता: वितरित प्रणाली विफलताओं के आस-पास ऑटो-रूटिंग करने में सक्षम होना चाहिए, और सेवा उदाहरण के लिए अनुरोधों को रूट करने में सक्षम होना चाहिए जो इष्टतम प्रतिक्रिया प्रदान करेगा। स्प्रिंग हिस्ट्रिक्स, टर्बाइन और रिबन स्वास्थ्य परीक्षण, सेवा मेश (उदाहरण: इस्तिओ)[55]
ऑटोस्केलिंग और सेल्फ-हीलिंग: वितरित प्रणाली क्षैतिज रूप से स्केलिंग करके उच्च भार का उत्तर देते हैं: प्लेटफॉर्म को ऐसी स्थितियों का पता लगाना चाहिए और ऑटो-प्रतिक्रिया करनी चाहिए। इसके अतिरिक्त, प्रणाली को विफलताओं का पता लगाने और ऑपरेटर इनपुट के बिना ऑटो-पुनरारंभ करने का प्रयास करने की आवश्यकता है। - स्वास्थ्य जांच, स्व-उपचार और ऑटो-स्केलिंग
पैकेजिंग, परिनियोजन, और शेड्यूलिंग: बड़े पैमाने पर प्रणाली को ठोस पैकेज प्रबंधन की आवश्यकता होती है, और रोलिंग या ब्लू-ग्रीन परिनियोजन और यदि आवश्यक हो तो रोलबैक प्रबंधित करने के लिए परिनियोजन प्रणाली की आवश्यकता होती है। अनुसूचक यह निर्धारित करने में सहायता करता है कि वर्तमान परिस्थितियों के आधार पर किस विशेष निष्पादन नोड को सेवाओं का नया सेट नियुक्त किया जा सकता है। स्प्रिंग बूट, अपाचे मावेन। स्प्रिंग क्लाउड प्रणाली में कोई वास्तविक अनुसूचक नहीं है। डॉकर, आरकेटी, कुबेरनेट्स शेड्यूलर और डिप्लॉयमेंट, हेल्म[56]
कार्य प्रबंधन: किसी भी व्यक्तिगत उपयोगकर्ता अनुरोधों से डिस्कनेक्ट किए गए शेड्यूल किए गए कंप्यूटेशंस। स्प्रिंग बैच कुबेरनेट्स नौकरियां और अनुसूचित नौकरियां
सिंगलटन अनुप्रयोग: पूरे प्रणाली के अन्दर उस सेवा के एकमात्र उदाहरण के रूप में चलने के लिए विशिष्ट सेवा को सीमित करें। स्प्रिंग क्लाउड क्लस्टर कुबेरनेट्स पॉड

यह भी देखें

संदर्भ

  1. ↑ "माइक्रोसर्विस आर्किटेक्चर: उनके भागों के योग से अधिक?". IONOS Digitalguide (in English). Retrieved 2022-03-29.
  2. ↑ 2.0 2.1 2.2 2.3 Martin Fowler. "माइक्रोसर्विसेज". Archived from the original on 14 February 2018.
  3. ↑ Newman, Sam (2015-02-20). बिल्डिंग माइक्रोसर्विसेज. O'Reilly Media. ISBN 978-1491950357.
  4. ↑ Wolff, Eberhard (2016-10-12). माइक्रोसर्विसेज: फ्लेक्सिबल सॉफ्टवेयर आर्किटेक्चर. ISBN 978-0134602417.
  5. ↑ 5.0 5.1 5.2 Pautasso, Cesare (2017). "व्यवहार में माइक्रोसर्विसेज, भाग 1: वास्तविकता की जांच और सेवा डिजाइन". IEEE Software. 34 (1): 91–98. doi:10.1109/MS.2017.24. S2CID 5635705.
  6. ↑ 6.0 6.1 6.2 6.3 Chen, Lianping (2018). माइक्रोसर्विसेज: कंटीन्यूअस डिलीवरी और DevOps के लिए आर्किटेक्चरिंग. The IEEE International Conference on Software Architecture (ICSA 2018). IEEE.
  7. ↑ 7.0 7.1 Nadareishvili, I., Mitra, R., McLarty, M., Amundsen, M., Microservice Architecture: Aligning Principles, Practices, and Culture, O'Reilly 2016
  8. ↑ "फ्रंटएंड पैटर्न के लिए बैकएंड". Microsoft Azure Cloud Design Patterns. Microsoft.
  9. ↑ Lucas Krause. माइक्रोसर्विसेज: पैटर्न और अनुप्रयोग. ASIN B00VJ3NP4A.
  10. ↑ Designing microservices: Continuous integration Microsoft Retrieved 9 January 2018
  11. ↑ Josuttis, N. (2007). SOA in Practice. Sebastopol, CA, USA: O'Reilly. ISBN 978-0-596-52955-0.
  12. ↑ Martin Fowler. "माइक्रोसर्विस पूर्वापेक्षाएँ".
  13. ↑ Richardson, Chris (November 2018). "1.4.1 Scale cube and microservices". माइक्रोसर्विसेज पैटर्न. Manning Publications. ISBN 9781617294549.
  14. ↑ Mendonca, Nabor C.; Jamshidi, Pooyan; Garlan, David; Pahl, Claus (2019-10-16). "स्व-अनुकूली माइक्रोसर्विस सिस्टम विकसित करना: चुनौतियाँ और दिशाएँ". IEEE Software. 38 (2): 70–79. arXiv:1910.07660. doi:10.1109/MS.2019.2955937. S2CID 204744007.
  15. ↑ "वह टेक शो: द ग्रैंडफादर ऑफ माइक्रोसर्विसेज, फ्रेड जॉर्ज".
  16. ↑ Rodgers, Peter. "नेटकर्नेल पर सेवा-उन्मुख विकास- सिस्टम जटिलता को कम करने के लिए पैटर्न, प्रक्रियाएं और उत्पाद वेब सर्विसेज एज 2005 पूर्व: सीएस-3". CloudComputingExpo 2005. SYS-CON TV. Archived from the original on 20 May 2018. Retrieved 3 July 2017.
  17. ↑ Rodgers, Peter. "नेटकर्नेल पर सेवा-उन्मुख विकास- सिस्टम जटिलता को कम करने के लिए पैटर्न, प्रक्रियाएं और उत्पाद". CloudComputingExpo. SYS-CON Media. Archived from the original on 20 May 2018. Retrieved 19 August 2015.
  18. ↑ Russell, Perry; Rodgers, Peter; Sellman, Royston (2004). "एक्सएमएल एप्लीकेशन प्लेटफॉर्म का आर्किटेक्चर और डिजाइन". HP Technical Reports. p. 62. Retrieved 20 August 2015.
  19. ↑ Löwy, Juval (2007). प्रोग्रामिंग डब्ल्यूसीएफ सर्विसेज, पहला संस्करण।. O’Reilly Media. pp. 543–553. ISBN 978-0-596-52699-3.
  20. ↑ Juval Löwy "Every Class a WCF Service". (Channel9, ARCast.TV, October 2007).
  21. ↑ Juval Löwy "Every Class As a Service" (Microsoft TechEd Conference, May 2009), SOA206. Archived from the original on 2010.
  22. ↑ Löwy, Juval (2007). प्रोग्रामिंग डब्ल्यूसीएफ सर्विसेज, पहला संस्करण।. O’Reilly Media. pp. 48–51. ISBN 978-0-596-52699-3.
  23. ↑ Löwy, Juval (2010). प्रोग्रामिंग डब्ल्यूसीएफ सर्विसेज, तीसरा संस्करण।. O’Reilly Media. pp. 74–75. ISBN 978-0-596-80548-7.
  24. ↑ Dragoni, Nicola; Giallorenzo, Saverio; Lafuente, Alberto Lluch; Mazzara, Manuel; Montesi, Fabrizio; Mustafin, Ruslan; Safina, Larisa (2017). "माइक्रोसर्विसेज: कल, आज और कल". Present and Ulterior Software Engineering: 195–216. arXiv:1606.04036. doi:10.1007/978-3-319-67425-4_12. ISBN 978-3-319-67424-7. S2CID 14612986.
  25. ↑ James Lewis. "माइक्रो सर्विसेज - जावा, यूनिक्स वे".
  26. ↑ Fred George (2013-03-20). "माइक्रोसर्विस आर्किटेक्चर: डिस्कवरी की एक व्यक्तिगत यात्रा".
  27. ↑ Farrow, Rik (2012). "नेटफ्लिक्स बादलों में जाता है" (PDF).
  28. ↑ James Lewis and Martin Fowler. "Microservices".
  29. ↑ "सतत परिनियोजन: रणनीतियाँ". javacodegeeks.com. 10 December 2014. Retrieved 28 December 2016.
  30. ↑ Research, Verified Market. "क्लाउड माइक्रोसर्विसेज मार्केट 2020 के रुझान, मार्केट शेयर, उद्योग का आकार, अवसर, विश्लेषण और 2026 तक पूर्वानुमान - इंस्टेंट टेक मार्केट न्यूज़" (in English). Retrieved 2020-02-18.
  31. ↑ O. Zimmermann, Domain-Specific Service Decomposition with Microservice API Patterns, Microservices 2019, https://www.conf-micro.services/2019/slides//keynotes/Zimmerman.pdf
  32. ↑ "अमेज़न SOA जनादेश". 13 October 2011.
  33. ↑ Vaughn, Vernon (2016). डोमेन-संचालित डिज़ाइन डिस्टिल्ड. Addison-Wesley Professional. ISBN 978-0-13-443442-1.
  34. ↑ Richardson, Chris. "माइक्रोसर्विस आर्किटेक्चर पैटर्न". microservices.io. Retrieved 2017-03-19.
  35. ↑ Chen, Lianping; Ali Babar, Muhammad (2014). "चुस्त सॉफ्टवेयर विकास में सतत रिफैक्टरिंग के माध्यम से वास्तुकला के उद्भव की एक साक्ष्य-आधारित समझ की ओर". Proceedings Working IEEE/IFIP Conference on Software Architecture 2014 WICSA 2014. The 11th Working IEEE/IFIP Conference on Software Architecture(WICSA 2014). IEEE. doi:10.1109/WICSA.2014.45.
  36. ↑ Stenberg, Jan (11 August 2014). "माइक्रोसर्विसेज के साथ विफल होने के अनुभव".
  37. ↑ Calandra, Mariano (7 April 2021). "जब माइक्रोसर्विसेज की बात आती है तो यूनिट टेस्टिंग पर्याप्त क्यों नहीं है".
  38. ↑ 38.0 38.1 38.2 "स्प्रिंग और क्लाउड फाउंड्री के साथ PaaS के लिए माइक्रोसर्विसेज का विकास".
  39. ↑ Taibi, Davide; Lenarduzzi, Valentina; Pahl, Claus; Janes, Andrea (2017). "Microservices in agile software development: a workshop-based study into issues, advantages, and disadvantages". Proceedings of the XP2017 Scientific Workshops. doi:10.1145/3120459.3120483. S2CID 28134110.
  40. ↑ Tilkov, Stefan (17 November 2014). "आपकी माइक्रोसेवा कितनी छोटी होनी चाहिए?". Innoq. Retrieved 4 January 2017.
  41. ↑ Lanza, Michele; Ducasse, Stéphane (2002). "सॉफ़्टवेयर विज़ुअलाइज़ेशन और सॉफ़्टवेयर मेट्रिक्स के संयोजन का उपयोग करके सॉफ़्टवेयर विकास को समझना" (PDF). In Proceedings of LMO 2002 (Langages et Modèles à Objets): 135–149.
  42. ↑ Richardson, Chris (November 2018). माइक्रोसर्विसेज पैटर्न. Chapter 4. Managing transactions with sagas: Manning Publications. ISBN 978-1-61729454-9.{{cite book}}: CS1 maint: location (link)
  43. ↑ "- यूट्यूब". YouTube.
  44. ↑ 44.0 44.1 44.2 Löwy, Juval (2019). Righting Software 1st ed. Addison-Wesley Professional. pp. 73–75. ISBN 978-0136524038.
  45. ↑ Pautasso, Cesare (2017). "व्यवहार में माइक्रोसर्विसेज, भाग 2: सेवा एकीकरण और स्थिरता". IEEE Software. 34 (2): 97–104. doi:10.1109/MS.2017.56. S2CID 30256045.
  46. ↑ 46.0 46.1 Pautasso, Cesare (2018). "माइक्रोसर्विसेज के लिए लगातार डिजास्टर रिकवरी: बीएसी प्रमेय". IEEE Cloud Computing. 5 (1): 49–59. doi:10.1109/MCC.2018.011791714. S2CID 4560021.
  47. ↑ Fowler, Martin. "माइक्रोसर्विस ट्रेड-ऑफ्स".
  48. ↑ "BRASS बिल्डिंग रिसोर्स एडेप्टिव सॉफ्टवेयर सिस्टम". U.S. Government. DARPA. April 7, 2015. "Access to system components and the interfaces between clients and their applications, however, are mediated via a number of often unrelated mechanisms, including informally documented application programming interfaces (APIs), idiosyncratic foreign function interfaces, complex ill-understood model definitions, or ad hoc data formats. These mechanisms usually provide only partial and incomplete understanding of the semantics of the components themselves. In the presence of such complexity, it is not surprising that applications typically bake-in many assumptions about the expected behavior of the ecosystem they interact with".
  49. ↑ Wolff, Eberhard (2018-04-15). माइक्रोसर्विसेज - एक व्यावहारिक गाइड. ISBN 978-1717075901.
  50. ↑ Swart, Stephanie (14 December 2016). "ग्रहण माइक्रोप्रोफाइल". projects.eclipse.org.
  51. ↑ "माइक्रोप्रोफाइल". माइक्रोप्रोफाइल (in English). Retrieved 2021-04-11.{{cite web}}: CS1 maint: url-status (link)
  52. ↑ Netflix OSS, Git Hub
  53. ↑ Cloud, Spring
  54. ↑ "Spring Cloud for Microservices Compared to Kubernetes", Developers, Red hat, 2016-12-09
  55. ↑ Managing microservices with the Istio service mesh, Kubernetes, May 2017
  56. ↑ The Kubernetes Package Manager, Helm

आगे की पढाई

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=माइक्रोसर्विसेज&oldid=99538’