माइक्रोसर्विस से डरो मत: अभ्यास में माइक्रोसैस आर्किटेक्चर के उपयोग पर एलेक्सी बैतोव

कुछ के लिए, microservices अपेक्षाकृत आधुनिक शैली के लिए एक आवेदन को फिर से बनाने और पुन: सक्रिय करने की क्षमता है। यह वास्तु समाधान आवेदन के विभिन्न हिस्सों की बातचीत की ख़ासियत के कारण दूसरों के लिए उपयुक्त नहीं है। किसी भी मामले में, एक वास्तुकला को चुनना, एक मोनोलिथ से सेवाओं के एक सेट में संक्रमण से दूसरों के अनुभव का अध्ययन करना उपयोगी है।

हमने 2 जीआईएस के प्रमुख अभियंता अलेक्सी बैतोव के विकास और वितरण के हमारे मामले के अध्ययन को साझा करने के लिए कहा। आइए वास्तु समाधान, तैनाती और मापनीयता के बारे में बात करते हैं। काम के लिए ट्रेंडिंग और सिर्फ सुविधाजनक टूल के बारे में पूछें।



- अलेक्सी, कृपया हमें अपने बारे में और अपनी टीम के बारे में 2GIS में थोड़ा बताएं। आप अभी क्या काम कर रहे हैं?

मैं एक सिस्टम एडमिनिस्ट्रेटर के रूप में 2003 में वापस आया, मैंने 2011 में विकास में कदम रखा। इस समय के दौरान, उन्होंने PHP, जावास्क्रिप्ट में काम किया, गिट के लिए रेस्टफुल सेवाओं और पायथन ड्राइवर की एक श्रृंखला को लागू किया। मैं 2015 से 2GIS में काम कर रहा हूं।

उन्होंने दो microservice आर्किटेक्चर के विकास में भाग लिया। पहले में एक सेवा शामिल थी। यह कैश के साथ एक अतुल्यकालिक रिवर्स प्रॉक्सी था। वास्तव में, वह संदेश भेजने में लगा हुआ था। मैं केवल उन आवश्यकताओं को पूरा करने में शामिल था, जो DevOps को विकसित और विकसित कर रही थीं, लेकिन हमारी 2GIS कंपनी के विशेषज्ञों ने मेरी मदद की।

सेवा गो में लिखी गई थी। त्वरित संकलन ने मुझे प्रतीक्षा नहीं करने की अनुमति दी, और मैं निरंतर तैनाती पर ध्यान केंद्रित करने में सक्षम था। तब हम सिर्फ GitLab CI , Prometheus , Grafana और Deis ( Heroku का खुला स्रोत एनालॉग) का उपयोग करना शुरू कर रहे थे। हमारे पास इन्फ्रास्ट्रक्चर और ऑपरेशंस की एक टीम है, जिसने मेरे विकास के समय इन सभी बुनियादी ढांचे के समाधानों को उत्पादन के स्तर पर लाया। मैंने यह सब करने की कोशिश करने का फैसला किया और सफलतापूर्वक एक स्वतंत्र माइक्रोसेवा लागू किया।

दो साल पहले, मैं एक नई परियोजना पर दूसरी टीम में गया, जहाँ मैंने स्काला में कार्यात्मक प्रोग्रामिंग में संलग्न होना शुरू किया। स्क्रैच से हमारी टीम ने स्काला, सी # और जावास्क्रिप्ट में 2 जीआईएस विज्ञापन सामग्री के भंडारण के लिए एक माइक्रोसैस आर्किटेक्चर विकसित किया है। मैंने DevOps प्रथाओं (सतत तैनाती और रखरखाव) के निर्माण के लिए प्राप्त उपकरणों और अनुभव के साथ सभी सेवाओं की नींव रखी। आर्किटेक्चर प्रोटोटाइप से औद्योगिक संचालन के लिए चला गया है। उसने दो मोनोलिथ को अवशोषित किया, जिसमें अब 15 सेवाएं शामिल हैं और लगातार विस्तार हो रहा है।

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

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

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

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

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

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

डेवलपर और ग्राहक के बीच सीधे संपर्क के माध्यम से ग्राहक पर ध्यान केंद्रित किया जाता है। डेवलपर्स को यह देखने की आवश्यकता है कि उनके उत्पाद का उपयोग कैसे किया जाता है। इससे, तकनीकी क्षेत्र में ज्ञान की इच्छा, उत्पाद को ग्राहक तक पहुंचाने की क्षमता और उत्पाद का जल्द से जल्द पालन करना।

टीम के आकार के बारे में कहना मुश्किल है हर कोई शायद अमेज़ॅन के संस्थापक जेफ बेजोस के बयान को जानता है, कि सेवा उन्मुख विकास में टीम का आकार इतना छोटा होना चाहिए कि हर किसी को दो पिज्जा खिलाया जा सके। हैबे की टिप्पणियों में, इस विषय पर चर्चा हुई, और उन्होंने लिखा कि एक व्यक्ति के पास पर्याप्त एक पिज्जा नहीं हो सकता है और इसलिए एक टीम में एक या दो लोग शामिल होने चाहिए। मार्टिन फावलर ने दो पिज्जा के बारे में एक बयान को उद्धृत करते हुए कहा कि यह बड़े अमेरिकी पिज्जा के बारे में था, जिसके बाद उन्होंने निर्दिष्ट किया कि टीम में 50 नहीं, बल्कि लगभग 12 लोग होने चाहिए। मेरा मानना ​​है कि यह सब उत्पाद मॉडल पर निर्भर करता है। लेकिन "12 से अधिक लोगों को नहीं" के बारे में फाउलर का स्पष्टीकरण अब तक मेरे अभ्यास में जीता है। मैंने देखा कि टीम के भीतर, समान विचारधारा वाले लोगों को खोजने के लिए तकनीकी हितों के अनुसार विभाजित करना वांछनीय है।

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

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



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

मुझे बताओ, क्या आप खरोंच से विकास के प्रस्तावक हैं या क्या ऐसी परिस्थितियां हो सकती हैं जब यह एक मोनोलिथ से क्रमिक निष्कर्ष बनाने के लायक है? निकास रणनीति का निर्धारण कैसे करें?

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

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

माइक्रोसर्विस आर्किटेक्चर के लिए हमारा रास्ता सीधा नहीं था। पहले तो एक मठ था। उन्होंने पाठ्य विज्ञापन सामग्री को संसाधित किया। साढ़े तीन साल पहले, हमें ग्राफिक विज्ञापन सामग्री (चित्र, लोगो) के साथ काम करने की आवश्यकता थी। पाठ विज्ञापन सामग्री के साथ काम करते समय क्या कमी थी, इसे व्यावसायिक तर्क में शामिल करने की इच्छा थी।

एक नए व्यापार मॉडल का परीक्षण करने के लिए, हमने ग्राफिक विज्ञापन सामग्रियों के साथ एक और प्रौद्योगिकी स्टैक पर दूसरे मोनोलिथ के रूप में काम किया। ऑपरेशन के डेढ़ साल बाद, हमने महसूस किया कि यह दृष्टिकोण सही था।

इस समय के दौरान, हमने बहुत सारी विशलिस्ट प्राप्त की, व्यापार तर्क की खुरदरापन को प्रकट किया।

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

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

बहुत नए बिजनेस मॉडल के साथ काम करने के लिए, स्काला और पोस्टग्रेक्यूएल डेटाबेस को इस बार चुना गया था। स्काला हमारी तकनीकी आवश्यकताओं को पूरा करती है। इसके अलावा, स्काला डेवलपर्स सी # डेवलपर्स के समान मंजिल पर स्थित थे। इससे टीम के संचार का समय कम हो गया। कॉनवे के कानून ने काम किया - कंपनी की संरचना ने आवेदन की संरचना तय की। PHP डेवलपर ने एक Scala डेवलपर में पुनर्विकास किया है। मैंने बस एक पूर्ण सीआई / सीडी चक्र के साथ गोलंग पर एक स्वतंत्र माइक्रोसिस्ट सेवा पर काम पूरा किया, जिसके बाद मैं टीम में शामिल हो गया और स्कैला डेवलपर भी बन गया।

यह दिलचस्प है कि मैंने वास्तव में स्काला व्यापार तर्क के साथ काम करने के लिए क्या उपयोग करने का प्रस्ताव दिया, और सी # नहीं। तथ्य यह है कि हमारे पास पर्याप्त सी # डेवलपर्स नहीं थे। PHP-shnik और मैं स्काला के लिए पीछे हटना चाहते थे। इसके अलावा, हमारे पास एक अनुभवी स्काला डेवलपर को आकर्षित करने का अवसर था। एक और बिंदु: यदि हमने C # में सब कुछ लागू किया है, तो हम आउटपुट पर एक माइक्रोसेस्क आर्किटेक्चर या एक अन्य मोनोलिथ प्राप्त कर सकते हैं। स्काला और सी # में विभाजन, विभिन्न भंडारण आवश्यकताओं और आवश्यक क्षेत्रों में से प्रत्येक में अनुभवी डेवलपर्स की उपलब्धता - यह सब सीधे microservice वास्तुकला की ओर इशारा करता है। और हम केवल इससे लाभान्वित हुए। एक साल पहले, ग्राफिक और पाठ्य सामग्री के साथ काम करने के लिए माइक्रोसॉर्फ़ आर्किटेक्चर वाणिज्यिक संचालन में चला गया और आज तक सफलतापूर्वक संचालित हो रहा है।

इस सवाल के लिए कि क्या खरोंच से एक माइक्रोसर्विस आर्किटेक्चर बनाना संभव है। डेढ़ साल पहले, माइक्रोसैस आर्किटेक्चर पर काम करने की प्रक्रिया में, हम अपने उत्पादों - वीडियो विज्ञापन सामग्री में एक नई दिशा का समर्थन करने की मांग के साथ आए थे। नए बिक्री मॉडल को जल्दी से परीक्षण करना आवश्यक था। हमारी वास्तुकला अपनी प्रारंभिक अवस्था में थी। वीडियो सामग्री के साथ काम करना प्रौद्योगिकी के एक नए क्षेत्र को कवर करता है। हमने विकास वेक्टर में बदलाव नहीं करने का फैसला किया और वीडियो सामग्री के लिए MVP को C # में एक स्टैंड-अलोन माइक्रोसैस आर्किटेक्चर के रूप में लागू किया और वीडियो होस्टिंग पर भरोसा किया। यह एक सफल अनुभव है, और हमारे पास इस विषय पर एक रिपोर्ट है । इस प्रकार, हमारे पास दो समानांतर मौजूदा माइक्रोसर्विस आर्किटेक्चर हैं। एमवीपी बहुत विकसित नहीं हुआ, विशलिस्ट भी इस पर जमा हुआ है, और जल्द ही हम सब कुछ एक एकल माइक्रोसॉर्स्क वास्तुकला के ढांचे के भीतर जोड़ देंगे - हमें विज्ञापन पाठ, ग्राफिक और वीडियो सामग्री का एक एकल भंडार मिलेगा।

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

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

माइक्रोसैस आर्किटेक्चर का मुख्य नुकसान: यह बहुत अधिक जटिल है, और इसका कार्यान्वयन अधिक महंगा है।

आपको सेवा अनुबंधों का समर्थन करने के लिए तैयार रहने, सही रिमोट एक्सेस प्रोटोकॉल का चयन करने, सुरक्षित चौराहे की बातचीत के मुद्दों को हल करने, संभावित विफलताओं के साथ-साथ डिडुप्लिकेट और वितरित लेनदेन का प्रबंधन करने की भी आवश्यकता है।

सामान्य तौर पर, सार्वजनिक डोमेन में आप इसके साथ काम करने के तरीके के बारे में बहुत सारी जानकारी और सामग्री पा सकते हैं। लेकिन वास्तव में यह सब कार्य पर निर्भर करता है। मेरे अभ्यास में, से अधिक हमेशा minuses की तुलना में अधिक महत्वपूर्ण रहे हैं।

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

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

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

- माइक्रोसर्विस की निरंतर तैनाती और स्थानांतरण को ठेस पहुंचाना कितना आसान है?

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

यदि सक्रिय विकास में एक माइक्रोसैस आर्किटेक्चर में एक बार में 10 या अधिक सेवाएं हैं और प्रत्येक की अपनी स्वयं की संस्करण है, तो संस्करण संगतता की समस्या है। हमें विभिन्न संस्करणों की सेवाओं की संगतता में भ्रमित नहीं होने की कोशिश करनी चाहिए।

निरंतर तैनाती का मतलब है कि हम किसी भी समय किसी भी वातावरण में आवेदन वितरित कर सकते हैं।

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

यह सब कहीं न कहीं संग्रहीत करने की आवश्यकता है, कई स्थानों में परिवर्तन को सही करने के लिए (microservices सब के बाद स्वतंत्र हैं) और भ्रमित होने के लिए नहीं।

निरंतर तैनाती का मतलब किसी भी समय किसी भी संस्करण में वापस रोल करने की क्षमता है। तदनुसार, यह हो सकता है कि आपको एक बार में कई सेवाओं को वापस करने की आवश्यकता हो और आपको सेवा तैनाती के सही रिवर्स ऑर्डर का पालन करना होगा।

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

- माइक्रोसर्विस की निरंतर तैनाती के लिए उपकरणों का प्रारंभिक सेट क्या हो सकता है? आप माइक्रोसिस्टिक्स के साथ काम करने के लिए किन विकल्पों का उपयोग करने की सलाह देंगे?

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

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

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

तेजी से, मैं इस बात की पुष्टि करता हूं कि छोटी और मध्यम आकार की कंपनियां अपने स्वयं के ऑर्केस्ट्रेशन वातावरण (उदाहरण के लिए, कुबेरनेट्स , डॉकर झुंड या अपाचे मेसो ) को उठाने के लिए अनुपयुक्त हैं। . ( Google Cloud Platform , Amazon Web Services , Microsoft Azure Oracle Cloud ) .

GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .

, , , open source, .

Spinnaker Heroku — , , .

— , , , . . ?

, . , , .

( ) . .

. . , (package). .

( ) Docker-, Git. , . , . , .

, . : API. . : . , API. , API , — . , API, .

. , ; API, ; , , .

, , . , ?

— - . , API, , . . .

, , . , , . , , .

— , . 2. , ? ?

. . Mesosphere , OpenShift PaaS IaaS . Deis , Deis . open source Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .

Deis2 . Deis, Kubernetes. Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.

— , , , ? ?

Helm. , . Helm .

Helm , — : , .

Helm chart' chart, , .

2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.

API API Gateway . , — .

, : . , , .

DevOps , . DevOpsConf Russia .

DevOpsConf Russia 1 2 RootConf, , , , . DevOps , .

DevOps , , – . 15 .