डोडो IS वास्तुकलाको इतिहास: ब्याक अफिस पथ

Habr संसार परिवर्तन गर्दैछ। हामीले ब्लगिङ गरेको एक वर्षभन्दा बढी भइसक्यो। करिब छ महिना अघि, हामीले Khabrovites बाट पूर्णतया तार्किक प्रतिक्रिया प्राप्त गर्यौं: "डोडो, तपाईं जताततै भन्नुहुन्छ कि तपाईंको आफ्नै प्रणाली छ। र यो प्रणाली के हो? र पिज्जा चेन किन चाहिन्छ?

हामी बस्यौं, सोच्यौं र बुझ्यौं कि तपाईं सही हुनुहुन्छ। हामी हाम्रो औंलाहरूमा सबै कुरा व्याख्या गर्ने प्रयास गर्छौं, तर यो च्यातिएको टुक्राहरूमा बाहिर आउँछ र प्रणालीको पूर्ण विवरण कतै छैन। यसरी डोडो आईएसको बारेमा जानकारी सङ्कलन, लेखकहरूको खोजी र लेखहरूको श्रृंखला लेख्ने लामो यात्रा सुरु भयो। जाऔं!

स्वीकृतिहरू: हामीसँग तपाईंको प्रतिक्रिया साझा गर्नुभएकोमा धन्यवाद। उहाँलाई धन्यवाद, हामीले अन्ततः प्रणालीको वर्णन गर्यौं, प्राविधिक रडार कम्पाइल गर्यौं र चाँडै हाम्रो प्रक्रियाहरूको ठूलो विवरण रोल आउट गर्नेछौं। तिमी नभएको भए हामी अझै ५ वर्ष बस्ने थियौं ।

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

1. डोडो आईएस (२०११-२०१५) मा प्रारम्भिक मोनोलिथ। (प्रगति हुदैछ...)
2. पछाडिको कार्यालय मार्ग: अलग आधार र बस। (तिमि यहाँ छौ)
3. ग्राहक पक्ष मार्ग: आधार माथि अनुहार (2016-2017)। (प्रगति हुदैछ...)
4. वास्तविक microservices को इतिहास। (२०१८-२०१९)। (प्रगति हुदैछ...)
5. मोनोलिथको आरा र वास्तुकलाको स्थिरीकरण समाप्त भयो। (प्रगति हुदैछ...)

यदि तपाइँ अरू केहि जान्न इच्छुक हुनुहुन्छ भने - टिप्पणीहरूमा लेख्नुहोस्।

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

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

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

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

2020 सम्म, यो अलि बढी जटिल भएको छ र यस्तो भएको छ:

यो विकास कसरी भयो? प्रणालीको विभिन्न भागहरू किन आवश्यक छ? के वास्तु निर्णयहरू गरियो र किन? लेखहरूको यो श्रृंखलामा पत्ता लगाउनुहोस्।

2016 को पहिलो समस्या: किन सेवाहरू मोनोलिथ छोड्नु पर्छ

चक्रबाट पहिलो लेखहरू मोनोलिथबाट अलग हुने पहिलो सेवाहरूको बारेमा हुनेछ। तपाइँलाई सन्दर्भमा राख्नको लागि, म तपाइँलाई 2016 को सुरुमा प्रणालीमा कस्ता समस्याहरू थिए, जुन हामीले सेवाहरूको विभाजनको सामना गर्नुपर्‍यो भनेर बताउनेछु।

एकल MySql डाटाबेस, जसमा डोडो IS मा त्यस समयमा अवस्थित सबै अनुप्रयोगहरूले तिनीहरूको रेकर्ड लेखेका थिए। परिणामहरू थिए:

• भारी लोड (अनुरोधहरूको 85% पढ्नको लागि लेखिएको)।
• आधार बढेको छ । जसका कारण यसको लागत र सहयोग समस्या भएको छ ।
• असफलताको एकल बिन्दु। यदि डेटाबेसमा लेख्ने एउटा अनुप्रयोगले अचानक यसलाई अझ सक्रिय रूपमा गर्न थाल्यो भने, त्यसपछि अन्य अनुप्रयोगहरूले यसलाई आफैंमा महसुस गरे।
• भण्डारण र प्रश्नहरूमा असक्षमता। प्रायः डाटा केहि संरचनामा भण्डार गरिएको थियो जुन केहि परिदृश्यहरूको लागि सुविधाजनक थियो तर अरूको लागि उपयुक्त थिएन। अनुक्रमणिकाले केही कार्यहरू गति दिन्छ, तर अरूलाई ढिलो गर्न सक्छ।
• केही समस्याहरू हतारमा बनाइएका क्यासहरू र आधारहरूमा पढ्ने-प्रतिकृतिहरू हटाए (यो छुट्टै लेख हुनेछ), तर तिनीहरूले तिनीहरूलाई केवल समय प्राप्त गर्न अनुमति दिए र मौलिक रूपमा समस्या समाधान गरेनन्।

समस्या मोनोलिथको उपस्थिति थियो। परिणामहरू थिए:

• एकल र दुर्लभ रिलीज।
• ठूलो संख्यामा मानिसहरूको संयुक्त विकासमा कठिनाइ।
• नयाँ प्रविधि, नयाँ ढाँचा र पुस्तकालयहरू ल्याउन असक्षमता।

आधार र मोनोलिथसँग समस्याहरू धेरै पटक वर्णन गरिएको छ, उदाहरणका लागि, 2018 को प्रारम्भमा दुर्घटनाहरूको सन्दर्भमा (Munch जस्तै हुनुहोस्, वा प्राविधिक ऋण बारे केही शब्दहरू, Dodo IS रोकिएको दिन। एसिन्क्रोनस लिपि и फीनिक्स परिवारबाट डोडो चराको कथा। डोडो IS को ठूलो पतन), त्यसैले म धेरै बस्ने छैन। म केवल भन्न चाहन्छु कि हामी सेवाहरू विकास गर्दा थप लचिलोपन दिन चाहन्छौं। सबैभन्दा पहिले, यसले ती व्यक्तिहरूलाई चिन्तित गर्‍यो जुन सम्पूर्ण प्रणालीमा सबैभन्दा लोड र रूट थिए - Auth र Tracker।

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

अध्याय नेभिगेसन

1. मोनोलिथ योजना 2016
2. मोनोलिथ अनलोड गर्न सुरु गर्दै: प्रमाण र ट्र्याकर विभाजन
   
3. Auth ले के गर्छ?
4. भारहरू कहाँबाट आउँछन्?
5. प्रमाण अनलोड गर्दै
6. ट्र्याकरले के गर्छ?
7. भारहरू कहाँबाट आउँछन्?
8. ट्र्याकर अनलोड गर्दै

मोनोलिथ योजना 2016

यहाँ डोडो IS 2016 मोनोलिथका मुख्य ब्लकहरू छन्, र तल तिनीहरूको मुख्य कार्यहरूको ट्रान्सक्रिप्ट छ।

क्यासियर वितरण। कुरियरहरूको लागि लेखा, कुरियरहरूलाई आदेश जारी गर्दै।
सम्पर्क केन्द्र। अपरेटर मार्फत आदेश को स्वीकृति।
साइट। हाम्रो वेबसाइटहरू (dodopizza.ru, dodopizza.co.uk, dodopizza.by, आदि)।
Auth। ब्याक अफिसको लागि प्राधिकरण र प्रमाणीकरण सेवा।
ट्रयाकर। भान्सामा ट्रयाकर अर्डर गर्नुहोस्। अर्डर तयार गर्दा तत्परता स्थिति चिन्ह लगाउन सेवा।
रेस्टुरेन्टको नगद डेस्क। रेस्टुरेन्ट, क्यासियर इन्टरफेसमा अर्डर लिँदै।
निर्यात। लेखाको लागि 1C मा रिपोर्टहरू अपलोड गर्दै।
सूचनाहरू र इनभ्वाइसहरू। भान्सामा आवाज आदेशहरू (उदाहरणका लागि, "नयाँ पिज्जा आइपुग्यो") + कुरियरहरूको लागि इनभ्वाइस प्रिन्टिङ।
शिफ्ट प्रबन्धक। शिफ्ट प्रबन्धकको कामको लागि इन्टरफेसहरू: आदेशहरूको सूची, कार्यसम्पादन ग्राफहरू, शिफ्टमा कर्मचारीहरूको स्थानान्तरण।
कार्यालय ब्यबस्थापक। फ्रान्चाइजी र प्रबन्धकको कामको लागि इन्टरफेस: कर्मचारीहरूको स्वागत, पिज्जेरियाको काममा रिपोर्टहरू।
भोजनालय स्कोरबोर्ड। पिज्जेरियाहरूमा टिभीहरूमा मेनु प्रदर्शन।
व्यवस्थापक। विशिष्ट पिज्जेरियामा सेटिङहरू: मेनु, मूल्यहरू, लेखा, प्रोमो कोडहरू, प्रचारहरू, वेबसाइट ब्यानरहरू, आदि।
कर्मचारीको व्यक्तिगत खाता। कर्मचारीहरूको कार्य तालिका, कर्मचारीहरूको बारेमा जानकारी।
भान्सा प्रेरणा बोर्ड। एउटा छुट्टै स्क्रिन जसले भान्साकोठामा झुण्डिएको छ र पिज्जा निर्माताहरूको गति देखाउँछ।
सञ्चार। एसएमएस र इमेल पठाउँदै।
फाइल भण्डारण। स्थिर फाइलहरू प्राप्त गर्न र जारी गर्नको लागि आफ्नै सेवा।

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

मोनोलिथ अनलोड गर्न सुरु गर्दै: प्रमाण र ट्र्याकर विभाजन

मुख्य सेवाहरू जुन त्यसपछि रेकर्ड र डाटाबेसबाट अन्य भन्दा बढी पढ्छन्:

1. प्रमाण। ब्याक अफिसको लागि प्राधिकरण र प्रमाणीकरण सेवा।
2. ट्र्याकर। भान्सामा ट्रयाकर अर्डर गर्नुहोस्। अर्डर तयार गर्दा तत्परता स्थिति चिन्ह लगाउन सेवा।

Auth ले के गर्छ?

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

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

भारहरू कहाँबाट आउँछन्?

ब्याक अफिसको प्रत्येक लग इन प्रयोगकर्ता डाटाबेसमा जान्छ, प्रत्येक अनुरोधको लागि प्रयोगकर्ता तालिकामा, प्रयोगकर्तालाई sql क्वेरी मार्फत बाहिर निकाल्छ र जाँच गर्दछ कि उनीसँग यस पृष्ठमा आवश्यक पहुँच र अधिकार छ कि छैन।

प्रत्येक उपकरणले यन्त्र तालिकाको साथ मात्र गर्छ, यसको भूमिका र पहुँच जाँच गर्दै। मास्टर डाटाबेसमा अनुरोधहरूको ठूलो संख्याले यसको लोडिङ र यी अपरेसनहरूको लागि साझा डाटाबेसको स्रोतहरूको बर्बादीतर्फ लैजान्छ।

प्रमाण अनलोड गर्दै

Auth सँग पृथक डोमेन छ, त्यो हो, प्रयोगकर्ताहरू, लगइनहरू वा उपकरणहरू बारे डाटा सेवामा प्रवेश गर्दछ (अहिलेको लागि) र त्यहाँ रहन्छ। यदि कसैलाई आवश्यक छ भने, उसले डाटाको लागि यो सेवामा जानेछ।

WAS। कामको मूल योजना निम्नानुसार थियो:

म यो कसरी काम गर्यो भनेर थोरै व्याख्या गर्न चाहन्छु:

1. बाहिरबाट एउटा अनुरोध ब्याकइन्डमा आउँछ (त्यहाँ Asp.Net MVC छ), यसले एक सत्र कुकी ल्याउँछ, जुन Redis(1) बाट सत्र डेटा प्राप्त गर्न प्रयोग गरिन्छ। यसले या त पहुँचहरूको बारेमा जानकारी समावेश गर्दछ, र त्यसपछि नियन्त्रकमा पहुँच खुला छ (3,4), वा छैन।
2. यदि त्यहाँ पहुँच छैन भने, तपाईंले प्राधिकरण प्रक्रिया मार्फत जान आवश्यक छ। यहाँ, सरलताको लागि, यसलाई एउटै विशेषतामा मार्गको अंशको रूपमा देखाइएको छ, यद्यपि यो लगइन पृष्ठमा संक्रमण हो। एक सकारात्मक परिदृश्य को मामला मा, हामी एक सही पूरा सत्र प्राप्त हुनेछ र Backoffice नियन्त्रक जान्छौं।
3. यदि त्यहाँ डाटा छ भने, तपाइँ यसलाई प्रयोगकर्ता आधारमा सान्दर्भिकताको लागि जाँच गर्न आवश्यक छ। के उनको भूमिका परिवर्तन भयो, अब उसलाई पृष्ठमा अनुमति दिनु हुँदैन? यस अवस्थामा, सत्र (1) प्राप्त गरेपछि, तपाइँ सीधै डाटाबेसमा जानु पर्छ र प्रमाणीकरण तर्क तह (2) प्रयोग गरेर प्रयोगकर्ताको पहुँच जाँच गर्न आवश्यक छ। अर्को, या त लगइन पृष्ठमा, वा नियन्त्रकमा जानुहोस्। यस्तो सरल प्रणाली, तर एकदम मानक छैन।
4. यदि सबै प्रक्रियाहरू पारित भएमा, त्यसपछि हामी नियन्त्रकहरू र विधिहरूमा तर्कमा छोड्छौं।

प्रयोगकर्ता डेटा अन्य सबै डेटाबाट अलग गरिएको छ, यो छुट्टै सदस्यता तालिकामा भण्डारण गरिएको छ, AuthService तर्क तहबाट कार्यहरू राम्रोसँग एपीआई विधिहरू बन्न सक्छन्। डोमेन सीमाहरू एकदम स्पष्ट रूपमा परिभाषित गरिएको छ: प्रयोगकर्ताहरू, तिनीहरूको भूमिकाहरू, पहुँच डेटा, पहुँच प्रदान गर्ने र रद्द गर्ने। सबै कुरा यस्तो देखिन्छ कि यसलाई छुट्टै सेवामा लिन सकिन्छ।

बन्नुहोस्। त्यसैले तिनीहरूले गरे:

यो दृष्टिकोणमा धेरै समस्याहरू छन्। उदाहरणका लागि, प्रक्रिया भित्रको विधि कल गर्नु भनेको http मार्फत बाह्य सेवालाई कल गर्नु जस्तै होइन। विलम्बता, विश्वसनीयता, रखरखाव, सञ्चालनको पारदर्शिता पूर्ण रूपमा फरक छन्। Andrey Morevskiy आफ्नो रिपोर्ट मा यस्ता समस्याहरु को बारे मा अधिक विस्तार मा बोल्यो। "माइक्रोसर्भिसेसको ५० शेड्स".

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

बिछोडलाई किन यति लामो समय लाग्यो ?
बाटोमा धेरै समस्याहरू थिए जसले हामीलाई सुस्त बनायो:

1. हामी देश-विशिष्ट डाटाबेसबाट प्रयोगकर्ता, उपकरण, र प्रमाणीकरण डाटा एकमा सार्न चाहन्छौं। यो गर्नको लागि, हामीले सबै तालिकाहरू र प्रयोगलाई int पहिचानकर्ताबाट विश्वव्यापी UUId पहिचानकर्तामा अनुवाद गर्नुपर्‍यो (हालसालै यो कोड पुन: कार्य गरियो। रोमन बुकिन "Uuid - एक सानो संरचना को एक ठूलो कथा" र खुला स्रोत परियोजना आदिम)। प्रयोगकर्ता डेटा भण्डारण गर्ने (यो व्यक्तिगत जानकारी भएकोले) यसको सीमितताहरू छन् र केही देशहरूको लागि तिनीहरूलाई छुट्टै भण्डारण गर्न आवश्यक छ। तर प्रयोगकर्ताको ग्लोबल आइडी हुनुपर्छ।
2. डाटाबेसका धेरै तालिकाहरूमा सञ्चालन गर्ने प्रयोगकर्ताको बारेमा लेखापरीक्षण जानकारी हुन्छ। यसले स्थिरताको लागि थप संयन्त्र आवश्यक थियो।
3. एपीआई-सेवाहरूको सिर्जना पछि, अर्को प्रणालीमा संक्रमणको लामो र क्रमिक अवधि थियो। स्विचिंग प्रयोगकर्ताहरू र आवश्यक म्यानुअल कामको लागि निर्बाध हुनुपर्छ।

पिज्जेरियामा उपकरण दर्ता योजना:

प्रमाणीकरण र उपकरण सेवा को निकासी पछि सामान्य वास्तुकला:

भन्नु। २०२० को लागि, हामी Auth को नयाँ संस्करणमा काम गरिरहेका छौं, जुन OAuth 2020 प्राधिकरण मानकमा आधारित छ। यो मानक एकदम जटिल छ, तर यो पास-थ्रु प्रमाणीकरण सेवा विकास गर्न उपयोगी छ। लेखमा "प्राधिकरणको सूक्ष्मता: OAuth 2.0 प्रविधिको एक सिंहावलोकन» हामीले एलेक्सी चेरन्याएभले मानकको बारेमा सकेसम्म सरल र स्पष्ट रूपमा बताउन प्रयास गर्यौं ताकि तपाईंले यसलाई अध्ययन गर्न समय बचत गर्नुभयो।

ट्र्याकरले के गर्छ?

अब लोडेड सेवाहरूको दोस्रो बारे। ट्र्याकरले दोहोरो भूमिका प्रदर्शन गर्दछ:

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

जब नयाँ उत्पादन अर्डरमा देखा पर्दछ (उदाहरणका लागि, पिज्जा), यो रोलिङ आउट ट्र्याकर स्टेशनमा जान्छ। यस स्टेशनमा, त्यहाँ एक पिज्जा निर्माता छ जसले आवश्यक आकारको बन लिन्छ र यसलाई रोल आउट गर्दछ, त्यसपछि उसले ट्र्याकर ट्याब्लेटमा नोट गर्दछ कि उसले आफ्नो कार्य पूरा गरेको छ र रोल गरिएको आटाको आधार अर्को स्टेशनमा स्थानान्तरण गर्दछ - "प्रारम्भ"। ।

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

यो ट्याब्लेटको स्क्रिन ट्र्याकर "Raskatka" को स्टेशन मा जस्तो देखिन्छ

भारहरू कहाँबाट आउँछन्?

प्रत्येक पिज्जेरियामा ट्र्याकरसहित पाँचवटा ट्याब्लेटहरू छन्। 2016 मा, हामीसँग 100 भन्दा बढी पिज्जेरियाहरू थिए (र अहिले 600 भन्दा बढी)। प्रत्येक ट्याब्लेटले प्रत्येक 10 सेकेन्डमा एक पटक ब्याकइन्डमा अनुरोध गर्दछ र अर्डर तालिका (ग्राहक र ठेगानासँग जडान), अर्डर संरचना (उत्पादनसँग जडान र मात्राको सङ्केत), प्रेरणा लेखा तालिका (द) बाट डेटा स्क्र्याप गर्दछ। थिच्ने समय यसमा ट्र्याक गरिएको छ)। जब पिज्जा निर्माताले ट्र्याकरमा उत्पादनमा क्लिक गर्दछ, यी सबै तालिकाहरूमा प्रविष्टिहरू अद्यावधिक हुन्छन्। अर्डर तालिका सामान्य हो, यसले अर्डर स्वीकार गर्दा इन्सर्टहरू पनि समावेश गर्दछ, प्रणालीको अन्य भागहरूबाट अद्यावधिकहरू र असंख्य पढाइहरू, उदाहरणका लागि, टिभीमा जुन पिज्जेरियामा झुण्डिएको छ र ग्राहकहरूलाई समाप्त भएका अर्डरहरू देखाउँदछ।

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

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

WAS। मूल वास्तुकला थियो:

छुट्टाछुट्टै प्रक्रियामा छुट्याएपछि पनि धेरैजसो कोड आधार फरक-फरक सेवाहरूको लागि साझा रह्यो। नियन्त्रकहरू मुनि सबै एकल थियो र एउटै भण्डारमा बस्थ्यो। हामीले सेवाहरूको साझा विधिहरू, भण्डारहरू, साझा आधारहरू प्रयोग गर्यौं, जसमा साझा तालिकाहरू राखिएका छन्।

ट्र्याकर अनलोड गर्दै

ट्र्याकरको साथ मुख्य समस्या यो हो कि डाटा विभिन्न डाटाबेसहरू बीच सिङ्क्रोनाइज हुनुपर्छ। यो प्रमाणीकरण सेवाको पृथकीकरणबाट यसको मुख्य भिन्नता पनि हो, अर्डर र यसको स्थिति परिवर्तन हुन सक्छ र विभिन्न सेवाहरूमा देखाइनुपर्छ।

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

अर्डर स्थितिहरू परिवर्तन गर्ने योजना यस्तो देखिन्छ:

विभिन्न प्रणालीहरू बीच स्थितिहरू परिवर्तन हुन्छन्। र यहाँ ट्र्याकर अन्तिम प्रणाली होइन जसमा डाटा बन्द छ। हामीले यस्तो अवस्थामा विभाजनको लागि धेरै सम्भावित दृष्टिकोणहरू देखेका छौं:

1. हामी सबै अर्डर कार्यहरू एउटै सेवामा केन्द्रित गर्छौं। हाम्रो अवस्थामा, यो विकल्पलाई अर्डरसँग काम गर्न धेरै सेवा चाहिन्छ। यदि हामी यसलाई रोक्यौं भने, हामीले दोस्रो मोनोलिथ पाउनेछौं। हामीले समस्या समाधान गर्दैनौं ।
2. एउटा प्रणालीले अर्कोलाई कल गर्छ। दोस्रो विकल्प पहिले नै थप रोचक छ। तर यसको साथ, कलहरूको चेन सम्भव छ (क्यास्केडिङ विफलताहरू), कम्पोनेन्टहरूको जडान उच्च छ, यो व्यवस्थापन गर्न गाह्रो छ।
3. हामी घटनाहरू व्यवस्थित गर्छौं, र प्रत्येक सेवाले यी घटनाहरू मार्फत अर्कोसँग सञ्चार गर्छ। नतिजाको रूपमा, यो तेस्रो विकल्प थियो जुन छनौट गरिएको थियो, जसको अनुसार सबै सेवाहरू एकअर्कासँग घटनाहरू आदानप्रदान गर्न थाल्छन्।

हामीले तेस्रो विकल्प रोजेको तथ्यको अर्थ ट्र्याकरको आफ्नै डाटाबेस हुनेछ, र अर्डरमा प्रत्येक परिवर्तनको लागि, यसले यसको बारेमा घटना पठाउनेछ, जसमा अन्य सेवाहरू सदस्यता लिन्छ र जुन मास्टर डाटाबेसमा पनि पर्दछ। यो गर्नको लागि, हामीलाई सेवाहरू बीच सन्देशहरूको डेलिभरी सुनिश्चित गर्ने केही सेवा चाहिन्छ।

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

क्रमबद्ध मार्ग चरणबद्ध
अर्डर मार्ग अर्डर स्रोत सेवाहरू मध्ये एकबाट सुरु हुन्छ। यहाँ रेस्टुरेन्ट को क्यासियर छ:

1. चेकआउटमा, अर्डर पूर्ण रूपमा तयार छ, र यो ट्र्याकरमा पठाउने समय हो। घटना जसमा ट्र्याकर सदस्यता लिइएको छ फ्याँकिएको छ।
2. ट्र्याकरले आफैंको लागि अर्डर स्वीकार गर्दै, यसलाई आफ्नै डाटाबेसमा बचत गर्छ, घटनालाई "ट्र्याकरद्वारा स्वीकृत आदेश" बनाउँछ र RMQ मा पठाउँछ।
3. त्यहाँ धेरै ह्यान्डलरहरू पहिले नै प्रति अर्डर घटना बसमा सदस्यता लिएका छन्। हाम्रो लागि, एक मोनोलिथिक आधारसँग सिंक्रोनाइजेसन गर्ने महत्त्वपूर्ण छ।
4. ह्यान्डलरले घटना प्राप्त गर्दछ, त्यसबाट डेटा चयन गर्दछ जुन यसको लागि महत्त्वपूर्ण छ: हाम्रो अवस्थामा, यो "ट्र्याकर द्वारा स्वीकार्य" आदेशको स्थिति हो र मुख्य डाटाबेसमा यसको अर्डर इकाई अपडेट गर्दछ।

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

अन्य सबै सेवाहरूले पनि ट्र्याकरबाट घटनाहरू अर्डर गर्न सदस्यता लिन सक्छन् तिनीहरूलाई आफ्नै लागि प्रयोग गर्न।

यदि केहि समय पछि अर्डर काममा लिइन्छ, त्यसपछि यसको स्थिति पहिले यसको डाटाबेस (ट्र्याकर डाटाबेस) मा परिवर्तन हुन्छ, र त्यसपछि "OrderIn प्रगति" घटना तुरुन्तै उत्पन्न हुन्छ। यो RMQ मा पनि जान्छ, जहाँबाट यो एक मोनोलिथिक डाटाबेसमा सिंक्रोनाइज हुन्छ र अन्य सेवाहरूमा डेलिभर हुन्छ। बाटोमा विभिन्न समस्याहरू हुन सक्छन्, तिनीहरूको बारेमा थप विवरण Zhenya Peshkov को रिपोर्टमा पाउन सकिन्छ ट्र्याकरमा घटनात्मक स्थिरताको कार्यान्वयन विवरणहरूको बारेमा.

Auth र Tracker मा परिवर्तन पछि अन्तिम वास्तुकला

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

त्यस्ता सामग्रीका फाइदाहरू (वा यसको अभाव) लाई प्रतिबिम्बित गर्दै, म निष्कर्षमा पुगें कि घटनाहरूको पूर्ण विवरणहरू, विस्तृत पूर्वव्यापीहरू र मेरा विगतका निर्णयहरूको विश्लेषण बिना निरन्तर विकास असम्भव छ।

मलाई आशा छ कि यो हाम्रो मार्ग बारे जान्न को लागी उपयोगी र रोचक थियो। अब म अर्को लेखमा डोडो IS प्रणालीको कुन भाग वर्णन गर्ने छनौटको सामना गरिरहेको छु: टिप्पणीहरूमा लेख्नुहोस् वा भोट गर्नुहोस्।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

डोडो IS को कुन भागको बारेमा तपाईं अर्को लेखमा जान्न चाहनुहुन्छ?

• 24,1%डोडो IS (२०११-२०१५)१४ मा प्रारम्भिक मोनोलिथ

• 24,1%पहिलो समस्या र तिनको समाधान (2015-2016)14

• 20,7%क्लाइन्ट-साइड पथ: आधार माथि अनुहार (2016-2017)12

• 36,2%साँचो माइक्रोसेवाहरूको इतिहास (2018-2019)21

• 44,8%मोनोलिथको पूर्ण आरा र वास्तुकलाको स्थिरीकरण26

• 29,3%प्रणालीको विकासको लागि थप योजनाहरूको बारेमा 17

• 19,0%म Dodo IS11 को बारेमा केहि जान्न चाहन्न

58 प्रयोगकर्ताहरूले मतदान गरे। 6 प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com