क्लाउड की: अपने क्लाउड-नेटिव एप्लिकेशन का निर्माण कैसे करें

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

जब कोई एप्लिकेशन एक पर्यावरण का आदेश देता है

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

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

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


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

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

मोनोलिथ बनाम अराजकता का आदेश दिया

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

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

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

हालांकि, ऐसी सादगी की कीमत है। सबसे पहले, ये ऊपर वर्णित स्केलिंग के साथ समस्याएं हैं। कुछ बिंदु पर, यहां तक ​​कि सबसे विचारशील अखंड एप्लिकेशन सर्वर कॉन्फ़िगरेशन के नवीनीकरण से अधिक कुशलता से काम करना बंद कर देता है, जिस पर वह चल रहा है।


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

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

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

अनुप्रयोग विकास के एक तत्व के रूप में माइक्रोसिस्ट

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

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

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

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

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

चार विवरण

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

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

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


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

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

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

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

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