Microservices: तिनीहरू के हुन्, तिनीहरू किन हुन् र तिनीहरूलाई कहिले लागू गर्ने

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

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

फेरि एक पटक म आफैलाई उद्धृत गर्न अनुमति दिनेछु:

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

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

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

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

सबै कुरा प्रवाह हुन्छ, सबै परिवर्तन हुन्छ, वा माइक्रोसर्भिसेसहरू जटिलतासँग लड्ने माध्यम हो?

हामीले जारी राख्नु अघि, माइक्रोसर्भिस आर्किटेक्चरको बारेमा केही गलत धारणाहरू हेरौं।

माइक्रोसर्भिस दृष्टिकोण प्रयोग गर्ने समर्थकहरूले प्रायः तर्क गर्छन् कि माइक्रोसर्भिसेसमा मोनोलिथ तोड्दा व्यक्तिगत सेवाहरूको कोड आधार घटाएर विकास दृष्टिकोणलाई सरल बनाउँछ। मेरो विचारमा, यो कथन पूर्ण बकवास हो। गम्भीरतापूर्वक, एक मोनोलिथ र एकसमान कोड भित्र स्पष्ट अन्तरक्रिया जटिल देखिन्छ? यदि यो साँच्चै मामला हो भने, सबै परियोजनाहरू सुरुमा माइक्रोसर्भिसेसको रूपमा बनाइनेछन्, जबकि अभ्यासले देखाउँछ कि मोनोलिथबाट माइक्रोसर्भिसेसमा माइग्रेसन धेरै सामान्य छ। जटिलता हराउँदैन; यो केवल व्यक्तिगत मोड्युलहरूबाट इन्टरफेसमा सर्छ (यो डाटा बसहरू, RPC, API, र अन्य प्रोटोकलहरू) र अर्केस्ट्रेटिंग प्रणालीहरू हुन्। र यो गाह्रो छ!

विषम स्ट्याक प्रयोग गर्ने फाइदा पनि शंकास्पद छ। म तर्क गर्दिन कि यो पनि सम्भव छ, तर वास्तविकतामा यो विरलै हुन्छ (अगाडि हेर्दै - यो हुनुपर्दछ - तर फाइदा भन्दा नतिजाको रूपमा)।

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

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

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

जटिलतासँग लड्ने माध्यमको रूपमा माइक्रोसर्भिसेस... कन्फिगरेसन व्यवस्थापन

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

निष्कर्ष

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

स्रोत: www.habr.com