👩🏼‍🎓 🐴 ✳️ Microservices: यह क्या है, क्यों है और आपको उन्हें लागू करने की आवश्यकता कब है 🚪 🏅 😫

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

कॉनवे कानून और व्यापार, संगठन और सूचना प्रणाली के बीच संबंध

एक बार फिर, मैं अपने आप को उद्धृत करने की अनुमति देता हूं:

"कोई भी संगठन जो एक प्रणाली को डिजाइन करता है (व्यापक अर्थों में) एक डिजाइन प्राप्त करेगा जिसकी संरचना इस संगठन में टीमों की संरचना को कॉपी करती है"
- मेल्विन कॉनवे, 1967

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

बिजनेस ओरिएंटेशन इंफॉर्मेशन सिस्टम

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

क्या सब कुछ बहता है, क्या सबकुछ बदल जाता है, या क्या माइक्रोसॉफ़्ट जटिलता से निपटने का एक तरीका है?

जारी रखने से पहले, हम microservice वास्तुकला के बारे में कुछ गलत धारणाओं पर विचार करेंगे।

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

विषम ढेर का उपयोग करने का लाभ भी संदिग्ध है। मैं यह तर्क नहीं दूंगा कि यह भी संभव है, लेकिन वास्तविकता में शायद ही कभी होता है (आगे देखते हुए - यह होने की जगह होनी चाहिए - लेकिन इसके बजाय एक लाभ के रूप में)।

उत्पाद जीवन चक्र और सेवा जीवन चक्र

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

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

जटिलता से निपटने के लिए एक उपकरण के रूप में माइक्रोसॉफ़्ट ... कॉन्फ़िगरेशन प्रबंधन

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

जाँच - परिणाम

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