शॉपरोकेट की माइक्रोसर्विसेस की यात्रा: भाग 1

मेरी नौकरी के कुछ महीनों बाद, मैं Shoprocket पर निराश हो रहा था। हमारे छोटे और प्रतिभाशाली डेवलपर्स की टीम, जो दुनियाभर में फैली हुई थी, द्वारा एक PHP एप्लिकेशन पर काम चल रहा था। मुझे निराशा क्यों हो रही थी? मुझे ऐसा लग रहा था कि बग फिक्स अन्य बग उत्पन्न कर रहे हैं, नए फीचर्स का एकीकृत करना सरल नहीं था, और डिप्लॉयमेंट अक्सर होते थे और तनावपूर्ण थे। इन समस्याओं का कारण: अत्यधिक युग्मित कोड।

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

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

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

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

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

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

अपने बॉस को मनाने के बाद, मैंने माइक्रोसर्विसेस पर अपने शोध को तेज कर दिया। उपरोक्त लेख के अलावा, मैंने सैम न्यूमैन की 'बिल्डिंग माइक्रोसर्विसेस' को एक अमूल्य संसाधन पाया। मैं अपनी पोस्ट में उन दोनों का अक्सर संदर्भ दूंगा।

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

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

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

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

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

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

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

Shoprocket माइक्रोसर्विसेस की यात्रा जारी रखेगा। हम भाग 2 में आपको और बताने के लिए उत्सुक हैं!