माइक्रोसर्विसेस - संस्करणों का दहनशील विस्फोट

नमस्कार, हेब्र! मैं आपके लिए लेख के लेखक का अनुवाद प्रस्तुत करता हूं माइक्रोसर्विसेस - कॉम्बिनेटरियल एक्सप्लोरेशन ऑफ वर्जन ।

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

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

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

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

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

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

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

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

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

1. ( — — ).
2. () CI — , CI
3. « » CI - , . , . , — .
4. CD , « » . .

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

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

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