डोडो आईएस आर्किटेक्चर का इतिहास: बैक ऑफिस पथ

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

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

आभार: हमारे साथ अपनी प्रतिक्रिया साझा करने के लिए धन्यवाद। उनके लिए धन्यवाद, हमने अंततः सिस्टम का वर्णन किया, एक तकनीकी रडार संकलित किया और जल्द ही हमारी प्रक्रियाओं का एक बड़ा विवरण पेश करेंगे। आपके बिना, हम अगले 5 वर्षों तक वहीं बैठे रहते।

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

1. डोडो आईएस में प्रारंभिक मोनोलिथ (2011-2015)। (प्रगति पर है...)
2. पिछला कार्यालय पथ: अलग अड्डे और बस। (आप यहां हैं)
3. क्लाइंट साइड पाथ: बेस के ऊपर का मुखौटा (2016-2017)। (चालू...)
4. सच्चे माइक्रोसर्विसेज का इतिहास। (2018-2019)। (चालू...)
5. मोनोलिथ को काटने का काम पूरा हो गया है और वास्तुकला का स्थिरीकरण हो गया है। (चालू...)

यदि आप कुछ और जानने में रुचि रखते हैं - टिप्पणियों में लिखें।

कालानुक्रमिक विवरण पर लेखक की राय
मैं नियमित रूप से "सिस्टम आर्किटेक्चर" विषय पर नए कर्मचारियों के लिए एक बैठक आयोजित करता हूं। हम इसे "डोडो आईएस आर्किटेक्चर का परिचय" कहते हैं और यह नए डेवलपर्स के लिए ऑनबोर्डिंग प्रक्रिया का हिस्सा है। हमारी वास्तुकला के बारे में, इसकी विशेषताओं के बारे में किसी न किसी रूप में बताते हुए, मैंने वर्णन के लिए एक निश्चित ऐतिहासिक दृष्टिकोण को जन्म दिया है।

परंपरागत रूप से, हम सिस्टम को घटकों (तकनीकी या उच्च-स्तरीय), व्यावसायिक मॉड्यूल के एक सेट के रूप में देखते हैं जो किसी लक्ष्य को प्राप्त करने के लिए एक-दूसरे के साथ बातचीत करते हैं। और यदि ऐसा दृष्टिकोण डिज़ाइन के लिए उचित है, तो यह विवरण और समझ के लिए बिल्कुल उपयुक्त नहीं है। यहाँ कई कारण हैं:

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

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

2020 तक यह थोड़ा और जटिल हो गया है और इस प्रकार हो गया है:

यह विकास कैसे हुआ? सिस्टम के विभिन्न भागों की आवश्यकता क्यों है? क्या वास्तु संबंधी निर्णय लिए गए और क्यों? आइए लेखों की इस श्रृंखला में जानें।

2016 की पहली समस्याएं: सेवाओं को मोनोलिथ क्यों छोड़ना चाहिए?

चक्र के पहले लेख उन सेवाओं के बारे में होंगे जो सबसे पहले मोनोलिथ से अलग हुईं। आपको संदर्भ में रखने के लिए, मैं आपको बताऊंगा कि 2016 की शुरुआत तक सिस्टम में हमारी क्या समस्याएं थीं, कि हमें सेवाओं के पृथक्करण से निपटना पड़ा।

एक एकल MySql डेटाबेस, जिसमें डोडो आईएस में उस समय मौजूद सभी एप्लिकेशन ने अपने रिकॉर्ड लिखे। परिणाम ये थे:

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

समस्या मोनोलिथ की उपस्थिति ही थी. परिणाम ये थे:

• एकल और दुर्लभ रिलीज़।
• बड़ी संख्या में लोगों के संयुक्त विकास में कठिनाई।
• नई प्रौद्योगिकियों, नई रूपरेखाओं और पुस्तकालयों को लाने में असमर्थता।

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

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

अध्याय नेविगेशन

1. मोनोलिथ योजना 2016
2. मोनोलिथ को उतारना शुरू करना: प्रामाणिक और ट्रैकर पृथक्करण
   
3. ऑथ क्या करता है?
4. भार कहाँ से हैं?
5. प्रामाणिक उतारना
6. ट्रैकर क्या करता है?
7. भार कहाँ से हैं?
8. अनलोडिंग ट्रैकर

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

यहां डोडो आईएस 2016 मोनोलिथ के मुख्य ब्लॉक हैं, और ठीक नीचे उनके मुख्य कार्यों की एक प्रतिलेख है।

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

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

मोनोलिथ को उतारना शुरू करना: प्रामाणिक और ट्रैकर पृथक्करण

मुख्य सेवाएँ जो तब डेटाबेस से दूसरों की तुलना में अधिक रिकॉर्ड और पढ़ी जाती थीं:

1. प्रामाणिक. बैक ऑफिस के लिए प्राधिकरण और प्रमाणीकरण सेवा।
2. ट्रैकर. रसोई में ऑर्डर ट्रैकर। ऑर्डर तैयार करते समय तत्परता की स्थिति को चिह्नित करने की सेवा।

ऑथ क्या करता है?

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

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

भार कहाँ से हैं?

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

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

प्रामाणिक उतारना

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

ये था। कार्य की मूल योजना इस प्रकार थी:

मैं थोड़ा समझाना चाहूंगा कि यह कैसे काम करता है:

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

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

बनना। तो उन्होंने किया:

इस दृष्टिकोण में कई समस्याएँ हैं। उदाहरण के लिए, किसी प्रक्रिया के अंदर किसी विधि को कॉल करना http के माध्यम से किसी बाहरी सेवा को कॉल करने के समान नहीं है। ऑपरेशन की विलंबता, विश्वसनीयता, रखरखाव, पारदर्शिता पूरी तरह से अलग हैं। एंड्री मोरेव्स्की ने अपनी रिपोर्ट में ऐसी समस्याओं के बारे में अधिक विस्तार से बात की। "माइक्रोसर्विसेज के 50 शेड्स".

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

अलगाव में इतना समय क्यों लगा?
रास्ते में कई समस्याएँ थीं जिन्होंने हमें धीमा कर दिया:

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

पिज़्ज़ेरिया में डिवाइस पंजीकरण योजना:

प्रामाणिक और उपकरण सेवा के निष्कर्षण के बाद सामान्य वास्तुकला:

नोट. 2020 के लिए, हम ऑथ के एक नए संस्करण पर काम कर रहे हैं, जो OAuth 2.0 प्राधिकरण मानक पर आधारित है। यह मानक काफी जटिल है, लेकिन यह पास-थ्रू प्रमाणीकरण सेवा विकसित करने के लिए उपयोगी है। लेख में "प्राधिकरण की सूक्ष्मताएँ: OAuth 2.0 प्रौद्योगिकी का अवलोकन» हम एलेक्सी चेर्न्याव ने मानक के बारे में यथासंभव सरल और स्पष्ट रूप से बताने की कोशिश की ताकि आप इसका अध्ययन करने में समय बचा सकें।

ट्रैकर क्या करता है?

अब लोड की गई सेवाओं में से दूसरी के बारे में। ट्रैकर दोहरी भूमिका निभाता है:

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

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

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

ट्रैकर "रस्कटका" के स्टेशन पर टैबलेट की स्क्रीन इस तरह दिखती है

भार कहाँ से हैं?

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

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

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

ये था। मूल वास्तुकला थी:

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

अनलोडिंग ट्रैकर

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

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

ऑर्डर की स्थिति बदलने की योजना इस प्रकार है:

विभिन्न प्रणालियों के बीच स्थितियाँ बदलती रहती हैं। और यहां ट्रैकर कोई अंतिम सिस्टम नहीं है जिसमें डेटा बंद हो जाता है. हमने ऐसे मामले में विभाजन के लिए कई संभावित दृष्टिकोण देखे हैं:

1. हम ऑर्डर की सभी कार्रवाइयों को एक सेवा में केंद्रित करते हैं। हमारे मामले में, इस विकल्प को ऑर्डर के साथ काम करने के लिए बहुत अधिक सेवा की आवश्यकता होती है। अगर हम यहीं रुक गए तो हमें दूसरा मोनोलिथ मिल जाएगा। हम समस्या का समाधान नहीं करेंगे.
2. एक सिस्टम दूसरे को कॉल करता है. दूसरा विकल्प पहले से ही अधिक दिलचस्प है. लेकिन इसके साथ, कॉल की श्रृंखला संभव है (व्यापक विफलताएँ), घटकों की कनेक्टिविटी अधिक है, इसे प्रबंधित करना अधिक कठिन है।
3. हम कार्यक्रम आयोजित करते हैं, और प्रत्येक सेवा इन आयोजनों के माध्यम से दूसरे के साथ संचार करती है। परिणामस्वरूप, यह तीसरा विकल्प चुना गया, जिसके अनुसार सभी सेवाएँ एक-दूसरे के साथ घटनाओं का आदान-प्रदान करना शुरू करती हैं।

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

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

चरण दर चरण ऑर्डर पथ
ऑर्डर पथ ऑर्डर स्रोत सेवाओं में से एक पर शुरू होता है। यहाँ रेस्तरां का कैशियर है:

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

अगर किसी को मोनोलिथिक टेबल ऑर्डर से ऑर्डर चाहिए तो आप वहां से भी पढ़ सकते हैं. उदाहरण के लिए, शिफ्ट मैनेजर में ऑर्डर इंटरफ़ेस को इसकी आवश्यकता है:

अन्य सभी सेवाएँ भी अपने लिए उपयोग करने के लिए ट्रैकर से ईवेंट ऑर्डर करने के लिए सदस्यता ले सकती हैं।

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

ऑथ और ट्रैकर में बदलाव के बाद अंतिम आर्किटेक्चर

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

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

मुझे आशा है कि हमारे पथ के बारे में सीखना आपके लिए उपयोगी और दिलचस्प रहा होगा। अब मेरे सामने एक विकल्प है कि अगले लेख में डोडो आईएस प्रणाली के किस भाग का वर्णन किया जाए: टिप्पणियों में लिखें या वोट करें।

केवल पंजीकृत उपयोगकर्ता ही सर्वेक्षण में भाग ले सकते हैं। साइन इन करेंकृपया।

आप अगले लेख में डोडो आईएस के किस भाग के बारे में जानना चाहेंगे?

• 24,1% तक डोडो आईएस में प्रारंभिक मोनोलिथ (2011-2015)14

• 24,1% तक प्रथम समस्याएँ एवं उनके समाधान (2015-2016)14

• 20,7% तक क्लाइंट-साइड पथ: आधार पर अग्रभाग (2016-2017)12

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

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

• 29,3% तक सिस्टम के विकास के लिए आगे की योजनाओं के बारे में17

• 19,0% तक मैं डोडो IS11 के बारे में कुछ भी जानना नहीं चाहता

58 उपयोगकर्ताओं ने मतदान किया। 6 उपयोगकर्ता अनुपस्थित रहे।

स्रोत: www.habr.com