माइक्रोसर्विसेज: वे क्या हैं, वे क्यों हैं और उन्हें कब लागू करना है

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

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

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

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

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

सूचना प्रणाली का व्यावसायिक अभिविन्यास

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

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

आगे बढ़ने से पहले, आइए माइक्रोसर्विस आर्किटेक्चर के बारे में कुछ गलतफहमियों पर नजर डालें।

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

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

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

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

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

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

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

निष्कर्ष

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

स्रोत: www.habr.com