MVP के लिए सर्वश्रेष्ठ आर्किटेक्चर: मोनोलिथ, SOA, माइक्रोसर्विस या सर्वरलेस? .. भाग 1

नवंबर में, OTUS ने एक नया शैक्षिक कार्यक्रम "सॉफ्टवेयर आर्किटेक्ट" लॉन्च किया, इसी के सिलसिले में हमने अपने ब्लॉग के पाठ्यक्रम और पाठकों के भविष्य के प्रकाशनों की एक श्रृंखला तैयार की है।

---

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

अखंड वास्तुकला

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



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

इस तथ्य के बावजूद कि हमारे पास Google में माइक्रोसॉर्क्स का उपयोग करने का सकारात्मक अनुभव था, हम [स्केलेर में] एक अखंड मार्ग के साथ चले गए, क्योंकि एक अखंड सर्वर होने से हमारे लिए दो इंजीनियरों के रूप में कम काम होता है।
स्टीफन चेरविंस्की, डिजाइन के प्रमुख, स्केलेर

यह पता लगाने के लिए कि क्या यह समाधान आपके व्यवसाय के लिए उपयुक्त है, आइए इसके पेशेवरों और विपक्षों को देखें।

अखंड वास्तुकला के फायदे

सरलीकृत विकास और परिनियोजन

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

कम क्रॉस-कटिंग मुद्दे

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

सर्वश्रेष्ठ प्रदर्शन

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

अखंड वास्तुकला के विपक्ष

कोड बेस समय के साथ बोझिल हो जाता है

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

नई तकनीकों को पेश करना मुश्किल है

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

सीमित लचीलापन

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

अंत में

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

एसओए

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

SOA के पेशेवरों

सेवाओं का पुन: उपयोग

सेवा-उन्मुख अनुप्रयोगों में कार्यात्मक घटकों की स्वायत्त और शिथिल प्रकृति के कारण, इन घटकों को अन्य सेवाओं को प्रभावित किए बिना कई अनुप्रयोगों में पुन: उपयोग किया जा सकता है।

हल्कापन साथ

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

उच्च विश्वसनीयता

मोनोलिथ्स की तरह कोड की विशाल मात्रा से डिबग और परीक्षण करना आसान है। यह बदले में, SOA- आधारित उत्पादों को अधिक विश्वसनीय बनाता है।

समानांतर विकास

क्योंकि सेवा-उन्मुख वास्तुकला स्तरित है, यह विकास की प्रक्रिया में संगामिति का समर्थन करता है। स्वतंत्र सेवाओं को समानांतर में विकसित किया जा सकता है और एक ही समय में पूरा किया जा सकता है।

SOA के विपक्ष

प्रबंधन में कठिनाई

सेवा-उन्मुख वास्तुकला का मुख्य दोष इसकी जटिलता है। प्रत्येक सेवा को समय पर संदेश वितरण प्रदान करना चाहिए। इन संदेशों की संख्या एक बार में एक मिलियन से अधिक हो सकती है, जिससे सभी सेवाओं का प्रबंधन करना मुश्किल हो जाता है।

उच्च निवेश लागत

SOA विकास के लिए मानव संसाधन, प्रौद्योगिकी और विकास में महत्वपूर्ण अग्रिम निवेश की आवश्यकता होती है।

अतिरिक्त भार

SOA में, एक सेवा द्वारा दूसरी सेवा के साथ सहभागिता करने से पहले सभी इनपुट को मान्य किया जाता है। कई सेवाओं का उपयोग करते समय, यह प्रतिक्रिया समय बढ़ाता है और समग्र प्रदर्शन को कम करता है।

अंत में

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

यह अनुवाद के पहले भाग का निष्कर्ष निकालता है, और हम सामग्री के दूसरे भाग में microservices और serverless वास्तुकला के बारे में बात करेंगे।