मायक्रोसर्व्हिसेस: ते काय आहेत, ते का आहेत आणि ते कधी लागू करायचे

मला मायक्रोसर्व्हिस आर्किटेक्चर या विषयावर बराच काळ एक लेख लिहायचा होता, परंतु दोन गोष्टी मला थांबवत होत्या - मी या विषयात जितके पुढे जाऊ लागलो, तितकेच मला असे वाटू लागले की मला जे माहित आहे ते स्पष्ट आहे आणि मला काय माहित नाही. t माहित असणे आणि अभ्यास करणे आवश्यक आहे. दुसरीकडे, मला वाटते की मोठ्या प्रेक्षकांमध्ये चर्चा करण्यासाठी आधीपासूनच काहीतरी आहे. त्यामुळे पर्यायी मतांचे स्वागत आहे.

कॉनवेचा कायदा आणि व्यवसाय, संस्था आणि माहिती प्रणाली यांच्यातील संबंध

पुन्हा एकदा मी स्वतःला उद्धृत करण्याची परवानगी देईन:

"कोणतीही संस्था जी प्रणाली (व्यापक अर्थाने) डिझाइन करते तिला एक डिझाइन प्राप्त होईल ज्याची रचना त्या संस्थेतील संघांच्या संरचनेची प्रतिकृती बनवते."
- मेलव्हिन कॉनवे, 1967

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

माहिती प्रणालीचे व्यवसाय अभिमुखता

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

सर्व काही वाहते, सर्व काही बदलते किंवा मायक्रोसर्व्हिसेस हे गुंतागुंतीचा सामना करण्याचे साधन आहे?

आपण पुढे जाण्यापूर्वी, मायक्रोसर्व्हिस आर्किटेक्चरबद्दल काही गैरसमज पाहू.

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

विषम स्टॅक वापरण्याचा फायदा देखील संशयास्पद आहे. मी असा युक्तिवाद करणार नाही की हे देखील शक्य आहे, परंतु प्रत्यक्षात ते क्वचितच घडते (पुढे पाहता - हे घडले पाहिजे - परंतु फायद्यापेक्षा परिणाम म्हणून).

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

वरील आकृतीवर आणखी एक नजर टाका. हा योगायोग नाही की मी व्यवसायाच्या वेगळ्या आवृत्तीचे घटते जीवन चक्र लक्षात घेतले आहे - आधुनिक परिस्थितीत, व्यवसायाच्या आवृत्त्यांमधील संक्रमणाचा वेग हा त्याच्या यशासाठी निर्णायक आहे. उत्पादनाचे यश त्यामधील व्यावसायिक गृहितकांच्या चाचणीच्या गतीने निर्धारित केले जाते. आणि इथे, माझ्या मते, मायक्रोसर्व्हिस आर्किटेक्चरचा मुख्य फायदा आहे. पण क्रमाने जाऊया.

चला माहिती प्रणालीच्या उत्क्रांतीच्या पुढील टप्प्यावर - SOA च्या सेवा-देणारं आर्किटेक्चरकडे जाऊया. तर, काही विशिष्ट टप्प्यावर आम्ही आमच्या उत्पादनामध्ये हायलाइट केले दीर्घकालीन सेवा - दीर्घायुषी या अर्थाने की उत्पादनाच्या आवृत्त्यांमध्ये फिरताना, सेवेचे जीवनचक्र उत्पादनाच्या पुढील आवृत्तीच्या जीवन चक्रापेक्षा मोठे असण्याची शक्यता असते. त्यांना अजिबात न बदलणे तर्कसंगत असेल - आम्ही पुढील आवृत्तीत संक्रमणाचा वेग महत्त्वाचा आहे. पण अरेरे, आम्हाला सेवांमध्ये सतत बदल करण्यास भाग पाडले जाते - आणि येथे सर्वकाही आमच्यासाठी कार्य करते, DevOps पद्धती, कंटेनरायझेशन आणि असेच - जे काही मनात येते. पण या अजूनही मायक्रोसर्व्हिसेस नाहीत!

गुंतागुंतीचा सामना करण्यासाठी मायक्रोसर्व्हिसेस... कॉन्फिगरेशन व्यवस्थापन

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

निष्कर्ष

• प्रणालीचे आर्किटेक्चर त्याच्या घटकांच्या जीवन चक्राद्वारे निर्धारित केले पाहिजे. एखादा घटक उत्पादन आवृत्तीमध्ये राहत असल्यास, मायक्रोसर्व्हिस दृष्टिकोन वापरून सिस्टमची जटिलता वाढविण्यात काही अर्थ नाही.
• मायक्रोसर्व्हिस आर्किटेक्चर डोमेन मॉडेलवर आधारित असावे - कारण व्यवसायाची संधी सर्वात जास्त काळ टिकणारी डोमेन आहे
• डिलिव्हरी पद्धती (DevOps सराव) आणि ऑर्केस्ट्रेशन हे मायक्रोसर्व्हिस आर्किटेक्चरसाठी सर्वात महत्वाचे आहेत - कारण घटक बदलण्याच्या दरात वाढ झाल्यामुळे वितरणाचा वेग आणि गुणवत्तेवर मागणी वाढते.

स्त्रोत: www.habr.com