माइक्रोसर्विसेज: आकार मायने रखता है, भले ही आपके पास कुबेरनेट्स हो

19 सितम्बर मास्को में जगह ले ली पहली विषयगत बैठक HUG (हाईलोड++ यूजर ग्रुप), जो माइक्रोसर्विसेज को समर्पित थी। एक प्रस्तुति थी "ऑपरेटिंग माइक्रोसर्विसेज: आकार मायने रखता है, भले ही आपके पास कुबेरनेट्स हो," जिसमें हमने माइक्रोसर्विस आर्किटेक्चर के साथ परियोजनाओं के संचालन में फ़्लैंट के व्यापक अनुभव को साझा किया। सबसे पहले, यह उन सभी डेवलपर्स के लिए उपयोगी होगा जो अपने वर्तमान या भविष्य के प्रोजेक्ट में इस दृष्टिकोण का उपयोग करने के बारे में सोच रहे हैं।

परिचय रिपोर्ट का वीडियो (50 मिनट, लेख से कहीं अधिक जानकारीपूर्ण), साथ ही पाठ के रूप में इसका मुख्य अंश।

ध्यान दें: इस पोस्ट के अंत में वीडियो और प्रेजेंटेशन भी उपलब्ध हैं।

परिचय

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

मैं इस ग्राफ़ से शुरुआत करूंगा, जिसके लेखक (2015 में) था मार्टिन फाउलर:

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

कुबेरनेट्स का उपयोग करने के मामले में मैं इस ग्राफ़ में जोड़ूँगा:

माइक्रोसर्विसेज़ वाला एप्लिकेशन बेहतर क्यों है? क्योंकि इस तरह की वास्तुकला वास्तुकला के लिए गंभीर आवश्यकताओं को सामने रखती है, जो बदले में कुबेरनेट्स की क्षमताओं द्वारा पूरी तरह से कवर की जाती है। दूसरी ओर, इनमें से कुछ कार्यक्षमता एक मोनोलिथ के लिए उपयोगी होगी, विशेष रूप से क्योंकि आज का विशिष्ट मोनोलिथ वास्तव में एक मोनोलिथ नहीं है (विवरण बाद में रिपोर्ट में होगा)।

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

उपयोगी और हानिकारक माइक्रोसर्विसेज

और यहाँ मुख्य विचार है:

क्या है साधारण माइक्रोसर्विस आर्किटेक्चर? इससे आपको वास्तविक लाभ मिलना चाहिए, जिससे आपकी कार्यकुशलता बढ़ेगी। यदि हम ग्राफ़ पर वापस जाएँ, तो यह यहाँ है:

यदि आप उसे कॉल करते हैं उपयोगी, तो ग्राफ़ के दूसरी तरफ होगा हानिकारक माइक्रोसर्विसेज (काम में हस्तक्षेप):

"मुख्य विचार" पर लौटते हुए: क्या मुझे अपने अनुभव पर बिल्कुल भी भरोसा करना चाहिए? इस वर्ष की शुरुआत से ही मैं देख रहा हूं 85 प्रोजेक्ट. उनमें से सभी माइक्रोसर्विसेज नहीं थे (उनमें से लगभग एक तिहाई से आधे के पास ऐसी वास्तुकला थी), लेकिन यह अभी भी एक बड़ी संख्या है। हम (फ़्लैंट कंपनी) आउटसोर्सर के रूप में छोटी कंपनियों (5 डेवलपर्स के साथ) और बड़ी कंपनियों (~500 डेवलपर्स) दोनों में विकसित विभिन्न प्रकार के अनुप्रयोगों को देखने का प्रबंधन करते हैं। एक अतिरिक्त लाभ यह है कि हम इन अनुप्रयोगों को वर्षों तक जीवित और विकसित होते देखते हैं।

माइक्रोसर्विसेज क्यों?

माइक्रोसर्विसेज के लाभों के बारे में प्रश्न वहाँ है बहुत विशिष्ट उत्तर पहले से उल्लेखित मार्टिन फाउलर से:

1. प्रतिरूपकता की स्पष्ट सीमाएँ;
2. स्वतंत्र तैनाती;
3. प्रौद्योगिकियों को चुनने की स्वतंत्रता।

मैंने सॉफ्टवेयर आर्किटेक्ट और डेवलपर्स से बहुत बात की है और पूछा है कि उन्हें माइक्रोसर्विसेज की आवश्यकता क्यों है। और मैंने उनकी अपेक्षाओं की अपनी सूची बनाई। यहाँ क्या हुआ:

यदि हम "संवेदनाओं में" कुछ बिंदुओं का वर्णन करें, तो:

• मॉड्यूल की स्पष्ट सीमाएँ: यहाँ हमारे पास एक भयानक मोनोलिथ है, और अब सब कुछ Git रिपॉजिटरी में बड़े करीने से व्यवस्थित किया जाएगा, जिसमें सब कुछ "अलमारियों पर" है, गर्म और नरम मिश्रित नहीं हैं;
• तैनाती की स्वतंत्रता: हम सेवाओं को स्वतंत्र रूप से शुरू करने में सक्षम होंगे ताकि विकास तेजी से हो (समानांतर में नई सुविधाएँ प्रकाशित करें);
• विकास की स्वतंत्रता: हम यह माइक्रोसर्विस एक टीम/डेवलपर को दे सकते हैं, और वह एक दूसरे को, जिसकी बदौलत हम तेजी से विकास कर सकते हैं;
• боअधिक विश्वसनीयता: यदि आंशिक गिरावट होती है (20 में से एक माइक्रोसर्विस गिर जाती है), तो केवल एक बटन काम करना बंद कर देगा, और संपूर्ण सिस्टम कार्य करना जारी रखेगा।

विशिष्ट (हानिकारक) माइक्रोसर्विस आर्किटेक्चर

यह समझाने के लिए कि वास्तविकता वह क्यों नहीं है जिसकी हम अपेक्षा करते हैं, मैं प्रस्तुत करूँगा सामूहिक कई अलग-अलग परियोजनाओं के अनुभव के आधार पर माइक्रोसर्विस आर्किटेक्चर की एक छवि।

एक उदाहरण एक अमूर्त ऑनलाइन स्टोर होगा जो अमेज़ॅन या कम से कम ओज़ोन के साथ प्रतिस्पर्धा करने जा रहा है। इसका माइक्रोसर्विस आर्किटेक्चर इस तरह दिखता है:

कारणों के संयोजन से, ये माइक्रोसर्विसेज विभिन्न प्लेटफार्मों पर लिखे गए हैं:

चूँकि प्रत्येक माइक्रोसर्विस के पास स्वायत्तता होनी चाहिए, उनमें से कई को अपने स्वयं के डेटाबेस और कैश की आवश्यकता होती है। अंतिम वास्तुकला इस प्रकार है:

इसके परिणाम क्या हैं?

फाउलर के पास भी यह है एक लेख है - माइक्रोसर्विसेज का उपयोग करने के लिए "भुगतान" के बारे में:

और हम देखेंगे कि क्या हमारी अपेक्षाएँ पूरी हुईं।

मॉड्यूल की स्पष्ट सीमाएँ...

लेकिन हमें वास्तव में कितनी माइक्रोसर्विसेज़ को ठीक करने की आवश्यकता है?परिवर्तन लागू करने के लिए? क्या हम यह भी पता लगा सकते हैं कि वितरित ट्रेसर के बिना सब कुछ कैसे काम करता है (आखिरकार, किसी भी अनुरोध को आधे माइक्रोसर्विसेज द्वारा संसाधित किया जाता है)?

एक पैटर्न है"गंदगी का बड़ा ढेर“, और यहाँ यह गंदगी का एक वितरित ढेला निकला। इसकी पुष्टि करने के लिए, यहां एक अनुमानित उदाहरण दिया गया है कि अनुरोध कैसे आते हैं:

तैनाती स्वतंत्रता...

तकनीकी रूप से, यह हासिल कर लिया गया है: हम प्रत्येक माइक्रोसर्विस को अलग से रोल आउट कर सकते हैं। लेकिन व्यवहार में आपको यह ध्यान रखना होगा कि यह हमेशा लागू रहता है कई माइक्रोसर्विसेज, और हमें इसे ध्यान में रखना होगा उनके रोलआउट का क्रम. एक अच्छे तरीके से, हमें आम तौर पर एक अलग सर्किट में परीक्षण करने की आवश्यकता होती है कि क्या हम रिलीज को सही क्रम में रोल आउट कर रहे हैं।

तकनीक चुनने की आजादी...

वह है। बस याद रखें कि स्वतंत्रता अक्सर अराजकता पर सीमाबद्ध होती है। यहां यह बहुत महत्वपूर्ण है कि प्रौद्योगिकियों को केवल उनके साथ "खेलने" के लिए न चुना जाए।

विकास की स्वतंत्रता...

संपूर्ण एप्लिकेशन (इतने सारे घटकों के साथ) के लिए टेस्ट लूप कैसे बनाएं? लेकिन आपको अभी भी इसे अद्यतित रखना होगा। यह सब इस तथ्य की ओर ले जाता है कि परीक्षण सर्किट की वास्तविक संख्या, जिसे हम सैद्धांतिक रूप से शामिल कर सकते हैं, न्यूनतम हो जाता है.

यह सब स्थानीय स्तर पर तैनात करने के बारे में क्या ख्याल है?.. यह पता चला है कि अक्सर डेवलपर अपना काम स्वतंत्र रूप से करता है, लेकिन "यादृच्छिक रूप से", क्योंकि उसे तब तक इंतजार करने के लिए मजबूर किया जाता है जब तक कि सर्किट परीक्षण के लिए मुक्त न हो जाए।

अलग स्केलिंग...

हाँ, लेकिन यह प्रयुक्त DBMS के क्षेत्र में सीमित है। दिए गए आर्किटेक्चर उदाहरण में, कैसेंड्रा को समस्या नहीं होगी, लेकिन MySQL और PostgreSQL को होगी।

Боअधिक विश्वसनीयता...

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

लोड मापनीयता...

यह सचमुच अच्छा है।

माइक्रोसर्विसेज की "हल्कापन"...

हमारे पास न केवल विशाल है नेटवर्क ओवरहेड (डीएनएस के लिए अनुरोध बढ़ रहे हैं, आदि), लेकिन हमारे द्वारा शुरू की गई कई सबक्वेरीज़ के कारण भी डेटा को दोहराएँ (स्टोर कैश), जिसके कारण महत्वपूर्ण मात्रा में भंडारण हुआ।

और यहाँ हमारी अपेक्षाओं को पूरा करने का परिणाम है:

लेकिन वह सब नहीं है!

क्योंकि:

• सबसे अधिक संभावना है कि हमें एक संदेश बस की आवश्यकता होगी।
• सही समय पर लगातार बैकअप कैसे बनाएं? एकमात्र реальный इसके लिए ट्रैफिक बंद करने का विकल्प है। लेकिन उत्पादन में यह कैसे करें?
• यदि हम कई क्षेत्रों के समर्थन के बारे में बात कर रहे हैं, तो उनमें से प्रत्येक में स्थिरता का आयोजन करना एक बहुत ही श्रम-गहन कार्य है।
• केंद्रीकृत परिवर्तन करने की समस्या उत्पन्न होती है। उदाहरण के लिए, यदि हमें PHP संस्करण को अपडेट करने की आवश्यकता है, तो हमें प्रत्येक रिपॉजिटरी के लिए प्रतिबद्ध होना होगा (और उनमें से दर्जनों हैं)।
• परिचालन जटिलता में वृद्धि, अप्रत्याशित, घातीय है।

इन सबका क्या करें?

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

एक और मूल्यवान विचार यह है कि माइक्रोसर्विस आर्किटेक्चर वाले प्रोजेक्ट के सफल होने के लिए, आपको अच्छी तरह से जानना चाहिए और विषय क्षेत्र, और माइक्रोसर्विसेज कैसे बनाएं. और किसी विषय क्षेत्र को सीखने का सबसे अच्छा तरीका एक मोनोलिथ बनाना है।

लेकिन क्या होगा अगर हम पहले से ही इस स्थिति में हैं?

किसी भी समस्या को हल करने के लिए पहला कदम उससे सहमत होना और यह समझना है कि यह एक समस्या है, जिसे हम अब और नहीं सहना चाहते।

यदि, एक अतिवृष्टि वाले मोनोलिथ के मामले में (जब हमारे पास इसके लिए अतिरिक्त संसाधन खरीदने का अवसर समाप्त हो गया है), हम इसे काट देते हैं, तो इस मामले में विपरीत कहानी सामने आती है: जब अत्यधिक माइक्रोसर्विसेज अब मदद नहीं करते हैं, बल्कि बाधा डालते हैं - अतिरिक्त काटें और बड़ा करें!

उदाहरण के लिए, ऊपर चर्चा की गई सामूहिक छवि के लिए...

सबसे संदिग्ध माइक्रोसर्विसेज से छुटकारा पाएं:

फ्रंटएंड जेनरेशन के लिए जिम्मेदार सभी माइक्रोसर्विसेज को मिलाएं:

... एक माइक्रोसर्विस में, एक (आधुनिक और सामान्य, जैसा कि आप स्वयं सोचते हैं) भाषा/ढांचे में लिखा गया है:

इसमें एक ORM (एक DBMS) और पहले कुछ एप्लिकेशन होंगे:

... लेकिन सामान्य तौर पर आप वहां बहुत कुछ स्थानांतरित कर सकते हैं, जिससे निम्नलिखित परिणाम प्राप्त होंगे:

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

सारांश

बड़ी तस्वीर देखिए. बहुत बार, माइक्रोसर्विसेज के साथ ये सभी समस्याएं उत्पन्न होती हैं क्योंकि किसी ने उनका कार्य ले लिया, लेकिन "माइक्रोसर्विसेज के साथ खेलना" चाहता था।

"माइक्रोसर्विसेज" शब्द में "माइक्रो" भाग अनावश्यक है।. वे केवल इसलिए "सूक्ष्म" हैं क्योंकि वे एक विशाल मोनोलिथ से छोटे हैं। लेकिन इन्हें कोई छोटी चीज़ मत समझिए.

और अंतिम विचार के लिए, आइए मूल चार्ट पर वापस जाएँ:

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

वीडियो और स्लाइड

भाषण का वीडियो (~50 मिनट; दुर्भाग्य से, यह आगंतुकों की असंख्य भावनाओं को व्यक्त नहीं करता है, जो काफी हद तक रिपोर्ट के मूड को निर्धारित करता है, लेकिन यह इस प्रकार है):

रिपोर्ट की प्रस्तुति:

पुनश्च

हमारे ब्लॉग पर अन्य रिपोर्ट:

• «निगरानी और कुबेरनेट्स» (दिमित्री स्टोलारोव; 28 मई, 2018 रूटकॉन्फ पर);
• «कुबेरनेट्स और गिटलैब के साथ सीआई/सीडी सर्वोत्तम अभ्यास» (दिमित्री स्टोलारोव; 7 नवंबर, 2017 हाईलोड++ पर);
• «छोटी परियोजनाओं में कुबेरनेट्स के साथ हमारा अनुभव» (दिमित्री स्टोलारोव; 6 जून, 2017 रूटकॉन्फ पर);
• «हम एक डैप के साथ सीआई/सीडी के लिए जल्दी और आसानी से डॉकर छवियां बनाते हैं» (दिमित्री स्टोलारोव; 8 नवंबर, 2016 हाईलोड++ पर);
• «डॉकर के साथ सतत वितरण अभ्यास» (दिमित्री स्टोलारोव; 31 मई, 2016 रूटकॉन्फ पर).

आपको निम्नलिखित प्रकाशनों में भी रुचि हो सकती है:

• «2018 में माइक्रोसर्विस पागलपन की मौत";
• «Google के अनुसार कंटेनरों का उपयोग करने की 7 सर्वोत्तम प्रथाएँ";
• «कुबेरनेट्स को लागू करने की चुनौतियों पर द न्यू स्टैक के आँकड़े'.

स्रोत: www.habr.com