माइक्रोसर्विसेज - संस्करणों का एक संयुक्त विस्फोट

नमस्ते, हबर! मैं आपके ध्यान में प्रस्तुत करता हूँ लेख का लेखक का अनुवाद माइक्रोसर्विसेज - संस्करणों का संयुक्त विस्फोट.

ऐसे समय में जब आईटी जगत धीरे-धीरे कुबेरनेट्स जैसे माइक्रोसर्विसेज और टूल की ओर बढ़ रहा है, केवल एक समस्या अधिक से अधिक ध्यान देने योग्य होती जा रही है। इस समस्या - संयुक्त विस्फोट माइक्रोसर्विस संस्करण। फिर भी आईटी समुदाय का मानना ​​है कि मौजूदा स्थिति काफी बेहतर है "निर्भरता नरक" प्रौद्योगिकियों की पिछली पीढ़ी. हालाँकि, माइक्रोसर्विसेज को वर्जन करना एक बहुत ही जटिल समस्या है। इसका एक प्रमाण जैसे लेख हो सकते हैं "मुझे मेरा मोनोलिथ वापस दे दो".

यदि आप अभी भी इस पाठ को पढ़कर समस्या को नहीं समझ पाए हैं, तो मैं समझाता हूँ। मान लीजिए कि आपके उत्पाद में 10 माइक्रोसर्विसेज शामिल हैं। अब मान लेते हैं कि इनमें से प्रत्येक माइक्रोसर्विसेज के लिए 1 नया संस्करण जारी किया गया है। केवल 1 संस्करण - मुझे आशा है कि हम सभी सहमत हो सकते हैं कि यह एक बहुत ही तुच्छ और महत्वहीन तथ्य है। हालाँकि, अब आइए अपने उत्पाद पर एक और नज़र डालें। प्रत्येक घटक के सिर्फ एक नए संस्करण के साथ, अब हमारे पास 2^10 - या 1024 क्रमपरिवर्तन हैं कि हमारा उत्पाद कैसे बनाया जा सकता है।

यदि अब भी कोई ग़लतफ़हमी है, तो मैं गणित का विश्लेषण कर दूं। तो हमारे पास 10 माइक्रोसर्विसेज हैं, जिनमें से प्रत्येक को एक अपडेट प्राप्त हो रहा है। अर्थात्, हमें प्रत्येक माइक्रोसर्विस के लिए 2 संभावित संस्करण मिलते हैं (या तो पुराना या नया)। अब, प्रत्येक उत्पाद घटक के लिए, हम इन दोनों संस्करणों में से किसी एक का उपयोग कर सकते हैं। गणितीय रूप से, यह वैसा ही है जैसे हमारे पास 10 अंकों की एक बाइनरी संख्या हो। उदाहरण के लिए, मान लें कि 1 नया संस्करण है, और 0 पुराना संस्करण है - तो एक संभावित क्रमपरिवर्तन को 1001000000 के रूप में दर्शाया जा सकता है - जहां पहला और चौथा घटक अपडेट किया गया है, और अन्य सभी नहीं हैं। गणित से हम जानते हैं कि 1 अंकों वाली बाइनरी संख्या में 4^10 या 2 मान हो सकते हैं। अर्थात्, हम जिस संख्या से निपट रहे हैं उसके पैमाने की हमने पुष्टि कर दी है।

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

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

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

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

हमें एकीकरण चरण में प्रयोग की एक प्रणाली की आवश्यकता है, जहां हम प्रत्येक घटक के लिए जोखिम कारक निर्धारित कर सकते हैं, और ऑपरेटर के हस्तक्षेप के बिना विभिन्न घटकों को अद्यतन करने और परीक्षण करने के लिए एक स्वचालित प्रक्रिया भी है - यह देखने के लिए कि क्या काम करता है और क्या नहीं।

प्रयोगों की ऐसी प्रणाली इस तरह दिख सकती है:

1. डेवलपर्स परीक्षण लिखते हैं (यह एक महत्वपूर्ण चरण है - क्योंकि अन्यथा हमारे पास कोई मूल्यांकन मानदंड नहीं है - यह मशीन लर्निंग में डेटा को लेबल करने जैसा है)।
2. प्रत्येक घटक (परियोजना) को अपनी स्वयं की सीआई प्रणाली प्राप्त होती है - यह प्रक्रिया अब अच्छी तरह से विकसित हो गई है, और एकल घटक के लिए सीआई प्रणाली बनाने का मुद्दा काफी हद तक हल हो गया है।
3. "स्मार्ट एकीकरण प्रणाली" विभिन्न सीआई प्रणालियों के परिणाम एकत्र करती है और घटक परियोजनाओं को अंतिम उत्पाद में जोड़ती है, परीक्षण चलाती है और अंत में मौजूदा घटकों और जोखिम कारकों के आधार पर वांछित उत्पाद कार्यक्षमता प्राप्त करने के लिए सबसे छोटे रास्ते की गणना करती है। यदि कोई अपडेट संभव नहीं है, तो यह सिस्टम डेवलपर्स को मौजूदा घटकों के बारे में सूचित करता है और उनमें से कौन सी त्रुटि उत्पन्न कर रहा है। एक बार फिर, परीक्षण प्रणाली यहां अत्यंत महत्वपूर्ण है - चूंकि एकीकरण प्रणाली परीक्षणों को मूल्यांकन मानदंड के रूप में उपयोग करती है।
4. सीडी सिस्टम, जो फिर स्मार्ट इंटीग्रेशन सिस्टम से डेटा प्राप्त करता है और सीधे अपडेट करता है। यह चरण चक्र को समाप्त करता है।

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

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

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

स्रोत: www.habr.com