कैसे Groupon न्यू नोड.जेएस इन्फ्रास्ट्रक्चर के लिए एक अखंड रेल एप्लिकेशन से माइग्रेट किया गया

आई-टियर: मोनोलिथ क्लीवेज

हाल ही में, हमने संयुक्त राज्य में ग्रुपन की वार्षिक वेब ट्रैफिक माइग्रेशन परियोजना को नए Node.js स्टैक के लिए रेल एप्लिकेशन पर एक अखंड रूबी से पूरा किया, और हमें महत्वपूर्ण परिणाम मिले।

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

इस वैश्विक वास्तु प्रवास के कुछ मुख्य अंश इस प्रकार हैं:

• साइट पर पेज बहुत तेजी से लोड होते हैं

• हमारी विकास टीमें अन्य टीमों पर कम निर्भरता के साथ तेजी से नई सुविधाओं को विकसित और जोड़ सकती हैं

• हम विभिन्न देशों में जहां Groupon उपलब्ध है, उन्हीं विशेषताओं को फिर से विकसित करने से बच सकते हैं।

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

संक्षिप्त इतिहास

Groupon मूल रूप से एक पेज की साइट थी जो शिकागो के निवासियों के लिए दैनिक सौदों का प्रदर्शन करती थी। इस तरह के विशिष्ट सौदे का एक उदाहरण स्थानीय रेस्तरां या स्थानीय संगीत कार्यक्रम के लिए टिकट पर छूट हो सकता है।

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

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

मूल रेल वास्तुकला काफी सरल थी:



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

हमने एक समान पैटर्न का पालन करना जारी रखा, नई सेवाओं में मौजूदा बैकएंड असाइनमेंट को तोड़ते हुए, हालांकि, वेबसाइट पर सभी कुछ (विचार, नियंत्रक, संसाधन, आदि) मूल रेल एप्लिकेशन का हिस्सा बने रहे:



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

भूमंडलीकरण

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

CityDeal वास्तुकला में Groupon वास्तुकला के साथ समानताएं थीं, लेकिन यह पूरी तरह से एक अन्य टीम द्वारा बनाई गई स्वायत्त कार्यान्वयन थी। नतीजतन, अंतर डिजाइन और प्रौद्योगिकी में थे - माणिक के बजाय रूबी, अपाचे के बजाय जावा, MySQL के बजाय पोस्टग्रेक्यूएल।



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

मोबाइल ऐप

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



इसने हमारी मोबाइल टीम के लिए अच्छा काम किया। वे एक मोबाइल एप्लिकेशन का निर्माण कर सकते हैं जो हमारे सभी देशों में काम करता है।

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

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

यौगिक मोनोलिथ

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

लेकिन हम बार-बार इसी तरह की समस्याओं का सामना कर रहे हैं। हमें न केवल संयुक्त राज्य अमेरिका में कोड से निपटना था, बल्कि यूरोपीय कोड के साथ भी हमें कई समस्याएं थीं। हमें सीमा को पूरी तरह से पुनर्गठित करने की जरूरत है।

सभी को फिर से लिखें

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

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

लक्ष्य 1: हमारे सामने के छोरों को मिलाएं

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

लक्ष्य 2: मोबाइल ऐप्स को वेब पर रखें

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

लक्ष्य 3: साइट को तेज़ करें

हमारी साइट हमसे कम धीमी थी। जब हम साइट के विकास को नियंत्रित करने की कोशिश कर रहे थे, तो अमेरिकी सीमांत तकनीकी ऋण जमा हो गया, जिससे अनुकूलन करना मुश्किल हो गया। हम एक समाधान खोजना चाहते थे जिसके लिए अनुरोधों को पूरा करने के लिए बहुत सारे कोड की आवश्यकता नहीं होगी। हम कुछ सरल चाहते थे।

लक्ष्य 4: टीमों को स्वतंत्र रूप से प्रगति करने की अनुमति दें

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

दृष्टिकोण

सबसे पहले, हमने साइट की प्रत्येक मुख्य विशेषता को अलग-अलग वेब अनुप्रयोगों में विभाजित करने का निर्णय लिया:



हमने Node.js पर एक फ्रेमवर्क बनाया, जिसमें सभी अनुप्रयोगों द्वारा आवश्यक सामान्य कार्यक्षमता शामिल थी, ताकि हमारी टीम इन व्यक्तिगत अनुप्रयोगों को आसानी से बना सके।

नोट: Node.js क्यों?

अपनी नई फ्रंट-एंड लेयर बनाने से पहले, हमने यह पता लगाने के लिए कई अलग-अलग सॉफ्टवेयर स्टैक का मूल्यांकन किया कि कौन सा हमारे लिए सबसे अच्छा है।

हम एक विशिष्ट कार्य के लिए एक समाधान की तलाश में थे - कुशलतापूर्वक आने वाले कई HTTP अनुरोधों की सेवा करने के लिए, इन HTTP अनुरोधों में से प्रत्येक की सेवाओं के समानांतर एपीआई अनुरोधों को निष्पादित करें; और परिणाम HTML पर लौटाएँ। हम कुछ ऐसा भी चाहते थे जिससे हम आत्मविश्वास से निगरानी, ​​तैनाती और समर्थन कर सकें।

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

दृष्टिकोण, जारी ...

फिर हमने शीर्ष पर एक रूटिंग परत जोड़ी, जो उपयोगकर्ताओं को उनके द्वारा देखे गए पृष्ठ के आधार पर उपयुक्त एप्लिकेशन पर पुनर्निर्देशित करती है:



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

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

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



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

परिणाम:

हमने अभी-अभी रुबी से नए Node.js. के लिए अपने अमेरिकी सीमा के परिवर्तन को पूरा किया है पुराने अखंड फ्रंट-एंड को लगभग 20 अलग-अलग वेब अनुप्रयोगों में विभाजित किया गया है, जिनमें से प्रत्येक को पूरी तरह से फिर से लिखा गया है। वर्तमान में हम प्रति मिनट औसतन 50,000 अनुरोधों की सेवा करते हैं, लेकिन हम उम्मीद करते हैं कि यह यातायात छुट्टियों के मौसम में बढ़ेगा। और यह संख्या काफी बढ़ जाएगी, क्योंकि हम अपने अन्य 48 देशों से यातायात को स्थानांतरित करते हैं।

ये वे फायदे हैं जिनकी पहचान हमने हाल ही में की है:

- पृष्ठ तेजी से लोड होते हैं - आमतौर पर 50% तक। यह आंशिक रूप से प्रौद्योगिकी में परिवर्तन के कारण है और आंशिक रूप से क्योंकि हमारे पास चीजों को गति देने के लिए हमारे सभी वेब पृष्ठों को फिर से लिखने का मौका था। और हम अभी भी यहां महत्वपूर्ण बदलाव करने की योजना बना रहे हैं, क्योंकि हम अतिरिक्त बदलाव कर रहे हैं।

- हम पुराने स्टैक की तुलना में कम उपकरणों के साथ यातायात की समान मात्रा की सेवा करते हैं।

- टीमें स्वतंत्र रूप से अपने अनुप्रयोगों में परिवर्तन तैनात करने में सक्षम हैं।

- हम अपने पुराने आर्किटेक्चर के साथ जितना कर सकते थे उससे कहीं ज्यादा तेजी से एक व्यक्तिगत फीचर के कोड में बदलाव कर सकते हैं।

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

[ मूल लेख Engineering.groupon.com पर]