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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

रेफरी> 
 * मापनीयता: चूंकि माइक्रोसर्विसेज एक दूसरे से स्वतंत्र रूप से कार्यान्वित और नियुक्त किए जाते हैं, यानी वे स्वतंत्र प्रक्रियाओं के अन्दर चलते हैं, उन्हें स्वतंत्र रूप से मॉनिटर और स्केल किया जा सकता है।

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

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

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

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

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

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

सेवा प्रतिनिधि अन्य सेवा उदाहरणों के साथ संचार के लिए ज़िम्मेदार हैं और सेवा (उदाहरण) खोज, भार संतुलन, प्रमाणीकरण और प्राधिकरण, सुरक्षित संचार और अन्य जैसी क्षमताओं का समर्थन कर सकते हैं।

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

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

यह भी देखें

 * कॉनवे का नियम
 * क्रॉस-कटिंग चिंता
 * डेटा मेश, एक डोमेन-ओरिएंटेड डेटा आर्किटेक्चर
 * देवऑप्स
 * वितरित कंप्यूटिंग की भ्रांतियां
 * ग्राफक्यूएल
 * जीआरपीसी
 * प्रतिनिधित्वात्मक राज्य स्थानांतरण (आरईएसटी)
 * सेवा-उन्मुख वास्तुकला (एसओए)
 * सॉफ्टवेयर आधुनिकीकरण
 * यूनिक्स दर्शन
 * स्व-निहित प्रणाली (सॉफ्टवेयर)
 * सर्वर रहित कंप्यूटिंग
 * वेब-उन्मुख वास्तुकला (डब्ल्यूओए)

आगे की पढाई

 * Special theme issue on microservices, IEEE Software 35(3), May/June 2018, https://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=8354413
 * I. Nadareishvili et al., Microservices Architecture – Aligning Principles, Practices and Culture, O'Reilly, 2016,  ISBN 978-1-491-95979-4
 * S. Newman, Building Microservices – Designing Fine-Grained Systems, O'Reilly, 2015 ISBN 978-1491950357
 * Wijesuriya, Viraj Brian (2016-08-29) Microservice Architecture, Lecture Notes - University of Colombo School of Computing, Sri Lanka
 * Christudas Binildas (June 27, 2019). Practical Microservices Architectural Patterns: Event-Based Java Microservices with Spring Boot and Spring Cloud. Apress. ISBN 978-1484245002.