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

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



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

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

परिचय

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

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



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

मैं कुबेरनेट्स के उपयोग के मामले के लिए इस ग्राफ को पूरक करूंगा:



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

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

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

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



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



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



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

क्यों माइक्रोसिस्टम्स?

माइक्रोसर्विस के लाभों के बारे में सवाल करने के लिए, पहले से ही वर्णित मार्टिन फाउलर का एक बहुत ही विशिष्ट उत्तर है :

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

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



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

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

विशिष्ट (हानिकारक) माइक्रोसिस्टवर्क वास्तुकला

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

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



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



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

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

Fowler इस विषय पर एक लेख है - microservices का उपयोग करने के लिए "पेबैक" के बारे में:



और हम देखेंगे कि हमारी अपेक्षाएँ पूरी होती हैं या नहीं।

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

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

" कीचड़ का एक बड़ा गांठ " पैटर्न है, लेकिन यहां हमें कीचड़ की वितरित गांठ मिलती है। इसके समर्थन में, यहां एक उदाहरण दिया गया है कि प्रश्न कैसे चलते हैं:

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

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

प्रौद्योगिकी का चयन करने की स्वतंत्रता ...

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

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

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

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

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

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

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

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

भार की माप्यता ...

इसके साथ सब कुछ वास्तव में अच्छा है।

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

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

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

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

क्योंकि:

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

इस सबका क्या करना है?

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

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

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

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

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

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

सबसे संदिग्ध microservices से छुटकारा पाएं:



दृश्यपटल उत्पन्न करने के लिए जिम्मेदार सभी माइक्रोसर्विसेज को मिलाएं:



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



इसमें एक ओआरएम (एक डीबीएमएस) और पहले एक दो आवेदन होंगे:



... सामान्य में, बहुत अधिक वहाँ स्थानांतरित किया जा सकता है, निम्नलिखित परिणाम प्राप्त:



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

सारांश

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

शब्द "माइक्रोसेर्विस" में "सूक्ष्म" भाग बहुत अधिक है । वे "सूक्ष्म" केवल इस कारण से हैं कि वे एक विशाल मोनोलिथ से छोटे हैं। लेकिन उन्हें कुछ छोटा न समझें।

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



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

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

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



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

पुनश्च

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

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

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

• " 2018 में माइक्रोसॉफ़्ट मैडनेस की मृत्यु ";
• " Google के अनुसार कंटेनरों के संचालन के लिए 7 सर्वोत्तम अभ्यास ";
• " Kubernetes कार्यान्वयन कठिनाइयों पर नई स्टैक सांख्यिकी ।"