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

किंवा मोनोलिथ असलेली प्रत्येक नाखूष कंपनी स्वतःच्या मार्गाने नाखूष असते.

2011 मध्ये डोडो पिझ्झा व्यवसायाप्रमाणे डोडो आयएस प्रणालीचा विकास लगेचच सुरू झाला. हे व्यवसाय प्रक्रियेच्या पूर्ण आणि संपूर्ण डिजिटलायझेशनच्या कल्पनेवर आधारित होते आणि त्यांच्या स्वत: च्या वर, ज्याने 2011 मध्येही बरेच प्रश्न आणि संशय निर्माण केला होता. परंतु आता 9 वर्षांपासून आम्ही या मार्गाचे अनुसरण करत आहोत - आमच्या स्वत: च्या विकासासह, ज्याची सुरुवात एका मोनोलिथपासून झाली.

हा लेख "आर्किटेक्चर पुन्हा का लिहायचे आणि इतके मोठे आणि दीर्घकालीन बदल का करायचे?" या प्रश्नांची "उत्तर" आहे. मागील लेखाकडे परत "डोडो आयएस आर्किटेक्चरचा इतिहास: बॅक ऑफिसचा मार्ग". डोडो आयएसचा विकास कसा सुरू झाला, मूळ वास्तू कशी दिसली, नवीन मॉड्यूल कसे दिसले आणि कोणत्या समस्यांमुळे मोठ्या प्रमाणात बदल करावे लागले यापासून मी सुरुवात करेन.

लेखांची मालिका "डोडो आयएस म्हणजे काय?" याबद्दल सांगते:

1. डोडो IS (2011-2015) मधील प्रारंभिक मोनोलिथ. (तुम्ही इथे आहात)

2. मागील कार्यालयाचा मार्ग: स्वतंत्र तळ आणि बस.

3. क्लायंट साइड पथ: बेस वर दर्शनी भाग (2016-2017). (सुरू आहे...)

4. वास्तविक मायक्रोसर्व्हिसेसचा इतिहास. (2018-2019). (सुरू आहे...)

5. मोनोलिथचे पूर्ण सॉइंग आणि आर्किटेक्चरचे स्थिरीकरण. (सुरू आहे...)

प्रारंभिक आर्किटेक्चर

2011 मध्ये, डोडो IS आर्किटेक्चर असे दिसले:

आर्किटेक्चरमधील पहिले मॉड्यूल ऑर्डर स्वीकृती आहे. व्यवसाय प्रक्रिया अशी होती:

• क्लायंट पिझ्झेरियाला कॉल करतो;

• व्यवस्थापक फोन उचलतो;

• फोनद्वारे ऑर्डर स्वीकारते;

• ऑर्डर स्वीकृती इंटरफेसमध्ये समांतर भरते: क्लायंटबद्दल माहिती, ऑर्डर तपशीलावरील डेटा, वितरण पत्ता विचारात घेतला जातो. 

माहिती प्रणालीचा इंटरफेस असे काहीतरी दिसत होता ...

ऑक्टोबर 2011 पासून पहिली आवृत्ती:

जानेवारी 2012 मध्ये किंचित सुधारणा झाली

डोडो पिझ्झा माहिती प्रणाली वितरण पिझ्झा रेस्टॉरंट

प्रथम ऑर्डर घेणार्या मॉड्यूलच्या विकासासाठी संसाधने मर्यादित होती. आम्हाला त्वरीत आणि लहान संघासह बरेच काही करायचे होते. एक लहान संघ 2 विकासक आहे ज्यांनी संपूर्ण भविष्यातील प्रणालीचा पाया घातला.

त्यांच्या पहिल्या निर्णयाने तंत्रज्ञान स्टॅकचे भविष्य निश्चित केले:

• ASP.NET MVC, C# भाषेवर बॅकएंड. विकसक डॉटनेटचिकी होते, हा स्टॅक त्यांच्यासाठी परिचित आणि आनंददायी होता.

• बूटस्ट्रॅप आणि JQuery वर फ्रंटएंड: स्व-लिखित शैली आणि स्क्रिप्टवर वापरकर्ता इंटरफेस. 

• MySQL डेटाबेस: परवाना खर्च नाही, वापरण्यास सोपे.

• विंडोज सर्व्हरवरील सर्व्हर, कारण .NET नंतर फक्त Windows अंतर्गत असू शकते (आम्ही मोनोवर चर्चा करणार नाही).

शारीरिकदृष्ट्या, हे सर्व "होस्टरवर समर्पित" मध्ये व्यक्त केले गेले. 

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

मग प्रत्येकजण आधीच मायक्रोसर्व्हिसेसबद्दल बोलत होता आणि एसओएचा वापर मोठ्या प्रकल्पांमध्ये 5 वर्षांसाठी केला गेला, उदाहरणार्थ, डब्ल्यूसीएफ 2006 मध्ये रिलीज झाला. परंतु नंतर त्यांनी एक विश्वासार्ह आणि सिद्ध उपाय निवडला.

येथे आहे.

Asp.Net MVC हे रेझर आहे, जे फॉर्म किंवा क्लायंटच्या विनंतीनुसार, सर्व्हर रेंडरिंगसह HTML पृष्ठ प्रस्तुत करते. क्लायंटवर, CSS आणि JS स्क्रिप्ट आधीच माहिती प्रदर्शित करतात आणि आवश्यक असल्यास, JQuery द्वारे AJAX विनंत्या करतात.

सर्व्हरवरील विनंत्या *कंट्रोलर क्लासेसमध्ये संपतात, जिथे अंतिम HTML पृष्ठाची प्रक्रिया आणि निर्मिती पद्धतीमध्ये होते. नियंत्रक *सेवा नावाच्या तर्कशास्त्राच्या थराला विनंती करतात. प्रत्येक सेवा व्यवसायाच्या काही पैलूंशी संबंधित आहे:

• उदाहरणार्थ, डिपार्टमेंटस्ट्रक्चर सर्व्हिसने पिझ्झेरिया, विभागांवर माहिती दिली. विभाग हा पिझ्झरियाचा एक गट आहे जो एकल फ्रँचायझी चालवतो.

• ReceivingOrdersService ने ऑर्डरची रचना स्वीकारली आणि गणना केली.

• आणि SmsService ने SMS पाठवण्यासाठी API सेवांना कॉल करून एसएमएस पाठवले.

सेवांनी डेटाबेसमधून डेटावर प्रक्रिया केली, व्यवसाय तर्क संग्रहित केला. प्रत्येक सेवेमध्ये योग्य नावाचे एक किंवा अधिक *रेपॉझिटरीज असतात. त्यांच्यामध्ये डेटाबेसमध्ये संग्रहित प्रक्रिया आणि मॅपर्सचा एक स्तर आधीपासूनच प्रश्न आहेत. स्टोरेजमध्ये व्यावसायिक तर्क होता, विशेषत: ज्यांनी अहवाल डेटा जारी केला त्यांच्यामध्ये बरेच काही. ORM वापरला गेला नाही, प्रत्येकजण हाताने लिहिलेल्या sql वर अवलंबून होता. 

डोमेन मॉडेल आणि सामान्य सहाय्यक वर्गांचा एक स्तर देखील होता, उदाहरणार्थ, ऑर्डर संग्रहित करणारा ऑर्डर वर्ग. त्याच ठिकाणी, लेयरमध्ये, निवडलेल्या चलनानुसार प्रदर्शन मजकूर रूपांतरित करण्यासाठी एक मदतनीस होता.

हे सर्व अशा मॉडेलद्वारे दर्शविले जाऊ शकते:

ऑर्डर मार्ग

अशी ऑर्डर तयार करण्याचा एक सरलीकृत प्रारंभिक मार्ग विचारात घ्या.

सुरुवातीला, साइट स्थिर होती. त्यावर किंमती होत्या आणि वर - एक फोन नंबर आणि शिलालेख "तुम्हाला पिझ्झा हवा असल्यास - नंबरवर कॉल करा आणि ऑर्डर करा." ऑर्डर करण्यासाठी, आम्हाला एक साधा प्रवाह लागू करणे आवश्यक आहे: 

• क्लायंट किमतींसह स्थिर साइटला भेट देतो, उत्पादने निवडतो आणि साइटवर सूचीबद्ध केलेल्या नंबरवर कॉल करतो.

• ग्राहक त्यांना ऑर्डरमध्ये जोडू इच्छित उत्पादनांची नावे देतात.

• त्याचा पत्ता आणि नाव देतो.

• ऑपरेटर ऑर्डर स्वीकारतो.

• ऑर्डर स्वीकारलेल्या ऑर्डर इंटरफेसमध्ये प्रदर्शित केली जाते.

हे सर्व मेनू प्रदर्शित करण्यापासून सुरू होते. लॉग-इन केलेला वापरकर्ता-ऑपरेटर एका वेळी एकच ऑर्डर स्वीकारतो. म्हणून, मसुदा कार्ट त्याच्या सत्रात संग्रहित केला जाऊ शकतो (वापरकर्त्याचे सत्र मेमरीमध्ये संग्रहित केले जाते). उत्पादने आणि ग्राहक माहिती असलेली कार्ट ऑब्जेक्ट आहे.

ग्राहक उत्पादनाला नाव देतो, ऑपरेटर त्यावर क्लिक करतो + उत्पादनाच्या पुढे, आणि सर्व्हरला विनंती पाठविली जाते. उत्पादनाची माहिती डेटाबेसमधून काढली जाते आणि उत्पादनाची माहिती कार्टमध्ये जोडली जाते.

शेरा. होय, येथे आपण डेटाबेसमधून उत्पादन खेचू शकत नाही, परंतु ते फ्रंटएंडमधून हस्तांतरित करू शकता. परंतु स्पष्टतेसाठी, मी डेटाबेसमधून अचूक मार्ग दर्शविला. 

पुढे, क्लायंटचा पत्ता आणि नाव प्रविष्ट करा. 

तुम्ही "ऑर्डर तयार करा" वर क्लिक करता तेव्हा:

• विनंती OrderController.SaveOrder() वर पाठवली जाते.

• आम्हाला सत्रातून कार्ट मिळते, आम्हाला आवश्यक प्रमाणात उत्पादने आहेत.

• आम्ही कार्टला क्लायंटबद्दल माहिती पुरवतो आणि ते रिसीव्हिंगऑर्डरसर्व्हिस क्लासच्या AddOrder पद्धतीकडे पाठवतो, जिथे ते डेटाबेसमध्ये सेव्ह केले जाते. 

• डेटाबेसमध्ये ऑर्डर, ऑर्डरची रचना, क्लायंटसह टेबल असतात आणि ते सर्व जोडलेले असतात.

• ऑर्डर डिस्प्ले इंटरफेस जातो आणि नवीनतम ऑर्डर काढतो आणि प्रदर्शित करतो.

नवीन मॉड्यूल्स

ऑर्डर घेणे महत्वाचे आणि आवश्यक होते. तुमच्याकडे विक्रीची ऑर्डर नसल्यास तुम्ही पिझ्झा व्यवसाय करू शकत नाही. म्हणून, सिस्टमने कार्यक्षमता प्राप्त करण्यास सुरवात केली - अंदाजे 2012 ते 2015 पर्यंत. या वेळी, सिस्टमचे बरेच भिन्न ब्लॉक्स दिसू लागले, ज्यांना मी कॉल करेन मॉड्यूल्स, सेवा किंवा उत्पादनाच्या संकल्पनेच्या विरोधात. 

मॉड्यूल हा फंक्शन्सचा एक संच आहे जो काही सामान्य व्यावसायिक उद्दिष्टाद्वारे एकत्रित केला जातो. त्याच वेळी, ते शारीरिकदृष्ट्या समान अनुप्रयोगात आहेत.

मॉड्यूलला सिस्टम ब्लॉक्स म्हटले जाऊ शकते. उदाहरणार्थ, हे एक रिपोर्टिंग मॉड्यूल आहे, प्रशासक इंटरफेस, स्वयंपाकघर मध्ये अन्न ट्रॅकर, अधिकृतता. हे सर्व भिन्न वापरकर्ता इंटरफेस आहेत, काहींमध्ये भिन्न दृश्य शैली देखील आहेत. त्याच वेळी, सर्व काही एका अनुप्रयोगाच्या, एका चालू प्रक्रियेच्या चौकटीत आहे. 

तांत्रिकदृष्ट्या, मॉड्यूल्सची रचना क्षेत्र म्हणून केली गेली होती (अशी कल्पना देखील राहिली asp.net कोर). फ्रंटएंड, मॉडेल्स तसेच त्यांच्या स्वतःच्या कंट्रोलर क्लाससाठी स्वतंत्र फाइल्स होत्या. परिणामी, यातून प्रणालीचा कायापालट झाला ...

...यामध्ये:

काही मॉड्यूल्स वेगळ्या साइट्सद्वारे (एक्झिक्युटेबल प्रोजेक्ट) लागू केले जातात, पूर्णपणे वेगळ्या कार्यक्षमतेमुळे आणि अंशतः थोड्या वेगळ्या, अधिक केंद्रित विकासामुळे. हे:

• जागा - पहिली आवृत्ती साइट dodopizza.ru.

• निर्यात: 1C साठी Dodo IS कडून अहवाल अपलोड करत आहे. 

• वैयक्तिक - कर्मचाऱ्याचे वैयक्तिक खाते. हे स्वतंत्रपणे विकसित केले गेले आणि त्याचे स्वतःचे एंट्री पॉइंट आणि स्वतंत्र डिझाइन आहे.

• fs - होस्टिंग स्टॅटिक्ससाठी एक प्रकल्प. नंतर आम्ही सर्व स्टॅटिक्स अकामाई CDN वर हलवून त्यापासून दूर गेलो. 

बाकीचे ब्लॉक्स बॅकऑफिस ऍप्लिकेशनमध्ये होते. 

नाव स्पष्टीकरण:

• कॅशियर - रेस्टॉरंट कॅशियर.

• शिफ्ट मॅनेजर - "शिफ्ट मॅनेजर" भूमिकेसाठी इंटरफेस: पिझ्झरिया विक्रीवरील ऑपरेशनल आकडेवारी, स्टॉप लिस्टमध्ये उत्पादने ठेवण्याची क्षमता, ऑर्डर बदलणे.

• ऑफिस मॅनेजर - "पिझेरिया मॅनेजर" आणि "फ्रेंचायझी" भूमिकांसाठी इंटरफेस. पिझ्झेरिया, त्याच्या बोनस जाहिराती, कर्मचारी प्राप्त करणे आणि काम करणे, अहवाल यासाठी येथे एकत्रित कार्ये आहेत.

• पब्लिकस्क्रीन - पिझेरियामध्ये टांगलेल्या टीव्ही आणि टॅब्लेटसाठी इंटरफेस. टीव्ही डिलिव्हरी झाल्यावर मेनू, जाहिरात माहिती, ऑर्डर स्थिती प्रदर्शित करतात. 

त्यांनी एक सामान्य सेवा स्तर, एक सामान्य Dodo.Core डोमेन वर्ग ब्लॉक आणि एक सामान्य आधार वापरला. काहीवेळा ते अजूनही एकमेकांच्या संक्रमणासह नेतृत्व करू शकतात. dodopizza.ru किंवा personal.dodopizza.ru सारख्या वैयक्तिक साइट्ससह, सामान्य सेवांवर गेले.

नवीन मॉड्यूल दिसू लागल्यावर, आम्ही आधीच तयार केलेल्या सेवा कोड, संग्रहित कार्यपद्धती आणि डेटाबेसमधील टेबल्स जास्तीत जास्त वापरण्याचा प्रयत्न केला. 

सिस्टममध्ये बनवलेल्या मॉड्यूल्सच्या स्केलच्या अधिक चांगल्या प्रकारे समजून घेण्यासाठी, येथे विकास योजनांसह 2012 मधील एक आकृती आहे:

2015 पर्यंत, सर्वकाही नकाशावर होते आणि आणखी उत्पादनात होते.

• ऑर्डर स्वीकृती संपर्क केंद्राच्या वेगळ्या ब्लॉकमध्ये वाढली आहे, जिथे ऑपरेटरद्वारे ऑर्डर स्वीकारली जाते.

• पिझेरियामध्ये मेनू आणि माहिती टांगलेल्या सार्वजनिक स्क्रीन होत्या.

• किचनमध्ये एक मॉड्यूल आहे जे नवीन ऑर्डर आल्यावर "नवीन पिझ्झा" हा व्हॉइस मेसेज आपोआप प्ले करतो आणि कुरिअरसाठी इनव्हॉइस देखील प्रिंट करतो. हे स्वयंपाकघरातील प्रक्रिया मोठ्या प्रमाणात सुलभ करते, कर्मचार्यांना मोठ्या संख्येने साध्या ऑपरेशन्समुळे विचलित होऊ देत नाही.

• डिलिव्हरी ब्लॉक एक वेगळा डिलिव्हरी चेकआउट बनला, जिथे आधी शिफ्ट घेतलेल्या कुरिअरला ऑर्डर जारी केली गेली. पगाराच्या मोजणीसाठी त्याच्या कामाचा वेळ विचारात घेतला गेला. 

समांतर, 2012 ते 2015 पर्यंत, 10 पेक्षा जास्त विकसक दिसले, 35 पिझ्झेरिया उघडले, रोमानियामध्ये सिस्टम तैनात केले आणि युनायटेड स्टेट्समध्ये आउटलेट उघडण्यासाठी तयार केले. विकासक यापुढे सर्व कार्ये हाताळत नाहीत, परंतु कार्यसंघांमध्ये विभागले गेले. प्रत्येक प्रणालीच्या स्वतःच्या भागामध्ये विशेष. 

समस्या

आर्किटेक्चरमुळे (परंतु केवळ नाही) यासह.

बेस मध्ये अनागोंदी

एक आधार सोयीस्कर आहे. त्यात सुसंगतता प्राप्त केली जाऊ शकते आणि रिलेशनल डेटाबेसमध्ये तयार केलेल्या साधनांच्या खर्चावर. त्याच्यासह कार्य करणे परिचित आणि सोयीस्कर आहे, विशेषत: जर तेथे काही टेबल्स आणि थोडासा डेटा असेल.

परंतु 4 वर्षांच्या विकासादरम्यान, डेटाबेसमध्ये सुमारे 600 टेबल्स, 1500 संग्रहित प्रक्रिया असल्याचे दिसून आले, त्यापैकी अनेक तर्कशास्त्र देखील होते. अरेरे, MySQL सह कार्य करताना संचयित प्रक्रिया जास्त फायदा आणत नाहीत. ते बेसद्वारे कॅश केलेले नाहीत आणि त्यामध्ये तर्क संग्रहित केल्याने विकास आणि डीबगिंग गुंतागुंत होते. कोड पुन्हा वापरणे देखील कठीण आहे.

बर्‍याच सारण्यांमध्ये योग्य निर्देशांक नव्हते, कुठेतरी, त्याउलट, बरेच निर्देशांक होते, ज्यामुळे ते घालणे कठीण होते. सुमारे 20 टेबल्स सुधारित करणे आवश्यक होते - ऑर्डर तयार करण्यासाठी व्यवहारास सुमारे 3-5 सेकंद लागू शकतात. 

टेबलमधील डेटा नेहमीच सर्वात योग्य स्वरूपात नसतो. कुठेतरी डिनोर्मलायझेशन करणे आवश्यक होते. नियमितपणे प्राप्त झालेल्या डेटाचा एक भाग XML संरचनेच्या रूपात स्तंभात होता, यामुळे अंमलबजावणीची वेळ वाढली, प्रश्नांची लांबी वाढली आणि विकास गुंतागुंतीचा झाला.

त्याच टेबल खूप उत्पादन केले होते विषम विनंत्या. लोकप्रिय सारण्यांना विशेषतः त्रास सहन करावा लागला, वर नमूद केलेल्या तक्त्याप्रमाणे. आदेश किंवा टेबल पिझ्झा दुकान. ते स्वयंपाकघरातील ऑपरेशनल इंटरफेस, विश्लेषणे प्रदर्शित करण्यासाठी वापरले गेले. दुसर्‍या साइटने त्यांच्याशी संपर्क साधला (dodopizza.ru), जेथे कोणत्याही वेळी अनेक विनंत्या अचानक येऊ शकतात. 

डेटा एकत्रित केलेला नाही आणि बेस वापरून अनेक गणिते माशीवर झाली. यामुळे अनावश्यक गणना आणि अतिरिक्त भार निर्माण झाला. 

अनेकदा कोड डेटाबेसमध्ये गेला जेव्हा ते तसे करू शकले नसते. कुठेतरी पुरेशी मोठ्या प्रमाणात ऑपरेशन्स नव्हती, कुठेतरी वेग वाढवण्यासाठी आणि विश्वासार्हता वाढवण्यासाठी कोडद्वारे एक विनंती अनेकांमध्ये पसरवणे आवश्यक असेल. 

कोडमध्ये सुसंगतता आणि गोंधळ

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

सेवा (एका मोनोलिथिक मोठ्या प्रकल्पातील वर्ग) त्यांचा डेटा समृद्ध करण्यासाठी एकमेकांना कॉल करू शकतात.

डेटा संग्रहित करणार्‍या मॉडेल वर्गासह, कोडमधील काम वेगळ्या पद्धतीने केले गेले. कुठेतरी असे कन्स्ट्रक्टर होते ज्याद्वारे आवश्यक फील्ड निर्दिष्ट करणे शक्य होते. कुठेतरी हे सार्वजनिक मालमत्तांच्या माध्यमातून केले गेले. अर्थात, डेटाबेसमधून डेटा मिळवणे आणि त्याचे रूपांतर करणे विविध होते. 

तर्क एकतर नियंत्रकांमध्ये किंवा सेवा वर्गांमध्ये होता. 

हे किरकोळ समस्या असल्यासारखे वाटतात, परंतु त्यांनी विकासाचा वेग कमी केला आणि गुणवत्ता कमी केली, ज्यामुळे अस्थिरता आणि दोष निर्माण झाले. 

मोठ्या विकासाची जटिलता

विकासातच अडचणी निर्माण झाल्या. सिस्टमचे वेगवेगळे ब्लॉक्स आणि समांतर तयार करणे आवश्यक होते. प्रत्येक घटकाच्या गरजा एकाच कोडमध्ये बसवणे दिवसेंदिवस कठीण होत गेले. एकाच वेळी सर्व घटकांना सहमती देणे आणि खूश करणे सोपे नव्हते. यामध्ये तंत्रज्ञानाच्या मर्यादा जोडल्या गेल्या, विशेषत: बेस आणि फ्रंटएंडच्या संदर्भात. उच्च-स्तरीय फ्रेमवर्कच्या दिशेने jQuery सोडणे आवश्यक होते, विशेषत: क्लायंट सेवा (वेबसाइट) च्या बाबतीत.

प्रणालीच्या काही भागांमध्ये, यासाठी अधिक योग्य डेटाबेस वापरला जाऊ शकतो.. उदाहरणार्थ, नंतर आमच्याकडे ऑर्डर बास्केट संचयित करण्यासाठी Redis वरून CosmosDB वर जाण्याचा उपयोग झाला. 

त्यांच्या क्षेत्रातील कार्यसंघ आणि विकासकांना त्यांच्या सेवांसाठी विकास आणि रोलआउट या दोन्ही बाबतीत स्पष्टपणे अधिक स्वायत्तता हवी होती. संघर्ष विलीन करा, समस्या सोडा. जर 5 विकसकांसाठी ही समस्या क्षुल्लक असेल, तर 10 सह, आणि त्याहूनही अधिक नियोजित वाढीसह, सर्वकाही अधिक गंभीर होईल. आणि पुढे मोबाईल ऍप्लिकेशन विकसित करायचे होते (हे 2017 मध्ये सुरू झाले आणि 2018 मध्ये ते होते मोठी घसरण). 

सिस्टमच्या वेगवेगळ्या भागांना वेगवेगळ्या स्तरांची स्थिरता आवश्यक आहे, परंतु सिस्टमच्या मजबूत कनेक्टिव्हिटीमुळे, आम्ही हे प्रदान करू शकलो नाही. साइटवरील ऑर्डर स्वीकारताना अॅडमिन पॅनेलमधील नवीन फंक्शनच्या विकासामध्ये त्रुटी आली असती, कारण कोड सामान्य आणि पुन्हा वापरण्यायोग्य आहे, डेटाबेस आणि डेटा देखील समान आहेत.

अशा मोनोलिथिक-मॉड्युलर आर्किटेक्चरच्या चौकटीत या चुका आणि समस्या टाळणे शक्य आहे: जबाबदारीचे विभाजन करा, कोड आणि डेटाबेस दोन्ही रिफॅक्टर करा, स्तर एकमेकांपासून स्पष्टपणे वेगळे करा, दररोज गुणवत्तेचे निरीक्षण करा. परंतु निवडलेल्या आर्किटेक्चरल सोल्यूशन्स आणि सिस्टमच्या कार्यक्षमतेच्या जलद विस्तारावर लक्ष केंद्रित केल्यामुळे स्थिरतेच्या बाबतीत समस्या निर्माण झाल्या.

पॉवर ऑफ द माइंड ब्लॉगने रेस्टॉरंट्समध्ये कॅश रजिस्टर कसे ठेवले

जर पिझेरिया नेटवर्कची वाढ (आणि लोड) त्याच वेगाने चालू राहिली, तर काही काळानंतर फॉल्स अशा प्रकारे होईल की सिस्टम उठणार नाही. 2015 पासून आपण ज्या समस्यांना तोंड देऊ लागलो ते चांगल्या प्रकारे स्पष्ट करते, येथे अशी एक कथा आहे. 

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

• नेटवर्कमधील पिझेरियाची संख्या;

• वर्षाच्या सुरुवातीपासून एकूण नेटवर्क महसूल;

• आजसाठी महसूल.

महसुलावरील आकडेवारीची विनंती थेट डेटाबेसमध्ये गेली आणि ऑर्डरवरील डेटाची विनंती करणे, फ्लायवर डेटा एकत्रित करणे आणि रक्कम देणे सुरू केले. 

रेस्टॉरंट्समधील कॅश डेस्क ऑर्डरच्या समान टेबलवर गेले, आजसाठी प्राप्त झालेल्या ऑर्डरची यादी अनलोड केली आणि त्यात नवीन ऑर्डर जोडल्या गेल्या. कॅश रजिस्टर्सने दर 5 सेकंदांनी किंवा पेज रिफ्रेशवर त्यांच्या विनंत्या केल्या.

आकृती असे दिसले:

एक गडी बाद होण्याचा क्रम, Fyodor Ovchinnikov त्याच्या ब्लॉगवर एक लांब आणि लोकप्रिय लेख लिहिले. बरेच लोक ब्लॉगवर आले आणि सर्वकाही काळजीपूर्वक वाचू लागले. आलेले प्रत्येक लोक लेख वाचत असताना, महसूल विजेटने योग्य प्रकारे काम केले आणि प्रत्येक 20 सेकंदांनी API ची विनंती केली.

API ने नेटवर्कमधील सर्व पिझेरियासाठी वर्षाच्या सुरुवातीपासून सर्व ऑर्डरची बेरीज मोजण्यासाठी एक संग्रहित प्रक्रिया म्हटले. एकत्रीकरण ऑर्डर टेबलवर आधारित होते, जे खूप लोकप्रिय आहे. त्या वेळी सर्व खुल्या रेस्टॉरंट्सचे सर्व कॅश डेस्क त्यावर जातात. कॅश डेस्कने प्रतिसाद देणे थांबवले, ऑर्डर स्वीकारल्या गेल्या नाहीत. ते साइटवरून देखील स्वीकारले गेले नाहीत, ट्रॅकरवर दिसले नाहीत, शिफ्ट व्यवस्थापक त्यांना त्याच्या इंटरफेसमध्ये पाहू शकत नाही. 

ही एकच कथा नाही. 2015 च्या पतनापर्यंत, प्रत्येक शुक्रवारी सिस्टमवरील भार गंभीर होता. अनेक वेळा आम्ही सार्वजनिक API बंद केले आणि एकदा, आम्हाला साइट बंदही करावी लागली, कारण काहीही मदत झाली नाही. जड भाराखाली शटडाउन ऑर्डरसह सेवांची यादी देखील होती.

आतापासून, भारांसह आणि सिस्टमच्या स्थिरीकरणासाठी आमचा संघर्ष सुरू होतो (शरद ऋतूतील 2015 पासून शरद ऋतूतील 2018 पर्यंत). तेव्हा हे घडले"महान पडणे" पुढे, कधीकधी अपयश देखील आले, काही खूप संवेदनशील होते, परंतु अस्थिरतेचा सामान्य कालावधी आता उत्तीर्ण मानला जाऊ शकतो.

जलद व्यवसाय वाढ

ते लगेच का करता आले नाही? फक्त खालील तक्ते पहा.

तसेच 2014-2015 मध्ये रोमानियामध्ये एक ओपनिंग होते आणि यूएसए मध्ये एक ओपनिंग तयार केले जात होते.

नेटवर्क खूप लवकर वाढले, नवीन देश उघडले गेले, पिझेरियाचे नवीन स्वरूप दिसू लागले, उदाहरणार्थ, फूड कोर्टवर पिझेरिया उघडला गेला. या सर्वांसाठी विशेषत: डोडो आयएस फंक्शन्सच्या विस्ताराकडे लक्षणीय लक्ष देणे आवश्यक आहे. या सर्व फंक्शन्सशिवाय, किचनमध्ये ट्रॅक न करता, सिस्टममधील उत्पादनांचा आणि तोट्याचा लेखाजोखा न ठेवता, फूड कोर्ट हॉलमध्ये ऑर्डर जारी करणे प्रदर्शित केल्याशिवाय, आम्ही "योग्य" आर्किटेक्चर आणि "योग्य" दृष्टिकोनाबद्दल क्वचितच बोलत असतो. आता विकास.

आर्किटेक्चरच्या वेळेवर पुनरावृत्ती आणि सामान्यतः तांत्रिक समस्यांकडे लक्ष देण्यात आणखी एक अडथळा म्हणजे 2014 चे संकट. यासारख्या गोष्टींचा संघांच्या वाढीच्या संधींवर मोठा आघात होतो, विशेषत: डोडो पिझ्झासारख्या तरुण व्यवसायासाठी.

मदत करणारे द्रुत उपाय

समस्यांवर उपाय आवश्यक आहेत. पारंपारिकपणे, उपाय 2 गटांमध्ये विभागले जाऊ शकतात:

• जलद जे आग विझवतात आणि सुरक्षिततेचा एक छोटासा फरक देतात आणि आम्हाला बदलण्यासाठी वेळ देतात.

• पद्धतशीर आणि, म्हणून, लांब. अनेक मॉड्यूल्सचे रीइंजिनियरिंग, मोनोलिथिक आर्किटेक्चरचे स्वतंत्र सेवांमध्ये विभाजन (त्यापैकी बहुतेक सर्व सूक्ष्म नसून मॅक्रो सेवा आहेत आणि त्याबद्दल काहीतरी आहे. आंद्रे मोरेव्स्कीचा अहवाल). 

द्रुत बदलांची कोरडी यादी खालीलप्रमाणे आहे:

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

अर्थात, लोडचा सामना करण्यासाठी पहिली गोष्ट म्हणजे सर्व्हरची क्षमता वाढवणे. हे मास्टर डेटाबेस आणि वेब सर्व्हरसाठी केले गेले. अरेरे, हे एका विशिष्ट मर्यादेपर्यंतच शक्य आहे, नंतर ते खूप महाग होते.

2014 पासून, आम्ही अझूरमध्ये गेलो आहोत, आम्ही त्या वेळी या लेखात या विषयावर देखील लिहिले होते “Dodo पिझ्झा Microsoft Azure Cloud वापरून पिझ्झा कसा वितरित करतो" परंतु बेससाठी सर्व्हरमध्ये वाढीच्या मालिकेनंतर, ते खर्चाच्या विरोधात आले. 

वाचनासाठी बेस प्रतिकृती

बेससाठी दोन प्रतिकृती तयार केल्या होत्या:

प्रतिकृती वाचा संदर्भ विनंत्यांसाठी. डिरेक्टरी, प्रकार, शहर, रस्ता, पिझ्झेरिया, उत्पादने (हळूहळू बदललेले डोमेन) वाचण्यासाठी आणि ज्या इंटरफेसमध्ये थोडा विलंब स्वीकार्य असेल तेथे त्याचा वापर केला जातो. यापैकी 2 प्रतिकृती होत्या, आम्ही मास्टर्स प्रमाणेच त्यांची उपलब्धता सुनिश्चित केली.

अहवाल विनंत्यांची प्रतिकृती वाचा. या डेटाबेसची उपलब्धता कमी होती, परंतु सर्व अहवाल त्यावर गेले. त्यांना प्रचंड डेटा पुनर्गणनेसाठी भारी विनंत्या करू द्या, परंतु ते मुख्य डेटाबेस आणि ऑपरेशनल इंटरफेसवर परिणाम करत नाहीत. 

कोडमध्ये कॅशे

कोडमध्ये कुठेही कॅशे नव्हते (अजिबात). यामुळे लोड केलेल्या डेटाबेसला अतिरिक्त, नेहमी आवश्यक नसलेल्या, विनंत्या झाल्या. कॅशे प्रथम मेमरीमध्ये आणि बाह्य कॅशे सेवेवर होते, ते रेडिस होते. सर्व काही वेळेनुसार अवैध होते, सेटिंग्ज कोडमध्ये निर्दिष्ट केल्या होत्या.

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

वाढीव वर्कलोड हाताळण्यासाठी ऍप्लिकेशनच्या बॅकएंडला देखील स्केल करणे आवश्यक आहे. एका आयआयएस-सर्व्हरवरून क्लस्टर बनवणे आवश्यक होते. आम्ही पुन्हा शेड्यूल केले आहे अर्ज सत्र मेमरी ते RedisCache पर्यंत, ज्यामुळे राउंड रॉबिनसह साध्या लोड बॅलन्सरच्या मागे अनेक सर्व्हर बनवणे शक्य झाले. सुरुवातीला, त्याच रेडिसचा वापर कॅशेसाठी केला गेला, नंतर तो अनेकांमध्ये विभागला गेला. 

परिणामी, आर्किटेक्चर अधिक क्लिष्ट झाले आहे ...

… पण काही तणाव दूर झाला.

आणि मग लोड केलेले घटक पुन्हा करणे आवश्यक होते, जे आम्ही हाती घेतले. याविषयी आपण पुढच्या भागात बोलू.

स्त्रोत: www.habr.com