डोडो आईएस आर्किटेक्चर का इतिहास: एक प्रारंभिक मोनोलिथ

या मोनोलिथ वाली हर नाखुश कंपनी अपने तरीके से नाखुश है।

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

यह लेख "आर्किटेक्चर को फिर से लिखने और इतने बड़े पैमाने पर और दीर्घकालिक परिवर्तन क्यों करें?" सवालों का "जवाब" है? पिछले लेख पर वापस "डोडो आईएस आर्किटेक्चर का इतिहास: बैक ऑफिस का रास्ता". मैं शुरू करूँगा कि डोडो आईएस का विकास कैसे शुरू हुआ, मूल वास्तुकला कैसा दिखता था, नए मॉड्यूल कैसे दिखाई दिए, और किन समस्याओं के कारण बड़े पैमाने पर बदलाव किए जाने थे।

लेखों की श्रृंखला "डोडो आईएस क्या है?" के बारे में बताता है:

1. डोडो आईएस (2011-2015) में प्रारंभिक मोनोलिथ। (आप यहां हैं)

2. बैक ऑफिस पाथ: अलग-अलग बेस और बस.

3. क्लाइंट साइड पाथ: बेस के ऊपर का मुखौटा (2016-2017)। (चालू...)

4. सच्चे माइक्रोसर्विसेज का इतिहास। (2018-2019)। (चालू...)

5. मोनोलिथ को काटने का काम पूरा हो गया है और वास्तुकला का स्थिरीकरण हो गया है। (चालू...)

प्रारंभिक वास्तुकला

2011 में डोडो आईएस आर्किटेक्चर इस तरह दिखता था:

आर्किटेक्चर में पहला मॉड्यूल ऑर्डर स्वीकृति है। व्यापार प्रक्रिया थी:

• ग्राहक पिज़्ज़ेरिया कहता है;

• प्रबंधक फोन उठाता है;

• फोन द्वारा आदेश स्वीकार करता है;

• इसे ऑर्डर स्वीकृति इंटरफ़ेस में समानांतर में भरता है: ग्राहक के बारे में जानकारी, ऑर्डर विवरण पर डेटा, वितरण पते को ध्यान में रखा जाता है। 

कुछ इस तरह दिखता था सूचना तंत्र का इंटरफेस...

अक्टूबर 2011 से पहला संस्करण:

जनवरी 2012 में थोड़ा सुधार हुआ

डोडो पिज्जा सूचना प्रणाली डिलीवरी पिज्जा रेस्तरां

पहले ऑर्डर लेने वाले मॉड्यूल के विकास के लिए संसाधन सीमित थे। हमें बहुत कुछ करना था, जल्दी और एक छोटी सी टीम के साथ। एक छोटी सी टीम 2 डेवलपर्स हैं जिन्होंने पूरे भविष्य की प्रणाली की नींव रखी।

उनके पहले निर्णय ने प्रौद्योगिकी ढेर के भाग्य का निर्धारण किया:

• ASP.NET MVC, C# भाषा पर बैकएंड। डेवलपर्स dotnetchiki थे, यह स्टैक उनके लिए परिचित और सुखद था।

• बूटस्ट्रैप और JQuery पर दृश्यपटल: स्व-लिखित शैलियों और लिपियों पर उपयोगकर्ता इंटरफ़ेस। 

• MySQL डेटाबेस: कोई लाइसेंस लागत नहीं, प्रयोग करने में आसान।

• विंडोज सर्वर पर सर्वर, क्योंकि .NET तब केवल विंडोज के तहत हो सकता है (हम मोनो पर चर्चा नहीं करेंगे)।

शारीरिक रूप से, यह सब "होस्टर में समर्पण" में व्यक्त किया गया था। 

ऑर्डर इनटेक एप्लिकेशन आर्किटेक्चर

तब हर कोई पहले से ही माइक्रोसर्विसेज के बारे में बात कर रहा था, और SOA का उपयोग 5 वर्षों के लिए बड़ी परियोजनाओं में किया गया था, उदाहरण के लिए, WCF को 2006 में जारी किया गया था। लेकिन फिर उन्होंने एक विश्वसनीय और सिद्ध समाधान चुना।

यहाँ यह है।

Asp.Net MVC रेजर है, जो किसी फॉर्म या क्लाइंट के अनुरोध पर सर्वर रेंडरिंग के साथ एक HTML पेज रेंडर करता है। क्लाइंट पर, CSS और JS स्क्रिप्ट पहले से ही जानकारी प्रदर्शित करते हैं और यदि आवश्यक हो, तो JQuery के माध्यम से AJAX अनुरोध करते हैं।

सर्वर पर अनुरोध *नियंत्रक वर्ग में समाप्त होते हैं, जहां विधि में अंतिम HTML पृष्ठ का प्रसंस्करण और निर्माण होता है। नियंत्रक *सेवा नामक तर्क की एक परत के लिए अनुरोध करते हैं। प्रत्येक सेवा व्यवसाय के किसी न किसी पहलू से मेल खाती है:

• उदाहरण के लिए, डिपार्टमेंट स्ट्रक्चर सर्विस ने विभागों पर पिज़्ज़ेरिया के बारे में जानकारी दी। एक विभाग पिज़्ज़ेरिया का एक समूह है जो एक एकल फ्रेंचाइजी द्वारा चलाया जाता है।

• ReceivingOrdersService ने स्वीकार किया और ऑर्डर की संरचना की गणना की।

• और एसएमएस सेवा ने एसएमएस भेजने के लिए एपीआई सेवाओं को कॉल करके एसएमएस भेजा।

सेवाएँ डेटाबेस से डेटा संसाधित करती हैं, व्यावसायिक तर्क संग्रहीत करती हैं। प्रत्येक सेवा में उपयुक्त नाम के साथ एक या अधिक *रिपॉजिटरी थी। उनमें पहले से ही डेटाबेस में संग्रहीत कार्यविधियों और मैपर्स की एक परत के लिए प्रश्न शामिल थे। स्टोरेज में व्यावसायिक तर्क था, विशेष रूप से उन में बहुत कुछ जो रिपोर्टिंग डेटा जारी करते थे। ORM का उपयोग नहीं किया गया था, हर कोई हाथ से लिखे sql पर निर्भर था। 

डोमेन मॉडल और सामान्य सहायक वर्गों की एक परत भी थी, उदाहरण के लिए, ऑर्डर वर्ग जो ऑर्डर संग्रहीत करता है। वहीं, लेयर में सेलेक्टेड करेंसी के हिसाब से डिस्प्ले टेक्स्ट को कन्वर्ट करने के लिए हेल्पर था।

यह सब इस तरह के मॉडल द्वारा दर्शाया जा सकता है:

आदेश मार्ग

ऐसा आदेश बनाने के लिए एक सरल प्रारंभिक तरीके पर विचार करें।

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

• ग्राहक कीमतों के साथ एक स्थिर साइट पर जाता है, उत्पादों का चयन करता है और साइट पर सूचीबद्ध नंबर पर कॉल करता है।

• ग्राहक उन उत्पादों को नाम देता है जिन्हें वे ऑर्डर में जोड़ना चाहते हैं।

• अपना पता और नाम बताता है।

• ऑपरेटर आदेश स्वीकार करता है।

• ऑर्डर स्वीकृत ऑर्डर इंटरफ़ेस में प्रदर्शित होता है।

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

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

नोट. हां, यहां आप उत्पाद को डेटाबेस से नहीं खींच सकते हैं, लेकिन इसे फ्रंटएंड से ट्रांसफर कर सकते हैं। लेकिन स्पष्टता के लिए, मैंने डेटाबेस से बिल्कुल सही रास्ता दिखाया। 

अगला, ग्राहक का पता और नाम दर्ज करें। 

जब आप "आर्डर बनाएँ" पर क्लिक करते हैं:

• अनुरोध ऑर्डरकंट्रोलर.सेवऑर्डर() को भेजा जाता है।

• हम सत्र से कार्ट प्राप्त करते हैं, हमारे लिए आवश्यक मात्रा में उत्पाद हैं।

• हम क्लाइंट के बारे में जानकारी के साथ कार्ट को पूरक करते हैं और इसे ReceivingOrderService क्लास के AddOrder मेथड में पास करते हैं, जहाँ इसे डेटाबेस में सेव किया जाता है। 

• डेटाबेस में ऑर्डर, ऑर्डर की संरचना, क्लाइंट के साथ टेबल हैं, और वे सभी जुड़े हुए हैं।

• ऑर्डर डिस्प्ले इंटरफ़ेस जाता है और नवीनतम ऑर्डर निकालता है और उन्हें प्रदर्शित करता है।

नए मॉड्यूल

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

एक मॉड्यूल कार्यों का एक समूह है जो कुछ सामान्य व्यावसायिक लक्ष्य से एकजुट होता है। साथ ही, वे शारीरिक रूप से एक ही एप्लिकेशन में हैं।

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

तकनीकी रूप से, मॉड्यूल को क्षेत्र के रूप में डिजाइन किया गया था (ऐसा विचार अंदर भी बना रहा एएसपीनेट कोर). दृश्यपटल, मॉडल, साथ ही अपने स्वयं के नियंत्रक वर्गों के लिए अलग-अलग फाइलें थीं। नतीजतन, सिस्टम इस से बदल गया था ...

...इस मामले में:

कुछ मॉड्यूल पूरी तरह से अलग कार्यक्षमता और आंशिक रूप से थोड़ा अलग, अधिक केंद्रित विकास के कारण अलग-अलग साइटों (निष्पादन योग्य परियोजना) द्वारा कार्यान्वित किए जाते हैं। यह:

• साइट - पहला संस्करण साइट dodopizza.ru।

• निर्यात: 1सी के लिए डोडो आईएस से रिपोर्ट अपलोड करना। 

• व्यक्तिगत - कर्मचारी का व्यक्तिगत खाता। इसे अलग से विकसित किया गया था और इसका अपना प्रवेश बिंदु और अलग डिज़ाइन है।

• fs - स्टैटिक्स की मेजबानी के लिए एक परियोजना। बाद में हम इससे दूर चले गए, सभी स्टैटिक्स को अकामाई सीडीएन में ले गए। 

बाकी ब्लॉक बैकऑफिस एप्लिकेशन में थे। 

नाम की व्याख्या:

• खजांची - रेस्तरां खजांची।

• ShiftManager - "Shift Manager" भूमिका के लिए इंटरफेस: पिज़्ज़ेरिया की बिक्री पर परिचालन आँकड़े, उत्पादों को स्टॉप लिस्ट पर रखने की क्षमता, ऑर्डर बदलें।

• OfficeManager - "पिज़्ज़ेरिया प्रबंधक" और "फ़्रैंचाइज़ी" भूमिकाओं के लिए इंटरफ़ेस। यहां एक पिज़्ज़ेरिया स्थापित करने, उसके बोनस प्रचार, प्राप्त करने और कर्मचारियों के साथ काम करने, रिपोर्ट करने के लिए कार्य एकत्र किए गए हैं।

• पब्लिकस्क्रीन - पिज़्ज़ेरिया में लटकने वाले टीवी और टैबलेट के लिए इंटरफेस। टीवी डिस्प्ले मेन्यू, विज्ञापन की जानकारी, डिलीवरी पर ऑर्डर की स्थिति। 

उन्होंने एक सामान्य सेवा परत, एक सामान्य Dodo.Core डोमेन क्लास ब्लॉक और एक सामान्य आधार का उपयोग किया। कभी-कभी वे अभी भी एक-दूसरे के संक्रमण के साथ आगे बढ़ सकते हैं। dodopizza.ru या personal.dodopizza.ru जैसी अलग-अलग साइटों सहित, सामान्य सेवाओं में चली गईं।

जब नए मॉड्यूल दिखाई दिए, तो हमने डेटाबेस में पहले से ही बनाई गई सेवाओं, संग्रहीत कार्यविधियों और तालिकाओं का अधिकतम पुन: उपयोग करने का प्रयास किया। 

सिस्टम में बने मॉड्यूल के पैमाने की बेहतर समझ के लिए, यहां 2012 से विकास योजनाओं के साथ एक आरेख है:

2015 तक, सब कुछ मानचित्र पर था और इससे भी अधिक उत्पादन में था।

• आदेश स्वीकृति संपर्क केंद्र के एक अलग ब्लॉक में विकसित हो गई है, जहां ऑपरेटर द्वारा आदेश स्वीकार किया जाता है।

• पिज़्ज़ेरिया में मेन्यू और सूचनाओं के साथ सार्वजनिक स्क्रीन थीं।

• किचन में एक मॉड्यूल है जो एक नया ऑर्डर आने पर वॉयस मैसेज "न्यू पिज्जा" को स्वचालित रूप से प्ले करता है, और कूरियर के लिए एक चालान भी प्रिंट करता है। यह रसोई में प्रक्रियाओं को बहुत सरल करता है, कर्मचारियों को बड़ी संख्या में सरल संचालन से विचलित नहीं होने देता है।

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

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

समस्याओं

वास्तुकला के कारण (लेकिन न केवल)।

बेस में अफरातफरी

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

लेकिन विकास के 4 वर्षों में, डेटाबेस में लगभग 600 टेबल, 1500 संग्रहीत कार्यविधियाँ निकलीं, जिनमें से कई में तर्क भी थे। काश, संग्रहीत कार्यविधियाँ MySQL के साथ काम करते समय अधिक लाभ नहीं लातीं। वे आधार द्वारा कैश नहीं किए जाते हैं, और उनमें तर्क संग्रहीत करना विकास और डिबगिंग को जटिल बनाता है। कोड का पुन: उपयोग भी कठिन है।

कई तालिकाओं में उपयुक्त अनुक्रमणिकाएँ नहीं थीं, कहीं न कहीं, इसके विपरीत, बहुत सारे इंडेक्स थे, जिससे सम्मिलित करना मुश्किल हो गया। लगभग 20 तालिकाओं को संशोधित करना आवश्यक था - एक आदेश बनाने के लिए लेन-देन में लगभग 3-5 सेकंड लग सकते थे। 

तालिकाओं में डेटा हमेशा सबसे उपयुक्त रूप में नहीं होता है. कहीं न कहीं denormalization करना जरूरी था। नियमित रूप से प्राप्त डेटा का एक हिस्सा XML संरचना के रूप में एक कॉलम में था, इसने निष्पादन समय में वृद्धि की, प्रश्नों को लंबा किया और विकास को जटिल बना दिया।

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

डेटा एकत्र नहीं किया गया था और आधार का उपयोग करते हुए कई गणनाएँ तुरंत की गईं। इससे अनावश्यक गणना और अतिरिक्त भार पैदा हुआ। 

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

कोड में सामंजस्य और अस्पष्टता

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

सेवाएँ (एक अखंड बड़ी परियोजना के भीतर की कक्षाएं) अपने डेटा को समृद्ध करने के लिए एक दूसरे को बुला सकती हैं।

मॉडल कक्षाओं के साथ जो स्वयं डेटा संग्रहीत करते हैं, कोड में काम अलग तरीके से किया गया था. कहीं कंस्ट्रक्टर थे जिनके माध्यम से आवश्यक फ़ील्ड निर्दिष्ट करना संभव था। कहीं सार्वजनिक संपत्तियों के जरिए ऐसा किया गया। बेशक, डेटाबेस से डेटा प्राप्त करना और बदलना विविध था। 

तर्क या तो नियंत्रकों या सेवा वर्गों में था। 

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

एक बड़े विकास की जटिलता

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

सिस्टम के कुछ हिस्सों में इसके लिए अधिक उपयुक्त डेटाबेस का उपयोग किया जा सकता है।. उदाहरण के लिए, बाद में हमारे पास ऑर्डर बास्केट स्टोर करने के लिए Redis से CosmosDB में जाने का उपयोग मामला था। 

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

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

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

पावर ऑफ द माइंड ब्लॉग कैसे रेस्तरां में कैश रजिस्टर रखता है

यदि पिज़्ज़ेरिया नेटवर्क (और लोड) का विकास उसी गति से जारी रहा, तो थोड़ी देर बाद गिरावट ऐसी होगी कि सिस्टम नहीं उठेगा। 2015 तक हम जिन समस्याओं का सामना करने लगे थे, उन्हें अच्छी तरह से दिखाता है, यहाँ ऐसी ही एक कहानी है। 

ब्लॉग में "मन की शक्ति” एक विजेट था जो पूरे नेटवर्क के वर्ष के लिए राजस्व पर डेटा दिखाता था। विजेट डोडो पब्लिक एपीआई तक पहुंच गया, जो यह डेटा प्रदान करता है। यह आँकड़ा वर्तमान में पर उपलब्ध है http://dodopizzastory.com/. विजेट प्रत्येक पृष्ठ पर दिखाया गया था और प्रत्येक 20 सेकंड में टाइमर पर अनुरोध किया गया था। अनुरोध api.dodopizza.ru पर गया और अनुरोध किया:

• नेटवर्क में पिज़्ज़ेरिया की संख्या;

• वर्ष की शुरुआत के बाद से कुल नेटवर्क राजस्व;

• आज के लिए राजस्व।

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

रेस्तरां में कैश डेस्क ऑर्डर की एक ही तालिका में गए, आज के लिए प्राप्त ऑर्डर की सूची को अनलोड किया और इसमें नए ऑर्डर जोड़े गए। कैश रजिस्टर ने हर 5 सेकंड में या पेज रिफ्रेश पर अपने अनुरोध किए।

आरेख इस प्रकार दिखाई दिया:

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

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

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

अब से, भार के साथ और सिस्टम के स्थिरीकरण के लिए हमारा संघर्ष शुरू होता है (शरद ऋतु 2015 से शरद ऋतु 2018 तक)। तभी यह हुआ"महान गिरावट"। इसके अलावा, कभी-कभी असफलताएँ भी हुईं, कुछ बहुत संवेदनशील थीं, लेकिन अस्थिरता की सामान्य अवधि को अब पारित माना जा सकता है।

तेजी से व्यापार वृद्धि

इसे तुरंत क्यों नहीं किया जा सका? बस निम्नलिखित चार्टों को देखें।

इसके अलावा 2014-2015 में रोमानिया में एक ओपनिंग थी और यूएसए में एक ओपनिंग तैयार की जा रही थी।

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

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

मदद करने वाले त्वरित समाधान

समस्याओं के समाधान की जरूरत है। परंपरागत रूप से, समाधानों को 2 समूहों में विभाजित किया जा सकता है:

• तेज़ जो आग बुझाते हैं और सुरक्षा का एक छोटा सा मार्जिन देते हैं और हमें बदलने के लिए समय देते हैं।

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

त्वरित परिवर्तनों की शुष्क सूची इस प्रकार है:

स्केल अप बेस मास्टर

बेशक, लोड से निपटने के लिए जो पहली चीज की जाती है वह सर्वर की क्षमता को बढ़ाना है। यह मास्टर डेटाबेस और वेब सर्वर के लिए किया गया था। काश, यह एक निश्चित सीमा तक ही संभव होता, फिर यह बहुत महंगा हो जाता।

2014 से, हम Azure में चले गए हैं, हमने उस समय इस विषय के बारे में लेख में भी लिखा था “Microsoft Azure क्लाउड का उपयोग करके डोडो पिज़्ज़ा कैसे पिज़्ज़ा वितरित करता है"। लेकिन आधार के लिए सर्वर में वृद्धि की एक श्रृंखला के बाद, वे लागत के खिलाफ आ गए। 

पढ़ने के लिए आधार प्रतिकृतियां

आधार के लिए दो प्रतिकृतियां बनाई गईं:

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

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

कोड में कैश

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

एकाधिक बैकएंड सर्वर

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

नतीजतन, वास्तुकला अधिक जटिल हो गई है ...

...लेकिन तनाव कुछ दूर हुआ।

और फिर लोड किए गए घटकों को फिर से करना आवश्यक था, जिसे हमने किया था। हम इस बारे में अगले भाग में बात करेंगे।

स्रोत: www.habr.com