प्लेटफार्म जन्म

दुनिया बदल गई है। मैं इसे पानी में महसूस करता हूं, इसे जमीन में देखता हूं, इसे हवा में महसूस करता हूं। जो कुछ भी एक बार अस्तित्व में है, वह चला गया है, और इसे याद रखने वालों की संख्या अधिक नहीं है।
फिल्म "द लॉर्ड ऑफ द रिंग्स: द फैलोशिप ऑफ द रिंग" से

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

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

भाग 1. कुछ बदलना आवश्यक है

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

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

वीर पुर्नजन्म

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

उदाहरण के लिए: ISPmanager में उपयोगकर्ता बनाने से FTP उपयोगकर्ता, मेल डोमेन, मेलबॉक्स, DNS रिकॉर्ड, साइट का निर्माण भी हो सकता है। और यह सब परमाणु रूप से किया जाता है, और इसलिए जब तक ऑपरेशन पूरा नहीं हो जाता तब तक सूचीबद्ध घटकों में परिवर्तन को अवरुद्ध करता है।

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

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

प्रतिक्रिया समय और तत्काल सूचनाएं कम करें

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

लेकिन अगर आपको परिणाम की आवश्यकता है, तो यहां और अब क्या कहा जाता है? मुझे लगता है कि कई लोग उस स्थिति से परिचित होते हैं जब आप पृष्ठ को इस उम्मीद से अधिक लोड करते हैं कि ऑपरेशन समाप्त होने वाला है।

नई पीढ़ी के उत्पादों में, हम त्वरित ईवेंट डिलीवरी के लिए वेबसोकेट का उपयोग करते हैं।

पहले कार्यान्वयन में लॉन्गपोल का उपयोग किया गया था, लेकिन इस दृष्टिकोण के साथ सीमांत डेवलपर्स असहज थे।

HTTP आंतरिक संचार

HTTP एक ट्रांसपोर्ट जीता। अब, किसी भी भाषा में, एक HTTP सर्वर सेकंड में लागू होता है (यदि आप Google, फिर मिनटों में)। स्थानीय रूप से भी, आपके प्रोटोकॉल को अवरुद्ध करने की तुलना में HTTP अनुरोध बनाना आसान है।

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

इसलिए, छठी पीढ़ी में, हम HTTP के माध्यम से आंतरिक बातचीत में बदल गए, और एक्सटेंशन, वास्तव में, छोटे वेब सर्वर बन गए।

नया (काफी नहीं) एपीआई

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

कल्पना करें कि यह कितना दुखद है: कुछ सौ मेगाबाइट या गीगाबाइट स्वीकार करने के लिए, और फिर पता चलता है कि उन्हें एक अनधिकृत उपयोगकर्ता द्वारा डाला गया था या अब उन्हें उस सर्वर पर स्थानांतरित करने की आवश्यकता है!

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

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

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

लंबे समय तक जीवित रहें!

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

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

एक निरपेक्ष प्लस डिस्क और मेमोरी दोनों की कम खपत है, और वीडीएस के अंदर काम करने के लिए यह काफी महत्वपूर्ण हो सकता है। कमियों में से - एक पुस्तकालय जिसका संस्करण आप नियंत्रित नहीं करते हैं का उपयोग करके अप्रत्याशित परिणाम हो सकते हैं, जो विकास और परीक्षण दोनों पर भार को बढ़ाता है। एक और दोष पुस्तकालयों और आधुनिक C ++ के नवीनतम संस्करणों का उपयोग करने में असमर्थता है (उदाहरण के लिए, CentOS 6 पर भी C ++ 11 पूरी तरह से समर्थित नहीं है)।

पुरानी आदतें

नई तकनीकों के लिए दृष्टिकोण और परिवर्तन, हम पुराने तरीके से कार्य करते रहे। इससे मुश्किलें बढ़ गईं।

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

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

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

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

भाग 2. असंगत का मेल

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

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

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

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

भाग 3. जैसा कि हमने बॉक्स लिखा है, और मंच लिखा है

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

एक मंच क्या है? सबसे पहले, हमने सास को तैनात किया, एक सेवा जो हमारे सर्वर पर चलती है और आपको अपने सर्वर को कॉन्फ़िगर करने की अनुमति देती है। यदि आपने किसी सर्वर कंट्रोल पैनल का उपयोग किया है और इसे स्वयं खरीदा है - तो यह आपके लिए समाधान है। लेकिन यह प्रदाताओं को सूट नहीं करता है: वे अपने ग्राहकों के सर्वर को किसी तीसरे पक्ष की कंपनी तक पहुंच प्रदान करने के लिए तैयार नहीं हैं, और मैं उन्हें अच्छी तरह से समझता हूं। यह सुरक्षा और गलती सहिष्णुता दोनों के सवाल उठाता है। इसलिए, हमने उन्हें अपना पूरा सास देने का फैसला किया ताकि वे इसे घर पर तैनात कर सकें। यह अमेज़ॅन की तरह है, जिसे आप अपने स्वयं के डेटा केंद्र में चला सकते हैं और अपने बिलिंग सिस्टम से कनेक्ट कर सकते हैं। हमने इस समाधान को एक मंच कहा।

पहली तैनाती बहुत आसानी से नहीं हुई। प्रत्येक सक्रिय उपयोगकर्ता के लिए, हमने एक अलग कंटेनर उठाया। डॉकर कंटेनर जल्दी से बढ़ते हैं, लेकिन सेवा खोज तुरंत काम नहीं करती है: यह एक सेकंड के भीतर कंटेनरों को गतिशील रूप से बढ़ाने / रोकने का इरादा नहीं है। और उस पल को बढ़ाने से लेकर जब सेवा का उपयोग किया जा सकता है, कभी-कभी मिनट बीत जाते हैं !!!

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

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



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

अभी भी ऐसे लोग हो सकते हैं जो किसी भी पैनल का उपयोग नहीं करते हैं और सोचते हैं: इससे मुझे चिंता नहीं है। लेकिन शायद आपके सर्वर पर, यदि आपके पास एक है, तो किसी प्रकार का पैनल अभी भी खड़ा है और संसाधनों को खाता है, लेकिन आप इसका उपयोग नहीं करते हैं?

"तो यह भी अद्भुत है, आप हमें संसाधनों को बेचने में मदद करते हैं," रूसी होस्टर्स कहते हैं। अन्य लोग कहते हैं: "हम अपने संसाधनों को एक मंच पर तैनात करने में क्यों खर्च करते हैं जो एक स्टैंड-अलोन पैनल से अधिक खपत करता है?"

इस सवाल के कई जवाब हैं।

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

हमारे कई और ग्राहकों ने पैक्स में लाइसेंस खरीदे और फिर उन्हें रद्दी कर दिया और उन्हें अपने ग्राहकों को दे दिया। सिद्धांत रूप में, निरर्थक कार्य, ऐसा करने की अब कोई आवश्यकता नहीं है। आखिरकार, अब यह एक उत्पाद है।

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

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

कहानी अभी खत्म नहीं हुई है, लेकिन जो हुआ उसे वेप्प वेबसाइट पर देखा जा सकता है।