hi

यह काम किस प्रकार करता है?

व्यापार के लिए मदद चाहिए?

आपकी आवश्यकताओं के अनुरूप वैयक्तिकृत FinMV कोट के लिए हमसे संपर्क करें।

मोनोलिथिक या माइक्रोसर्विस?

आपकी कंपनी के तकनीकी निदेशक को, वित्तीय प्लेटफॉर्म के लॉन्च की योजना बनाते समय, एक प्रोजेक्ट आर्किटेक्चर विकल्प चुनना होगा। उसके लिए कौन से आर्किटेक्चर विकल्प उपलब्ध हैं और कौन सा चुनना बेहतर है?

विकल्प 1. मोनोलिथिक आर्किटेक्चर (मोनोलिथ)

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

परिणामस्वरूप, मालिक तकनीकी निदेशक, टीम के सदस्यों को बदलना शुरू करते हैं, लेकिन यह केवल बदतर हो जाता है। नई टीम के सदस्यों को ऐतिहासिक विवरण नहीं पता है कि स्नोबॉल ऐसा क्यों है और दूसरा नहीं। उत्पाद दस्तावेज़ीकरण जल्दी पुराना हो जाता है।

क्यों न इसे शुरू से ही करें? सबसे पहले, किसी व्यवसाय की शुरुआत में, हमेशा संसाधन सीमित होते हैं, पर्याप्त डेवलपर, विशेषज्ञता और समय नहीं होता है। मैनुअल आग्रह कर रहा है, और प्रोग्रामर इसे सबसे तेज़ संभव तरीके से करने की जल्दी में हैं।

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

विकल्प 2. माइक्रोसर्विस आर्किटेक्चर

हम आपके वित्तीय मंच को तुरंत माइक्रोसर्विस आर्किटेक्चर के आधार पर बना देंगे।

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

इस आर्किटेक्चर के कई फायदे हैं, लेकिन मैं सबसे महत्वपूर्ण का नाम दूंगा:

  • प्रत्येक माइक्रोसर्विस के संचालन के लिए व्यक्तिगत कर्मचारी जिम्मेदार हैं
  • प्रोजेक्ट कोड की चोरी को रोका जाता है, क्योंकि डेवलपर्स के पास कोड के केवल एक हिस्से तक पहुंच होती है
  • जब प्रोग्रामिंग भाषा के अपडेट सामने आते हैं, तो आप प्रत्येक सेवा के प्रोग्राम कोड को एक-एक करके ठीक कर सकते हैं

वास्तविक जीवन के उदाहरण

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

इस कार्यक्षमता को लागू करने में पूरी टीम को महीनों लग गए, और नई कार्यक्षमता का विकास और भी धीमा हो गया। माइक्रोसर्विस आर्किटेक्चर के मामले में, सब कुछ बहुत आसान और तेज़ होगा।

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

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

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

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

उस समय PHP और Laravel के नए संस्करण परियोजना और आगे के विकास को गति दे सकते थे, लेकिन मोनोलिथिक आर्किटेक्चर ने प्रौद्योगिकी स्टैक को अपडेट करने की अनुमति नहीं दी