# Shoprocket का माइक्रोसर्विसेज़ की ओर सफ़र, भाग 1: मोनोलिथ को तोड़ने के बारे में मैंने क्या ग़लत समझा

> Shoprocket के शुरुआती सालों की इंजीनियरिंग टीम की पोस्ट, PHP मोनोलिथ से पहली सर्विस निकालने की कोशिश पर। मैंने ग़लत पहली सर्विस क्यों चुनी, कसी हुई कपलिंग ने मुझे क्या सिखाया, और Newman की वह सलाह जो मुझे पहले मान लेनी चाहिए थी।

Winston Berty  - 17 मार्च 2016 - 5 मिनट में पढ़ें

Shoprocket में अपनी नौकरी के कुछ महीने बाद, मैं झुँझलाने लगा था। हमारे पास एक PHP एप्लिकेशन थी जिस पर दुनिया भर में फैले तेज़ डेवलपरों की एक छोटी टीम काम कर रही थी, और मुझे लगता था कि बग ठीक करने से और बग पैदा होते थे, नए फ़ीचर जोड़ना उतना आसान नहीं था जितना होना चाहिए, और डिप्लॉयमेंट कम होते थे और तनाव भरे होते थे। वजह: बेहद जुड़ा हुआ कोड।

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

नई चीज़ की तलाश में रहने वाला एक उत्साही युवा डेवलपर होने के नाते, जब मेरी नज़र माइक्रोसर्विसेज़ पर पड़ी तो मैंने सोचा कि यह हमारी सारी समस्याएँ हल कर देगा।

## मैं माइक्रोसर्विसेज़ को क्या समझता था

माइक्रोसर्विसेज़ की कोई औपचारिक परिभाषा नहीं है, पर अपने शोध से मैंने यह निकाला कि माइक्रोसर्विस आर्किटेक्चर सॉफ़्टवेयर एप्लिकेशन को स्वतंत्र सर्विसों के वितरित सिस्टम के रूप में डिज़ाइन करने का तरीक़ा है, जिनमें से हर एक अत्यंत विशिष्ट होती है और उसका अपना जीवनचक्र होता है। विस्तृत परिचय के लिए Martin Fowler का [लेख](https://martinfowler.com/articles/microservices.html) शानदार है।

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

मैं क़ायल हो गया। Shoprocket मोनोलिथ को तोड़ने जा रहा था। यह उस सफ़र को दर्ज करती एक छोटी शृंखला का भाग 1 है। मेरी उम्मीद है कि ऐसे ही बदलाव की योजना बना रहे या उससे गुज़र रहे पाठक हमारी सफलताओं और असफलताओं से सीखेंगे।

## पहली चुनौती मानवीय थी, तकनीकी नहीं

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

पीछे मुड़कर देखें तो यह पहली सर्विस के लिए ख़राब चुनाव था। हमारे प्रोडक्ट में एक JavaScript विजेट शामिल है जो [किसी भी वेबसाइट पर ईकॉमर्स को संभव बनाता है](https://v3.shoprocket.io/hi/features/sell-on-any-website.md)। हम सेशन को एक संसाधन मानते हैं, और कार्ट छोड़ने और दूसरे KPI का विश्लेषण करने के लिए सेशन की जानकारी डेटाबेस में सहेजते हैं। पर यह संसाधन ऑर्डर या लाइन आइटम जैसी किसी चीज़ जितना मूर्त नहीं है, और हम एप्लिकेशन की स्थिति में लगभग हर बदलाव पर सेशन इस्तेमाल करते थे। इसका मतलब था कि सर्विस अनिवार्य रूप से बाक़ी एप्लिकेशन के साथ बातूनी रहेगी, जिसका मुझे अंदाज़ा नहीं था और जिसने मेरा काम और कठिन कर दिया।

## इसे सचमुच बनाकर मैंने क्या सीखा

मैंने अपना शोध तेज़ किया। Fowler के साथ-साथ, Sam Newman की **Building Microservices** एक अनिवार्य संसाधन साबित हुई।

Newman की सलाह, बाद में समझ आया, वही थी जो मुझे माननी चाहिए थी: पहले मौजूदा एप्लिकेशन को ऐसे मॉड्यूलों में पुनर्गठित करें जो डोमेन के बाउंडेड कॉन्टेक्स्ट को दर्शाते हों। जब डेवलपर सीमाओं से संतुष्ट हो जाएँ, *तब* मॉड्यूलों को उनकी अपनी सर्विसों में अलग करें। वजह यह है कि ख़राब सीमाओं वाले मॉड्यूलों को तोड़ना और दोबारा लिखना, अपने सारे अतिरिक्त प्लंबिंग कोड और स्थायी संसाधनों वाली पूरी सर्विसों को तोड़ने और दोबारा लिखने से कहीं आसान है।

मैंने वह सलाह नहीं मानी। अपना कोई कॉम्पोनेंट बनाने की उत्सुकता में, मैं सेशन सर्विस के साथ आगे बढ़ गया।

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

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

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

## ईमानदार आकलन

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

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

जो भी ऐसे ही बदलाव के बारे में सोच रहा है, उसके लिए मेरी ईमानदार सिफ़ारिशें:

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

Shoprocket अपने सफ़र पर चलता रहेगा। भाग 2 वहाँ है जहाँ बात ज़्यादा दिलचस्प होती है।

---

*मूल रूप से एक छोटी शृंखला की पहली कड़ी के तौर पर प्रकाशित, जो Shoprocket के PHP मोनोलिथ से दूर जाने के शुरुआती माइग्रेशन को दर्ज करती है। पूरा सफ़र, बाद के संस्करणों में सुधारी गई ग़लतियों समेत, तब से प्लेटफ़ॉर्म के हर बड़े पुनर्लेखन में जारी रहा है।*

---

- HTML version: https://v3.shoprocket.io/hi/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith
- Language: हिन्दी (hi)
- Also in: [العربية](https://v3.shoprocket.io/ar/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Deutsch](https://v3.shoprocket.io/de/blog/shoprocket-microservices-teil-1-monolith-zerlegen-fehler.md), [Ελληνικά](https://v3.shoprocket.io/el/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [English](https://v3.shoprocket.io/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Español](https://v3.shoprocket.io/es/blog/shoprocket-microservicios-parte-1-lo-que-hice-mal-monolito.md), [Français](https://v3.shoprocket.io/fr/blog/shoprocket-vers-les-microservices-partie-1-decouper-le-monolithe.md), [עברית](https://v3.shoprocket.io/he/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Bahasa Indonesia](https://v3.shoprocket.io/id/blog/perjalanan-shoprocket-menuju-microservices-bagian-1-salah-memecah-monolit.md), [Italiano](https://v3.shoprocket.io/it/blog/viaggio-di-shoprocket-verso-i-microservizi-parte-1-cosa-ho-sbagliato-sul-monolite.md), [日本語](https://v3.shoprocket.io/ja/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Lietuvių](https://v3.shoprocket.io/lt/tinklarastis/shoprocket-kelione-i-mikropaslaugas-1-dalis.md), [Norsk](https://v3.shoprocket.io/nb/blogg/shoprockets-vei-mot-mikrotjenester-del-1-hva-jeg-tok-feil-av.md), [Nederlands](https://v3.shoprocket.io/nl/blog/shoprocket-microservices-deel-1-monoliet-opknippen.md), [Polski](https://v3.shoprocket.io/pl/blog/droga-shoprocket-do-mikroserwisow-czesc-1-rozbijanie-monolitu.md), [Português](https://v3.shoprocket.io/pt/blog/jornada-do-shoprocket-para-microsservicos-parte-1-o-que-errei-ao-quebrar-o-monolito.md), [Română](https://v3.shoprocket.io/ro/blog/drumul-shoprocket-spre-microservicii-partea-1-ce-am-gresit-cu-monolitul.md), [Русский](https://v3.shoprocket.io/ru/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [ไทย](https://v3.shoprocket.io/th/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md), [Türkçe](https://v3.shoprocket.io/tr/blog/shoprocket-mikroservis-yolculugu-1-monoliti-parcalarken-yanlis-yaptiklarim.md), [中文](https://v3.shoprocket.io/zh/blog/shoprockets-journey-to-microservices-part-1-what-i-got-wrong-about-breaking-up-the-monolith.md)