डोडो IS वास्तुकलाको इतिहास: एक प्रारम्भिक मोनोलिथ

वा मोनोलिथको साथ प्रत्येक दुखी कम्पनी आफ्नै तरिकामा दुखी छ।

डोडो IS प्रणालीको विकास तुरुन्तै सुरु भयो, डोडो पिज्जा व्यवसाय जस्तै, २०११ मा। यो व्यापार प्रक्रियाहरूको पूर्ण र कुल डिजिटलाइजेशनको विचारमा आधारित थियो, र आफ्नै मा, जुन 2011 मा पनि धेरै प्रश्न र शंका उत्पन्न भयो। तर अहिले ९ वर्षदेखि हामी यही बाटो पछ्याउँदै आएका छौं - आफ्नै विकासको साथ, जुन मोनोलिथबाट सुरु भएको थियो।

यो लेख प्रश्नहरूको "उत्तर" हो "किन वास्तुकला पुन: लेख्नुहोस् र यति ठूलो र दीर्घकालीन परिवर्तनहरू गर्नुहोस्?" अघिल्लो लेखमा फर्कनुहोस् "डोडो IS वास्तुकलाको इतिहास: ब्याक अफिसको बाटो"। म Dodo IS को विकास कसरी सुरु भयो, मूल वास्तुकला कस्तो देखिन्थ्यो, नयाँ मोड्युलहरू कसरी देखा पर्‍यो, र कस्ता समस्याहरूको कारणले गर्दा ठूला-ठूला परिवर्तनहरू गर्नुपर्‍यो भनेर सुरु गर्नेछु।

लेखहरूको श्रृंखला "डोडो IS के हो?" बारेमा बताउँछ:

1. डोडो आईएस (२०११-२०१५) मा प्रारम्भिक मोनोलिथ। (तिमि यहाँ छौ)

2. पछाडिको कार्यालय मार्ग: छुट्टै बेस र बस.

3. ग्राहक पक्ष मार्ग: आधार माथि अनुहार (2016-2017)। (प्रगति हुदैछ...)

4. वास्तविक microservices को इतिहास। (२०१८-२०१९)। (प्रगति हुदैछ...)

5. मोनोलिथको आरा र वास्तुकलाको स्थिरीकरण समाप्त भयो। (प्रगति हुदैछ...)

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

2011 मा, डोडो IS वास्तुकला यस्तो देखिन्थ्यो:

आर्किटेक्चरमा पहिलो मोड्युल अर्डर स्वीकृति हो। व्यापार प्रक्रिया थियो:

• ग्राहकले पिज्जेरियालाई कल गर्दछ;

• प्रबन्धकले फोन उठाए;

• फोन द्वारा अर्डर स्वीकार गर्दछ;

• यसलाई अर्डर स्वीकृति इन्टरफेसमा समानान्तर रूपमा भर्दछ: यसले ग्राहकको बारेमा जानकारी, अर्डर विवरणहरूमा डेटा, डेलिभरी ठेगानालाई ध्यानमा राख्छ। 

सूचना प्रणालीको इन्टरफेस यस्तो देखियो ...

अक्टोबर 2011 देखि पहिलो संस्करण:

जनवरी 2012 मा थोरै सुधार भयो

डोडो पिज्जा सूचना प्रणाली डेलिभरी पिज्जा भोजनालय

पहिलो अर्डर लिने मोड्युलको विकासको लागि स्रोतहरू सीमित थिए। हामीले छिटो र सानो टोलीसँग धेरै काम गर्नुपर्‍यो। एउटा सानो टोली भनेको 2 विकासकर्ताहरू हुन् जसले सम्पूर्ण भविष्य प्रणालीको लागि जग राखेका छन्।

तिनीहरूको पहिलो निर्णयले टेक्नोलोजी स्ट्याकको भाग्य निर्धारण गर्यो:

• ASP.NET MVC, C# भाषामा ब्याकइन्ड। विकासकर्ताहरू dotnetchiki थिए, यो स्ट्याक तिनीहरूलाई परिचित र सुखद थियो।

• बुटस्ट्र्याप र JQuery मा फ्रन्टएन्ड: स्व-लिखित शैलीहरू र स्क्रिप्टहरूमा प्रयोगकर्ता इन्टरफेसहरू। 

• MySQL डाटाबेस: कुनै इजाजतपत्र लागत छैन, प्रयोग गर्न सजिलो।

• Windows सर्भरमा सर्भरहरू, किनभने .NET त्यसपछि Windows अन्तर्गत मात्र हुन सक्छ (हामी Mono छलफल गर्दैनौं)।

भौतिक रूपमा, यो सबै "होस्टरमा समर्पित" मा व्यक्त गरिएको थियो। 

अर्डर इनटेक आवेदन आर्किटेक्चर

त्यसपछि सबैले पहिले नै माइक्रोसर्विसेसको बारेमा कुरा गरिरहेका थिए, र SOA 5 वर्षको लागि ठूला परियोजनाहरूमा प्रयोग गरिएको थियो, उदाहरणका लागि, WCF 2006 मा जारी गरिएको थियो। तर तिनीहरूले भरपर्दो र प्रमाणित समाधान रोजे।

यहाँ छ।

Asp.Net MVC रेजर हो, जसले फारम वा ग्राहकबाट अनुरोधमा, सर्भर रेन्डरिङको साथ HTML पृष्ठ रेन्डर गर्दछ। क्लाइन्टमा, CSS र JS स्क्रिप्टहरूले पहिले नै जानकारी प्रदर्शन गर्दछ र आवश्यक भएमा, JQuery मार्फत AJAX अनुरोधहरू प्रदर्शन गर्दछ।

सर्भरमा अनुरोधहरू *कन्ट्रोलर कक्षाहरूमा समाप्त हुन्छ, जहाँ अन्तिम HTML पृष्ठको प्रक्रिया र उत्पादन विधिमा हुन्छ। नियन्त्रकहरूले *सेवाहरू नामक तर्कको तहमा अनुरोध गर्छन्। प्रत्येक सेवाहरू व्यवसायको केही पक्षसँग मेल खान्छ:

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

• ReceivingOrdersService ले स्वीकृत गर्यो र अर्डरको संरचना गणना गर्यो।

• र SmsService ले एपीआई सेवाहरूलाई कल गरेर एसएमएस पठाउनको लागि एसएमएस पठायो।

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

त्यहाँ डोमेन मोडेल र साझा सहायक वर्गहरूको एक तह पनि थियो, उदाहरणका लागि, अर्डर वर्ग जसले अर्डर भण्डारण गर्छ। एउटै ठाउँमा, तहमा, चयन गरिएको मुद्रा अनुसार प्रदर्शन पाठ रूपान्तरण गर्न एक सहायक थियो।

यो सबै यस्तो मोडेल द्वारा प्रतिनिधित्व गर्न सकिन्छ:

अर्डर मार्ग

यस्तो आदेश सिर्जना गर्न एक सरल प्रारम्भिक तरिका विचार गर्नुहोस्।

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

• ग्राहकले मूल्यको साथ स्थिर साइट भ्रमण गर्दछ, उत्पादनहरू चयन गर्दछ र साइटमा सूचीबद्ध नम्बरलाई कल गर्दछ।

• ग्राहकले अर्डरमा थप्न चाहने उत्पादनहरूको नाम दिन्छ।

• आफ्नो ठेगाना र नाम दिन्छ।

• अपरेटरले अर्डर स्वीकार गर्दछ।

• अर्डर स्वीकृत अर्डर इन्टरफेसमा प्रदर्शित हुन्छ।

यो सबै मेनु प्रदर्शन संग सुरु हुन्छ। लग-इन गरिएको प्रयोगकर्ता-अपरेटरले एक पटकमा एउटा मात्र अर्डर स्वीकार गर्दछ। त्यसकारण, ड्राफ्ट कार्ट उसको सत्रमा भण्डारण गर्न सकिन्छ (प्रयोगकर्ताको सत्र मेमोरीमा भण्डार गरिएको छ)। त्यहाँ उत्पादन र ग्राहक जानकारी समावेश कार्ट वस्तु छ।

ग्राहकले उत्पादनको नाम दिन्छ, अपरेटरले क्लिक गर्दछ + उत्पादनको छेउमा, र सर्भरमा अनुरोध पठाइन्छ। उत्पादनको बारेमा जानकारी डाटाबेसबाट निकालिन्छ र उत्पादनको बारेमा जानकारी कार्टमा थपिन्छ।

भन्नु। हो, यहाँ तपाइँ डाटाबेसबाट उत्पादन तान्न सक्नुहुन्न, तर यसलाई फ्रन्टएन्डबाट स्थानान्तरण गर्नुहोस्। तर स्पष्टताको लागि, मैले डाटाबेसबाट ठ्याक्कै बाटो देखाएँ। 

अर्को, ग्राहकको ठेगाना र नाम प्रविष्ट गर्नुहोस्। 

जब तपाइँ "अर्डर सिर्जना गर्नुहोस्" मा क्लिक गर्नुहुन्छ:

• अनुरोध OrderController.SaveOrder() मा पठाइएको छ।

• हामीले सत्रबाट कार्ट पाउँछौं, हामीलाई आवश्यक मात्रामा उत्पादनहरू छन्।

• हामी ग्राहकको बारेमा जानकारीको साथ कार्टलाई पूरक गर्छौं र यसलाई रिसिभिङ अर्डरसर्भिस क्लासको AddOrder विधिमा पास गर्छौं, जहाँ यो डाटाबेसमा सुरक्षित हुन्छ। 

• डाटाबेससँग अर्डर, अर्डरको संरचना, क्लाइन्ट, र ती सबै जडान भएका तालिकाहरू छन्।

• अर्डर डिस्प्ले इन्टरफेस जान्छ र नवीनतम अर्डरहरू बाहिर निकाल्छ र तिनीहरूलाई प्रदर्शन गर्दछ।

नयाँ मोड्युलहरू

आदेश लिनु महत्त्वपूर्ण र आवश्यक थियो। यदि तपाइँसँग बेच्ने अर्डर छैन भने तपाइँ पिज्जा व्यवसाय गर्न सक्नुहुन्न। त्यसकारण, प्रणालीले कार्यक्षमता प्राप्त गर्न थाल्यो - लगभग 2012 देखि 2015 सम्म। यस समयमा, प्रणालीको धेरै फरक ब्लकहरू देखा पर्यो, जुन म कल गर्नेछु मोड्युलहरूसेवा वा उत्पादनको अवधारणाको विपरीत। 

एक मोड्युल कार्यहरूको एक सेट हो जुन केहि साझा व्यापार लक्ष्य द्वारा एकजुट हुन्छ। एकै समयमा, तिनीहरू शारीरिक रूपमा एउटै अनुप्रयोगमा छन्।

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

प्राविधिक रूपमा, मोड्युलहरू क्षेत्रको रूपमा डिजाइन गरिएको थियो (यस्तो विचार पनि रह्यो asp.net कोर)। त्यहाँ फ्रन्टएन्ड, मोडेलहरू, साथै तिनीहरूको आफ्नै नियन्त्रक वर्गहरूको लागि छुट्टै फाइलहरू थिए। नतिजाको रूपमा, यसबाट प्रणाली परिवर्तन भयो ...

...यसमा:

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

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

• निर्यात: 1C को लागि Dodo IS बाट रिपोर्टहरू अपलोड गर्दै। 

• व्यक्तिगत - कर्मचारी को व्यक्तिगत खाता। यो छुट्टै विकसित गरिएको थियो र यसको आफ्नै प्रवेश बिन्दु र छुट्टै डिजाइन छ।

• fs - होस्टिंग स्ट्याटिक्स को लागी एक परियोजना। पछि हामी सबै तथ्याङ्कहरूलाई अकामाई सीडीएनमा सार्दै यसबाट टाढा गयौं। 

बाँकी ब्लकहरू BackOffice अनुप्रयोगमा थिए। 

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

• क्यासियर - रेस्टुरेन्ट क्यासियर।

• ShiftManager - "Shift Manager" भूमिकाका लागि इन्टरफेसहरू: पिज्जेरिया बिक्रीमा परिचालन तथ्याङ्कहरू, उत्पादनहरूलाई स्टप सूचीमा राख्ने क्षमता, क्रम परिवर्तन गर्नुहोस्।

• OfficeManager - "Pizzeria Manager" र "Franchisee" भूमिकाहरूका लागि इन्टरफेसहरू। यहाँ पिज्जेरिया, यसको बोनस प्रमोशनहरू, कर्मचारीहरू प्राप्त गर्ने र काम गर्ने, रिपोर्टहरू सेटअप गर्नका लागि कार्यहरू सङ्कलन गरिएका छन्।

• सार्वजनिक स्क्रिनहरू - टिभी र पिज्जेरियाहरूमा झुण्डिएका ट्याब्लेटहरूका लागि इन्टरफेसहरू। टिभीहरूले मेनुहरू, विज्ञापन जानकारी, डेलिभरीमा अर्डर स्थिति प्रदर्शन गर्दछ। 

तिनीहरूले एक साझा सेवा तह, एक साझा 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 मा गएर अनुरोध गरियो:

• नेटवर्क मा pizzerias को संख्या;

• वर्षको सुरुदेखि कुल नेटवर्क राजस्व;

• आजको लागि राजस्व।

राजस्वको तथ्याङ्कको लागि अनुरोध सीधै डाटाबेसमा गयो र अर्डरमा डाटा अनुरोध गर्न थाल्यो, उडानमा डाटा जम्मा गर्दै र रकम दिन थाल्यो। 

रेस्टुरेन्टहरूमा नगद डेस्कहरू अर्डरहरूको एउटै तालिकामा गए, आजको लागि प्राप्त अर्डरहरूको सूची अनलोड गरियो, र यसमा नयाँ अर्डरहरू थपियो। नगद दर्ताहरूले प्रत्येक 5 सेकेन्डमा वा पृष्ठ रिफ्रेसमा आफ्नो अनुरोधहरू गरे।

रेखाचित्र यस्तो देखिन्थ्यो:

एक पतन, Fyodor Ovchinnikov आफ्नो ब्लग मा एक लामो र लोकप्रिय लेख लेखे। धेरै मानिसहरू ब्लगमा आए र सबै कुरा ध्यानपूर्वक पढ्न थाले। आएका प्रत्येक व्यक्तिले लेख पढिरहेको बेला, राजस्व विजेटले ठीकसँग काम गर्‍यो र प्रत्येक २० सेकेन्डमा API अनुरोध गर्‍यो।

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

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

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

द्रुत व्यापार वृद्धि

किन तुरुन्तै गर्न सकिएन ? केवल निम्न चार्टहरू हेर्नुहोस्।

2014-2015 मा पनि रोमानियामा उद्घाटन भएको थियो र संयुक्त राज्य अमेरिकामा उद्घाटनको तयारी भइरहेको थियो।

नेटवर्क धेरै चाँडै बढ्यो, नयाँ देशहरू खोलियो, पिज्जेरियाका नयाँ ढाँचाहरू देखा पर्यो, उदाहरणका लागि, खाना अदालतमा पिज्जेरिया खोलियो। यी सबैले डोडो IS कार्यहरूको विस्तारमा विशेष ध्यान दिनु आवश्यक छ। यी सबै प्रकार्यहरू बिना, भान्साकोठामा ट्र्याक नगरी, प्रणालीमा उत्पादनहरू र हानिहरूको लेखाजोखा नगरी, फूड कोर्ट हलमा अर्डर जारी गर्ने प्रदर्शन, हामीले "सही" वास्तुकला र "सही" दृष्टिकोणको बारेमा कुरा गर्दैनौं। अब विकास।

वास्तुकलाको समयमै संशोधन र सामान्यतया प्राविधिक समस्याहरूमा ध्यान दिन अर्को बाधा 2014 को संकट थियो। यस प्रकारका चीजहरूले टोलीहरू बढ्नका लागि अवसरहरूमा कडा असर गर्छ, विशेष गरी डोडो पिज्जा जस्ता युवा व्यवसायका लागि।

मद्दत गर्ने द्रुत समाधानहरू

समस्या समाधान आवश्यक छ। परम्परागत रूपमा, समाधानहरू 2 समूहहरूमा विभाजित गर्न सकिन्छ:

• आगो निभाउने र सुरक्षाको सानो मार्जिन दिने र हामीलाई परिवर्तन गर्न समय किन्ने छिटो।

• प्रणालीगत र, त्यसैले, लामो। धेरै मोड्युलहरूको पुन: इन्जिनियरिङ, एक मोनोलिथिक वास्तुकलालाई अलग-अलग सेवाहरूमा विभाजन गर्नुहोस् (तिनीहरूमध्ये धेरैजसो माइक्रो होइन, बरु म्याक्रो सेवाहरू छन्, र त्यहाँ यसको बारेमा केहि छ। Andrey Morevskiy रिपोर्ट). 

द्रुत परिवर्तनहरूको सुक्खा सूची निम्नानुसार छ:

आधार मास्टर मापन गर्नुहोस्

निस्सन्देह, लोडसँग सम्झौता गर्न पहिलो कुरा सर्भरको क्षमता बढाउनु हो। यो मास्टर डाटाबेस र वेब सर्भरहरूको लागि गरिएको थियो। काश, यो एक निश्चित सीमा सम्म मात्र सम्भव छ, त्यसपछि यो धेरै महँगो हुन्छ।

2014 देखि, हामी Azure मा सरेका छौं, हामीले लेखमा त्यस समयमा यस विषयमा लेखेका थियौं "कसरी डोडो पिज्जाले Microsoft Azure क्लाउड प्रयोग गरेर पिज्जा डेलिभर गर्छ"। तर आधार को लागी सर्भर मा वृद्धि को एक श्रृंखला पछि, तिनीहरू लागत विरुद्ध आए। 

पढ्नको लागि आधार प्रतिकृतिहरू

आधारको लागि दुई प्रतिकृतिहरू बनाइएका थिए:

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

रिपोर्ट अनुरोधहरूको लागि प्रतिकृति पढ्नुहोस्। यो डाटाबेस कम उपलब्धता थियो, तर सबै रिपोर्टहरू यसमा गए। तिनीहरूलाई ठूलो डेटा पुन: गणनाको लागि भारी अनुरोधहरू गर्न दिनुहोस्, तर तिनीहरूले मुख्य डाटाबेस र परिचालन इन्टरफेसहरूलाई असर गर्दैनन्। 

कोडमा क्यासहरू

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

बहु ब्याकइन्ड सर्भरहरू

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

नतिजाको रूपमा, वास्तुकला थप जटिल भएको छ ...

तर केही तनाव हट्यो।

र त्यसपछि लोड गरिएका कम्पोनेन्टहरू पुन: गर्न आवश्यक थियो, जुन हामीले लियौं। यस विषयमा हामी अर्को भागमा कुरा गर्नेछौं।

स्रोत: www.habr.com