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

Habr जग बदलत आहे. आम्ही एका वर्षाहून अधिक काळ ब्लॉगिंग करत आहोत. सुमारे सहा महिन्यांपूर्वी आम्हाला खाब्रोव्स्क रहिवाशांकडून जोरदार तार्किक अभिप्राय मिळाला: “डोडो, तुम्ही सर्वत्र म्हणता की तुमची स्वतःची प्रणाली आहे. ही कोणत्या प्रकारची यंत्रणा आहे? आणि पिझ्झेरिया चेनला याची गरज का आहे?"

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

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

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

1. डोडो IS (2011-2015) मधील प्रारंभिक मोनोलिथ. (सुरू आहे...)
2. बॅकऑफिस मार्ग: स्वतंत्र तळ आणि बस. (तुम्ही येथे आहात)
3. क्लायंट साइड पथ: बेस वर दर्शनी भाग (2016-2017). (सुरू आहे...)
4. वास्तविक मायक्रोसर्व्हिसेसचा इतिहास. (2018-2019). (सुरू आहे...)
5. मोनोलिथचे पूर्ण सॉइंग आणि आर्किटेक्चरचे स्थिरीकरण. (सुरू आहे...)

तुम्हाला आणखी काही शिकण्यात स्वारस्य असल्यास, टिप्पण्यांमध्ये लिहा.

लेखकाकडून कालक्रमानुसार वर्णनावर मत
मी "सिस्टम आर्किटेक्चर" या विषयावर नवीन कर्मचार्‍यांसाठी नियमितपणे बैठक घेतो. आम्ही त्याला "डोडो IS आर्किटेक्चरचा परिचय" म्हणतो आणि नवीन विकासकांसाठी ऑनबोर्डिंग प्रक्रियेचा भाग आहे. आमच्या आर्किटेक्चरबद्दल, त्याच्या वैशिष्ट्यांबद्दल एक किंवा दुसर्या स्वरूपात बोलणे, मी वर्णनासाठी एक विशिष्ट ऐतिहासिक दृष्टीकोन विकसित केला.

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

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

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

2020 पर्यंत, ते थोडे अधिक क्लिष्ट झाले आणि असे झाले:

ही उत्क्रांती कशी झाली? सिस्टमच्या वेगवेगळ्या भागांची आवश्यकता का आहे? कोणते वास्तुशास्त्रीय निर्णय घेतले आणि का? चला या लेखांच्या मालिकेत शोधूया.

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

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

एकल MySql डेटाबेस ज्यामध्ये त्या वेळी Dodo IS मध्ये अस्तित्वात असलेल्या सर्व अनुप्रयोगांनी त्यांचे रेकॉर्ड लिहिले. त्याचे परिणाम असे:

• जास्त भार (85% विनंत्या वाचल्या जात आहेत).
• पाया वाढत होता. त्यामुळे खर्च आणि आधार हा मुद्दा बनला.
• अपयशाचा एकच मुद्दा. डेटाबेसवर लिहिणारा एक अनुप्रयोग अचानक अधिक सक्रियपणे करू लागला, तर इतर अनुप्रयोगांना त्याचा परिणाम जाणवला.
• स्टोरेज आणि प्रश्नांमध्ये अकार्यक्षमता. बर्‍याचदा डेटा काही संरचनेत संग्रहित केला जातो जो काही परिस्थितींसाठी सोयीस्कर होता परंतु इतरांसाठी नाही. निर्देशांक काही ऑपरेशन्सची गती वाढवतात, परंतु इतरांची गती कमी करू शकतात.
• घाईघाईने बनवलेल्या कॅशे आणि डेटाबेसेसच्या वाचन-प्रतिकृतींद्वारे काही समस्यांचे निराकरण केले गेले (याबद्दल एका स्वतंत्र लेखात चर्चा केली जाईल), परंतु त्यांनी आम्हाला फक्त वेळ मिळू दिला आणि मूलभूतपणे समस्येचे निराकरण केले नाही.

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

• अद्वितीय आणि दुर्मिळ प्रकाशन.
• अडचण मोठ्या संख्येने लोकांच्या सहयोगी विकासात आहे.
• नवीन तंत्रज्ञान, नवीन फ्रेमवर्क आणि लायब्ररी सादर करण्यास असमर्थता.

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

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

धडा नेव्हिगेशन

1. मोनोलिथ 2016 ची योजना
2. आम्ही मोनोलिथ अनलोड करणे सुरू करतो: ऑथ आणि ट्रॅकर वेगळे करणे
   
3. Auth काय करते?
4. भार कुठून येतो?
5. प्रमाणीकरण अनलोड करत आहे
6. ट्रॅकर काय करतो?
7. भार कुठून येतो?
8. ट्रॅकर अनलोड करत आहे

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

येथे 2016 डोडो IS मोनोलिथचे मुख्य ब्लॉक्स आहेत आणि खाली त्यांच्या मुख्य कार्यांचे ब्रेकडाउन आहे.

डिलिव्हरी कॅश डेस्क. कुरिअरसाठी लेखांकन, कुरिअरला ऑर्डर जारी करणे.
संपर्क केंद्र. ऑपरेटरद्वारे ऑर्डर स्वीकारणे.
जागा. आमच्या वेबसाइट्स (dodopizza.ru, dodopizza.co.uk, dodopizza.by, इ.).
एथ. बॅकऑफिससाठी अधिकृतता आणि प्रमाणीकरण सेवा.
ट्रॅकर. किचन ऑर्डर ट्रॅकर. ऑर्डर तयार करताना तयारी स्थिती चिन्हांकित करण्यासाठी सेवा.
रेस्टॉरंट कॅश डेस्क. रेस्टॉरंटमध्ये ऑर्डर घेणे, कॅशियर इंटरफेस.
निर्यात. लेखांकनासाठी 1C मध्ये अहवाल अपलोड करणे.
सूचना आणि पावत्या. स्वयंपाकघरातील व्हॉइस कमांड (उदाहरणार्थ, “नवीन पिझ्झा आला आहे”) + कुरिअरसाठी पावत्या प्रिंट करणे.
शिफ्ट मॅनेजर. शिफ्ट मॅनेजरच्या कामासाठी इंटरफेस: ऑर्डरची यादी, उत्पादकता चार्ट, कर्मचाऱ्यांना शिफ्टमध्ये आणणे.
कार्यालय व्यवस्थापक. फ्रँचायझी आणि व्यवस्थापकांच्या कामासाठी इंटरफेस: कर्मचार्‍यांचे स्वागत, पिझ्झरियाच्या कामाचा अहवाल.
रेस्टॉरंट बोर्ड. पिझ्झरियामध्ये टीव्हीवर मेनू प्रदर्शित करणे.
अॅडमिन. विशिष्ट पिझ्झरियासाठी सेटिंग्ज: मेनू, किंमती, लेखा, प्रचारात्मक कोड, जाहिराती, साइटसाठी बॅनर इ.
कर्मचारी वैयक्तिक खाते. कर्मचाऱ्यांच्या कामाचे वेळापत्रक, कर्मचाऱ्यांची माहिती.
किचन मोटिव्हेशन बोर्ड. एक वेगळी स्क्रीन जी किचनमध्ये लटकते आणि पिझ्झा बनवणाऱ्यांची गती दाखवते.
संवाद. एसएमएस आणि ईमेल पाठवत आहे.
फाइल स्टोरेज. स्थिर फाइल्स प्राप्त करण्यासाठी आणि जारी करण्यासाठी स्वतःची सेवा.

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

आम्ही मोनोलिथ अनलोड करणे सुरू करतो: ऑथ आणि ट्रॅकर वेगळे करणे

मुख्य सेवा ज्या नंतर डेटाबेसमधून इतरांपेक्षा जास्त लिहित आणि वाचतात:

1. प्रमाण. बॅकऑफिससाठी अधिकृतता आणि प्रमाणीकरण सेवा.
2. ट्रॅकर. किचन ऑर्डर ट्रॅकर. ऑर्डर तयार करताना तयारी स्थिती चिन्हांकित करण्यासाठी सेवा.

Auth काय करते?

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

उदाहरणार्थ, आम्ही हॉलमध्ये टांगलेल्या टीव्हीवर पूर्ण केलेल्या ऑर्डरच्या स्थितीसह एक डिस्प्ले उघडू इच्छितो. मग आम्ही auth.dodopizza.ru उघडतो, "डिव्हाइस म्हणून लॉगिन करा" निवडा, एक कोड दिसेल जो शिफ्ट व्यवस्थापकाच्या संगणकावरील एका विशेष पृष्ठावर प्रविष्ट केला जाऊ शकतो, डिव्हाइसचा प्रकार (डिव्हाइस) दर्शवितो. टीव्ही स्वतः त्याच्या पिझ्झेरियाच्या इच्छित इंटरफेसवर जाईल आणि तेथे ज्या ग्राहकांच्या ऑर्डर तयार आहेत त्यांची नावे प्रदर्शित करण्यास सुरवात करेल.

भार कुठून येतो?

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

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

प्रमाणीकरण अनलोड करत आहे

Auth चे एक वेगळे डोमेन आहे, म्हणजे, वापरकर्ते, लॉगिन किंवा डिव्हाइसेसचा डेटा सेवेमध्ये प्रवेश करतो (सध्या भविष्यात) आणि तिथेच राहतो. जर एखाद्याला त्यांची गरज असेल तर तो डेटासाठी या सेवेकडे जाईल.

होते. कामाचा प्रवाह सुरुवातीला असा होता:

ते कसे कार्य करते ते मी थोडेसे स्पष्ट करू इच्छितो:

1. एक बाह्य विनंती बॅकएंडवर येते (तेथे Asp.Net MVC), सोबत सत्र कुकी आणते, जी Redis(1) कडून सत्र डेटा मिळविण्यासाठी वापरली जाते. त्यात एकतर ऍक्सेसबद्दल माहिती असते आणि नंतर कंट्रोलरचा ऍक्सेस खुला असतो (3,4), किंवा नाही.
2. प्रवेश नसल्यास, तुम्हाला अधिकृतता प्रक्रियेतून जाण्याची आवश्यकता आहे. येथे, साधेपणासाठी, हे समान गुणधर्मातील मार्गाचा भाग म्हणून दर्शविले आहे, जरी हे लॉगिन पृष्ठावरील संक्रमण आहे. सकारात्मक परिस्थितीच्या बाबतीत, आम्ही योग्यरित्या भरलेले सत्र प्राप्त करू आणि बॅकऑफिस कंट्रोलरकडे जाऊ.
3. डेटा असल्यास, वापरकर्ता डेटाबेसमधील प्रासंगिकतेसाठी आपल्याला ते तपासण्याची आवश्यकता आहे. त्यांची भूमिका बदलली आहे, आता त्यांना पानावर परवानगी द्यायची नाही का? या प्रकरणात, सत्र (1) प्राप्त केल्यानंतर, तुम्हाला थेट डेटाबेसवर जाण्याची आणि प्रमाणीकरण लॉजिक स्तर (2) वापरून वापरकर्त्याचा प्रवेश तपासण्याची आवश्यकता आहे. पुढे, एकतर लॉगिन पृष्ठावर जा किंवा कंट्रोलरवर जा. ही एक साधी प्रणाली आहे, परंतु पूर्णपणे मानक नाही.
4. जर सर्व प्रक्रिया पूर्ण झाल्या असतील, तर आम्ही नियंत्रक आणि पद्धतींमधील तर्कशास्त्रात पुढे जाऊ.

वापरकर्ता डेटा इतर सर्व डेटापासून विभक्त केला जातो, तो एका वेगळ्या सदस्यत्व सारणीमध्ये संग्रहित केला जातो, AuthService लॉजिक स्तरावरील कार्ये कदाचित API पद्धती बनू शकतात. डोमेनच्या सीमा अगदी स्पष्टपणे परिभाषित केल्या आहेत: वापरकर्ते, त्यांची भूमिका, प्रवेश डेटा, जारी करणे आणि प्रवेश रद्द करणे. प्रत्येक गोष्ट वेगळ्या सेवेत हलवली जाऊ शकते असे दिसते.

झाले. त्यांनी तेच केले:

या दृष्टिकोनात अनेक समस्या आहेत. उदाहरणार्थ, एखाद्या प्रक्रियेमध्ये पद्धत कॉल करणे हे http द्वारे बाह्य सेवेला कॉल करण्यासारखे नाही. ऑपरेशनची विलंबता, विश्वासार्हता, समर्थनक्षमता आणि पारदर्शकता पूर्णपणे भिन्न आहेत. आंद्रे मोरेव्स्कीने आपल्या अहवालात नेमक्या या समस्यांबद्दल अधिक तपशीलवार सांगितले "मायक्रोसर्व्हिसेसच्या ५० शेड्स".

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

विभक्त होण्यास इतका वेळ का लागला?
वाटेत अनेक समस्या आल्या ज्याने आमची गती कमी केली:

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

पिझ्झेरियामध्ये डिव्हाइसची नोंदणी करण्याची योजना:

प्रमाणीकरण आणि डिव्हाइस सेवा विभक्त केल्यानंतर सामान्य आर्किटेक्चर:

शेरा. 2020 साठी, आम्ही Auth च्या नवीन आवृत्तीवर काम करत आहोत, जी OAuth 2.0 अधिकृतता मानकावर आधारित आहे. हे मानक खूपच जटिल आहे, परंतु एंड-टू-एंड ऑथेंटिकेशन सेवा विकसित करण्यासाठी उपयुक्त आहे. लेखात "अधिकृततेची सूक्ष्मता: OAuth 2.0 तंत्रज्ञानाचे विहंगावलोकन» आम्ही अॅलेक्सी चेरन्याएव्हने मानकांबद्दल शक्य तितक्या सोप्या आणि स्पष्टपणे बोलण्याचा प्रयत्न केला जेणेकरून तुमचा त्याचा अभ्यास करण्यात वेळ वाचेल.

ट्रॅकर काय करतो?

आता लोड केलेल्या सेवांच्या दुसऱ्या बद्दल. ट्रॅकर दुहेरी भूमिका पार पाडतो:

• एकीकडे, त्याचे कार्य स्वयंपाकघरातील कर्मचार्‍यांना दर्शविणे आहे की सध्या कोणत्या ऑर्डर चालू आहेत, कोणती उत्पादने आता तयार करणे आवश्यक आहे.
• दुसरीकडे, स्वयंपाकघरातील सर्व प्रक्रिया डिजिटल करा.

जेव्हा नवीन उत्पादन (उदाहरणार्थ, पिझ्झा) ऑर्डरमध्ये दिसते, तेव्हा ते “रोलिंग” ट्रॅकर स्टेशनवर जाते. या स्टेशनवर एक पिझ्झा मेकर आहे जो आवश्यक आकाराचा बन घेतो आणि तो रोल आउट करतो, त्यानंतर तो ट्रॅकर टॅबलेटवर चिन्हांकित करतो की त्याने त्याचे कार्य पूर्ण केले आहे आणि रोल आऊट केलेला पीठ पुढील स्टेशनवर पाठवतो - "फिलिंग" .

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

रास्कटका ट्रॅकर स्टेशनवर टॅब्लेट स्क्रीन असे दिसते.

भार कुठून येतो?

प्रत्येक पिझेरियामध्ये ट्रॅकरसह सुमारे पाच गोळ्या असतात. 2016 मध्ये आमच्याकडे 100 पेक्षा जास्त पिझेरिया होते (आणि आता 600 पेक्षा जास्त आहेत). प्रत्येक टॅब्लेट दर 10 सेकंदांनी बॅकएंडला विनंती करते आणि ऑर्डर टेबलमधून डेटा गोळा करते (क्लायंट आणि पत्त्यासह लिंक), ऑर्डर रचना (उत्पादनासह लिंक आणि प्रमाणाचे संकेत), आणि प्रेरणा सारणी (ते ट्रॅक करते. दाबण्याची वेळ). जेव्हा पिझ्झा मेकर ट्रॅकरवरील उत्पादनावर क्लिक करतो तेव्हा या सर्व टेबलमधील रेकॉर्ड अपडेट केले जातात. ऑर्डर टेबल सामान्य आहे; ऑर्डर स्वीकारताना त्यात एकाच वेळी इन्सर्टेशन, सिस्टमच्या इतर भागांवरील अपडेट्स आणि असंख्य रीडिंग्स असतात, उदाहरणार्थ, पिझ्झेरियामध्ये टांगलेल्या टीव्हीवर आणि ग्राहकांना रेडीमेड ऑर्डर दाखवते.

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

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

होते. सुरुवातीला वास्तुकला अशी होती:

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

ट्रॅकर अनलोड करत आहे

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

आम्ही रेस्टॉरंट चेकआउटवर ऑर्डर स्वीकारतो (ही एक सेवा आहे), ती डेटाबेसमध्ये “स्वीकारलेल्या” स्थितीमध्ये संग्रहित केली जाते. त्यानंतर, ते ट्रॅकरकडे जावे, जिथे ते त्याची स्थिती आणखी अनेक वेळा बदलेल: “किचन” वरून “पॅक केलेले”. या प्रकरणात, कॅशियर किंवा शिफ्ट मॅनेजर इंटरफेसचे काही बाह्य प्रभाव ऑर्डरसह येऊ शकतात. मी टेबलमध्ये त्यांच्या वर्णनासह ऑर्डरची स्थिती देईन:

ऑर्डर स्थिती बदलण्याची योजना यासारखी दिसते:

वेगवेगळ्या प्रणालींमध्ये स्थिती बदलतात. आणि येथे ट्रॅकर ही अंतिम प्रणाली नाही ज्यामध्ये डेटा लॉक केलेला आहे. अशा परिस्थितीत विभक्त होण्यासाठी आम्ही अनेक संभाव्य दृष्टिकोन पाहिले आहेत:

1. आम्ही सर्व ऑर्डर क्रिया एकाच सेवेमध्ये केंद्रित करतो. आमच्या बाबतीत, ऑर्डरवर प्रक्रिया करण्यासाठी या पर्यायासाठी खूप जास्त सेवा आवश्यक आहे. जर आम्ही तिथे थांबलो असतो, तर आम्ही दुसऱ्या मोनोलिथसह संपलो असतो. आम्ही प्रश्न सोडवले नसते.
2. एक यंत्रणा दुसऱ्याला कॉल करते. दुसरा पर्याय अधिक मनोरंजक आहे. परंतु त्यासह, कॉलची साखळी शक्य आहे (कॅस्केडिंग अपयश), घटकांची कनेक्टिव्हिटी जास्त आहे आणि ते व्यवस्थापित करणे अधिक कठीण आहे.
3. आम्ही कार्यक्रम आयोजित करतो आणि या कार्यक्रमांद्वारे प्रत्येक सेवा एकमेकांशी देवाणघेवाण करतो. परिणामी, तिसरा पर्याय निवडला गेला, त्यानुसार सर्व सेवा एकमेकांशी इव्हेंट्सची देवाणघेवाण करण्यास सुरवात करतात.

आम्ही तिसरा पर्याय निवडला याचा अर्थ असा आहे की ट्रॅकरचा स्वतःचा डेटाबेस असेल आणि क्रमातील प्रत्येक बदलासाठी तो याबद्दल एक इव्हेंट पाठवेल, ज्यासाठी इतर सेवा सदस्यता घेतील आणि ज्याचा मास्टर डेटाबेसमध्ये समावेश केला जाईल. हे करण्यासाठी, आम्हाला काही सेवेची आवश्यकता आहे जी सेवांमधील संदेशांचे वितरण सुनिश्चित करेल.

तोपर्यंत, आमच्याकडे स्टॅकमध्ये आधीच RabbitMQ होते, म्हणून संदेश ब्रोकर म्हणून वापरण्याचा अंतिम निर्णय. आकृती रेस्टॉरंट कॅशियरकडून ट्रॅकरद्वारे ऑर्डरचे संक्रमण दर्शवते, जिथे ते त्याची स्थिती आणि व्यवस्थापकाच्या ऑर्डर इंटरफेसवर त्याचे प्रदर्शन बदलते. झाले:

क्रमाने मार्ग चरणबद्ध
ऑर्डरचा मार्ग ऑर्डर स्त्रोत सेवांपैकी एकापासून सुरू होतो. येथे रेस्टॉरंट कॅशियर आहे:

1. चेकआउटवर ऑर्डर पूर्णपणे तयार आहे आणि ती ट्रॅकरला पाठवण्याची वेळ आली आहे. ज्या इव्हेंटमध्ये ट्रॅकरने सदस्यता घेतली आहे तो फेकला जातो.
2. ट्रॅकर, ऑर्डर स्वीकारून, तो त्याच्या स्वतःच्या डेटाबेसमध्ये सेव्ह करतो, "ऑर्डर अ‍ॅक्सेप्टेड बाय ट्रॅकर" इव्हेंट बनवतो आणि तो RMQ ला पाठवतो.
3. अनेक हँडलर आधीच सानुकूल इव्हेंट बसचे सदस्य आहेत. आमच्यासाठी, मोनोलिथिक डेटाबेससह सिंक्रोनाइझ केलेले एक महत्त्वाचे आहे.
4. हँडलरला इव्हेंट प्राप्त होतो, त्यातून तो डेटा निवडतो जो त्याच्यासाठी महत्त्वाचा आहे: आमच्या बाबतीत, ही ऑर्डर स्थिती "ट्रॅकरद्वारे स्वीकारलेली" आहे आणि मुख्य डेटाबेसमध्ये त्याची ऑर्डर संस्था अद्यतनित करते.

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

इतर सर्व सेवा देखील ट्रॅकर वरून इव्हेंट ऑर्डर करण्यासाठी सदस्यत्व घेऊ शकतात जेणेकरुन त्यांचा स्वतःसाठी वापर करा.

काही काळानंतर ऑर्डर उत्पादनात घेतल्यास, त्याची स्थिती प्रथम त्याच्या डेटाबेसमध्ये (ट्रॅकर डेटाबेस) बदलते आणि नंतर "OrderInWork" इव्हेंट त्वरित तयार केला जातो. हे RMQ मध्ये देखील मिळते, तेथून ते एका मोनोलिथिक डेटाबेसमध्ये सिंक्रोनाइझ केले जाते आणि इतर सेवांना वितरित केले जाते. या मार्गावर विविध समस्या असू शकतात; त्यांच्याबद्दल अधिक तपशील झेन्या पेशकोव्हच्या अहवालात आढळू शकतात ट्रॅकरमधील घटनात्मक सुसंगततेच्या अंमलबजावणीच्या तपशीलांबद्दल.

ऑथ आणि ट्रॅकरमधील बदलांनंतर अंतिम आर्किटेक्चर

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

अशा सामग्रीच्या फायद्यांवर (किंवा त्याची कमतरता) प्रतिबिंबित करून, मी या निष्कर्षापर्यंत पोहोचलो की घटनांच्या पूर्ण इतिहास, तपशीलवार पूर्वलक्ष्य आणि एखाद्याच्या भूतकाळातील निर्णयांचे विश्लेषण केल्याशिवाय निरंतर विकास अशक्य आहे.

मला आशा आहे की तुम्हाला आमच्या प्रवासाबद्दल जाणून घेणे उपयुक्त आणि मनोरंजक वाटले. आता मला पुढील लेखात डोडो आयएस प्रणालीच्या कोणत्या भागाचे वर्णन करायचे या निवडीचा सामना करावा लागला आहे: टिप्पण्यांमध्ये लिहा किंवा मत द्या.

केवळ नोंदणीकृत वापरकर्तेच सर्वेक्षणात भाग घेऊ शकतात. साइन इन करा, आपले स्वागत आहे.

डोडो IS च्या कोणत्या भागाबद्दल तुम्हाला पुढील लेखात जाणून घ्यायचे आहे?

• 24,1%डोडो IS (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%मला Dodo IS11 बद्दल काहीही जाणून घ्यायचे नाही

58 वापरकर्त्यांनी मतदान केले. 6 वापरकर्ते दूर राहिले.

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