क्या आप वाकई माइक्रोसेवर्स का उपयोग कर रहे हैं?

नमस्कार, हेब्र!

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

"माइक्रोसॉफ़्ट" शब्द पहली बार 2011/2012 के आसपास दिखाई दिया। तब से, आईटी वातावरण में बिना माइक्रोसिरोइस के, लगभग कहीं नहीं। हालांकि, इतने सालों के बाद, क्या हम ठीक से समझने में कामयाब रहे हैं कि माइक्रोसेवा क्या हैं?

पहले, आइए कुछ परिभाषाओं को देखें:

माइक्रोसॉफ़्ट सॉफ्टवेयर विकास (...) के लिए एक दृष्टिकोण है, जिसके अनुसार एक अनुप्रयोग शिथिल युग्मित सेवाओं के एक सेट के रूप में संरचित है। एक microservice वास्तुकला में, सेवाएं अत्यधिक विस्तृत हैं , और उपयोग किए जाने वाले प्रोटोकॉल हल्के हैं । अलग-अलग छोटी सेवाओं में किसी एप्लिकेशन को विघटित करने का लाभ प्रतिरूपकता में सुधार करना है । इस रूप में, आवेदन को समझना, विकसित करना, परीक्षण करना आसान है, और आवेदन स्वयं वास्तुकला के क्षरण के लिए अधिक प्रतिरोधी हो जाता है। वास्तुकला के इस दृष्टिकोण के साथ, विकास को समानांतर किया जाता है, और छोटे स्टैंड-अलोन टीमों को उन सेवाओं को स्वतंत्र रूप से विकसित करने , तैनात करने और पैमाने पर करने का अवसर मिलता है जिसके लिए वे जिम्मेदार हैं। इस दृष्टिकोण के साथ, प्रत्येक सेवा की वास्तुकला के लिए निरंतर रिफैक्टिंग लागू किया जा सकता है। माइक्रोसिस्टवर्क आर्किटेक्चर को निरंतर वितरण और निरंतर तैनाती के लिए भी डिज़ाइन किया गया है।
en.wikipedia.org/wiki/Microservices

मार्टिन फाउलर का एक और मार्ग है:

शब्द "माइक्रोसिस्टवर्क आर्किटेक्चर" को पिछले कुछ वर्षों में मजबूती से इस तरह के अनुप्रयोगों को डिजाइन करने के लिए एक विशेष तरीके से वर्णन किया गया है, जिनमें से प्रत्येक स्वतंत्र रूप से तैनात सेवाओं का एक सेट है। हालांकि इस स्थापत्य शैली की कोई सटीक परिभाषा नहीं है, लेकिन इसकी व्यावसायिक क्षमताओं, स्वचालित तैनाती, टर्मिनलों पर जानकारी का संग्रह, और भाषाओं और डेटा के विकेंद्रीकृत प्रबंधन के आसपास आवेदन के संगठन के बारे में कई सामान्य विशेषताएं हैं।
martinfowler.com/articles/microservices.html

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

क्या आपका सिस्टम आपको सेवाओं को स्वतंत्र रूप से पुनरारंभ करने की अनुमति देता है?

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

क्या आप सेवाओं को स्वतंत्र रूप से तैनात कर सकते हैं?

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

क्या एक संशोधन अन्य सेवाओं के लिए सिंक्रनाइज़ संशोधनों को बनाने की आवश्यकता को पूरा कर सकता है?

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

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

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

क्या डेटाबेस परिवर्तन से कई सेवाओं में बदलाव होता है?

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

क्या आप किसी एकल सेवा में जावा की निर्भरता या संस्करण को अपडेट कर सकते हैं?

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

क्या आपका चुना हुआ ढांचा या पुस्तकालय आपको अन्य सेवाओं में समान पसंद पर रहने के लिए मजबूर करता है?

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

मान लीजिए, उदाहरण के लिए, आपके पास NodeJS में लिखित कई सेवाएं हैं जो JSON: API का सक्रिय रूप से उपयोग करती हैं। अगला, आप स्काला पर एक नई सेवा लागू करना चाहते हैं और ऐसा लगता है कि कोई उपयुक्त क्लाइंट लाइब्रेरी नहीं है (कुछ साल पहले हमारे पास एक समान मामला था, लेकिन अब इस क्षेत्र की स्थिति में थोड़ा सुधार हुआ है)।

क्या एकल सेवा की विफलता पूरे सिस्टम की विफलता का कारण बनती है?

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

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

क्या आपके सिस्टम पर कोई साझा घटक है?

क्या आपके पास साझा कोड है? विन्यास? कुछ? हां, यह एक गैर-तुच्छ प्रश्न है। माइक्रोसर्विस की सफाई के पैरोकारों का मानना ​​है कि सिस्टम में साझा संस्थाओं को अनुमति नहीं देना सबसे अच्छा है! विभाजन कोड की तुलना में इसे कॉपी करना बेहतर है। व्यवहार में, यह कभी-कभी कई साझा पुस्तकालयों के लिए स्वीकार्य माना जाता है, लेकिन सख्त सीमाओं के साथ। शायद यह प्रोटोकॉल बफ़र्स या केवल साधारण POJO ऑब्जेक्ट्स के लिए proto फ़ाइलों वाली लाइब्रेरी होगी। ऐसे पुस्तकालयों में बेहतर निर्भरता से बचें। हमारे पास एक मामला था जहां एक साधारण ग्राहक पुस्तकालय जो एक बड़ी प्रणाली में निर्भरता संघर्ष का कारण बना। कुछ बिंदु पर, ऐसा लगने लगा कि एप्लिकेशन के सबसे पुराने तत्व पुराने HTTP लाइब्रेरी का उपयोग कर रहे थे, जिसे अपडेट नहीं किया जा सकता था। सौभाग्य से, निर्माण प्रक्रिया (निर्भरता छायांकन) में निर्भरता का उपयोग करके इन स्थितियों से बचा जा सकता है, लेकिन बहुत सावधान रहें।

कोड दोहराव के कारण होने वाली समस्याओं से सेवाओं के अधिक-सामंजस्य से नुकसान कहीं अधिक हानिकारक है।

सैम न्यूमैन, बनाना माइक्रोसिरोविसेज

निष्कर्ष

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

(...) आपको तुरंत ही एक नई परियोजना पर काम शुरू नहीं करना चाहिए, जिसमें माइक्रोसर्विसेस की शुरुआत हो, भले ही आपको यकीन हो कि आपका आवेदन काफी बड़ा होगा, ताकि माइक्रोसर्विस खुद को सही ठहरा सकें।
martinfowler.com/bliki/MonolithFirst.html

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