Yandex.Market शोध कसे कार्य करते आणि सर्व्हरपैकी एक अयशस्वी झाल्यास काय होते

हॅलो, माझे नाव इव्हगेनी आहे. मी Yandex.Market शोध इन्फ्रास्ट्रक्चरमध्ये काम करतो. मला हबर समुदायाला मार्केटच्या आतल्या स्वयंपाकघराबद्दल सांगायचे आहे - आणि मला सांगायचे आहे. सर्व प्रथम, मार्केट शोध कसे कार्य करते, प्रक्रिया आणि आर्किटेक्चर. आम्ही आपत्कालीन परिस्थितींना कसे सामोरे जाऊ: एक सर्व्हर डाउन झाल्यास काय होईल? असे 100 सर्व्हर असतील तर?

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

आमच्याबद्दल थोडेसे: आम्ही कोणती समस्या सोडवतो

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

आम्ही सर्व शोध विनंत्यांवर प्रक्रिया करतो: market.yandex.ru, beru.ru, सुपरचेक सेवा, Yandex.Advisor, मोबाइल अनुप्रयोग या साइटवरून. आम्ही yandex.ru वरील शोध परिणामांमध्ये उत्पादन ऑफर देखील समाविष्ट करतो.

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

काय आहे: मार्केट आर्किटेक्चर

मी मार्केटच्या सध्याच्या आर्किटेक्चरचे थोडक्यात वर्णन करेन. खाली दिलेल्या आकृतीद्वारे त्याचे अंदाजे वर्णन केले जाऊ शकते:

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

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

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

आम्ही शोध आर्किटेक्चरच्या भागामध्ये मांजर कसा शोधतो ते मी तुम्हाला सांगेन.

बाजार शोध आर्किटेक्चर

आम्ही मायक्रो सर्व्हिसेसच्या जगात राहतो: प्रत्येक येणारी विनंती market.yandex.ru अनेक सबक्वेरी कारणीभूत आहेत आणि डझनभर सेवा त्यांच्या प्रक्रियेत गुंतलेल्या आहेत. आकृती फक्त काही दर्शवते:

सरलीकृत विनंती प्रक्रिया योजना

प्रत्येक सेवेमध्ये एक अद्भुत गोष्ट असते - त्याचे स्वतःचे बॅलन्सर अनन्य नावासह:

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

बॅलन्सरचे अद्वितीय नाव डेटा सेंटरवर अवलंबून नाही. जेव्हा सेवा A B ला विनंती करते, तेव्हा डीफॉल्ट बॅलन्सर B वर्तमान डेटा सेंटरकडे विनंती पुनर्निर्देशित करते. सेवा अनुपलब्ध असल्यास किंवा सध्याच्या डेटा सेंटरमध्ये अस्तित्वात नसल्यास, विनंती इतर डेटा केंद्रांकडे पुनर्निर्देशित केली जाते.

सर्व डेटा केंद्रांसाठी एकच FQDN सेवा A ला स्थानांपासून पूर्णपणे अमूर्त होण्यास अनुमती देते. B सेवा करण्यासाठी त्याच्या विनंतीवर नेहमीच प्रक्रिया केली जाईल. अपवाद असा आहे की जेव्हा सेवा सर्व डेटा सेंटरमध्ये असते.

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

अनपेक्षितांशी व्यवहार करणे: शोध सेवा संतुलन आणि लवचिकता

अशी कल्पना करा की एक संकुचित झाला आहे: आपल्याला स्क्विकर असलेली मांजर शोधण्याची आवश्यकता आहे, परंतु सर्व्हर क्रॅश होतो. किंवा 100 सर्व्हर. कसे बाहेर पडायचे? आम्ही खरोखर वापरकर्त्याला मांजरीशिवाय सोडणार आहोत का?

परिस्थिती भयावह आहे, पण आम्ही त्यासाठी तयार आहोत. मी तुम्हाला क्रमाने सांगेन.

शोध पायाभूत सुविधा अनेक डेटा केंद्रांमध्ये स्थित आहे:

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

चला एका डेटा सेंटरचा विचार करूया. प्रत्येक डेटा सेंटरमध्ये समान बॅलन्सर ऑपरेशन योजना असते:

एक बॅलन्सर म्हणजे किमान तीन फिजिकल सर्व्हर. ही रिडंडंसी विश्वासार्हतेसाठी केली आहे. बॅलन्सर्स HAProx वर चालतात.

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

एक सर्व्हर अयशस्वी होण्याची शक्यता कमी आहे. परंतु आपल्याकडे अनेक सर्व्हर असल्यास, किमान एक खाली जाण्याची शक्यता वाढते.

प्रत्यक्षात असेच घडते: सर्व्हर क्रॅश. म्हणून, सर्व सर्व्हरच्या स्थितीचे सतत निरीक्षण करणे आवश्यक आहे. सर्व्हरने प्रतिसाद देणे थांबवल्यास, ते स्वयंचलितपणे रहदारीपासून डिस्कनेक्ट होते. या उद्देशासाठी, HAProxy मध्ये अंगभूत आरोग्य तपासणी आहे. हे HTTP विनंती “/ping” सह सेकंदातून एकदा सर्व सर्व्हरवर जाते.

HAProxy चे आणखी एक वैशिष्ट्य: agent-check तुम्हाला सर्व सर्व्हर समान रीतीने लोड करण्यास अनुमती देते. हे करण्यासाठी, HAProxy सर्व सर्व्हरशी कनेक्ट होते, आणि ते 1 ते 100 पर्यंतच्या वर्तमान लोडवर अवलंबून त्यांचे वजन परत करतात. प्रक्रियेसाठी रांगेतील विनंत्या आणि प्रोसेसरवरील लोडच्या आधारावर वजन मोजले जाते.

आता मांजर शोधण्याबद्दल. यासारख्या विनंत्यांमध्ये शोध परिणाम: /search?text=angry+cat. शोध जलद होण्यासाठी, संपूर्ण कॅट इंडेक्स RAM मध्ये बसणे आवश्यक आहे. SSD वरून वाचणे देखील पुरेसे जलद नाही.

एकेकाळी, ऑफर डेटाबेस लहान होता आणि त्यासाठी एका सर्व्हरची रॅम पुरेशी होती. जसजसा ऑफर बेस वाढला, तसतसे सर्व काही या रॅममध्ये बसत नाही आणि डेटा दोन भागांमध्ये विभागला गेला: शार्ड 1 आणि शार्ड 2.

परंतु हे नेहमीच घडते: कोणताही उपाय, अगदी चांगला, इतर समस्यांना जन्म देतो.

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

बॅलन्सर विनंत्या समान रीतीने वितरीत करत असल्याने, सर्व सर्व्हर री-रँकिंगमध्ये गुंतले होते, आणि फक्त डेटा पाठवत नव्हते.

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

सध्या, आठ शार्ड्सचे कॉन्फिगरेशन वापरले जाते. याव्यतिरिक्त, आणखी मेमरी जतन करण्यासाठी, अनुक्रमणिका शोध भाग (जो शोधण्यासाठी वापरला जातो) आणि स्निपेट भाग (जो शोधात गुंतलेला नाही) मध्ये विभागला गेला.

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

सर्व्हर क्लस्टरमध्ये गटबद्ध केले आहेत. प्रत्येक क्लस्टरमध्ये आठ शोध इंजिन आणि एक स्निपेट सर्व्हर असतो.

स्निपेट सर्व्हर स्थिर डेटासह की-व्हॅल्यू डेटाबेस चालवतो. दस्तऐवज जारी करण्यासाठी त्यांना आवश्यक आहे, उदाहरणार्थ, squeaker सह मांजरीचे वर्णन. शोध सर्व्हरची मेमरी लोड होऊ नये म्हणून डेटा वेगळ्या सर्व्हरवर हस्तांतरित केला जातो.

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

शोध स्वतःच खालीलप्रमाणे संरचित आहे: शोध विनंती आठपैकी कोणत्याही सर्व्हरवर येऊ शकते. समजा तो सर्व्हर 1 वर आला आहे. हा सर्व्हर सर्व युक्तिवादांवर प्रक्रिया करतो आणि काय आणि कसे शोधायचे ते समजतो. येणार्‍या विनंतीवर अवलंबून, सर्व्हर आवश्यक माहितीसाठी बाह्य सेवांना अतिरिक्त विनंत्या करू शकतो. एका विनंतीनंतर बाह्य सेवांसाठी दहा विनंत्या केल्या जाऊ शकतात.

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

प्रतिसाद प्राप्त झाल्यानंतर, परिणाम एकत्र केले जातात. शेवटी, परिणाम व्युत्पन्न करण्यासाठी स्निपेट सर्व्हरवर अनेक उपक्वेरी आवश्यक असू शकतात.

क्लस्टरमधील शोध क्वेरी यासारख्या दिसतात: /shard1?text=angry+cat. याव्यतिरिक्त, क्लस्टरमधील सर्व सर्व्हरमध्ये फॉर्मच्या सबक्वेरी सतत सेकंदातून एकदा केल्या जातात: /स्थिती.

चौकशी /स्थिती सर्व्हर उपलब्ध नसलेली परिस्थिती शोधते.

हे देखील नियंत्रित करते की सर्व सर्व्हरवर शोध इंजिन आवृत्ती आणि अनुक्रमणिका आवृत्ती समान आहे, अन्यथा क्लस्टरमध्ये विसंगत डेटा असेल.

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

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

परंतु दुसर्‍या वास्तुकलेचे संक्रमण अद्याप पूर्ण झालेले नाही. आता आम्हाला समर्पित स्निपेट सर्व्हरपासून मुक्त व्हायचे आहे. आणि नंतर क्लस्टरच्या संरचनेपासून पूर्णपणे दूर जा. हे आम्हाला सहजपणे स्केल करणे सुरू ठेवण्यास अनुमती देईल. एक अतिरिक्त बोनस म्हणजे लक्षणीय लोह बचत.

आणि आता आनंदी शेवट असलेल्या भयानक कथांकडे. सर्व्हर अनुपलब्धतेच्या अनेक प्रकरणांचा विचार करूया.

काहीतरी भयंकर घडले: एक सर्व्हर अनुपलब्ध आहे

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

स्थिती तपासणीद्वारे /स्थिती शेजारील सर्व्हर समजतात की एक अनुपलब्ध आहे. म्हणून, पूर्णता राखण्यासाठी, प्रति विनंती क्लस्टरमधील सर्व सर्व्हर /पिंग ते बॅलन्सरला प्रतिसाद देऊ लागतात की ते देखील अनुपलब्ध आहेत. असे दिसून आले की क्लस्टरमधील सर्व सर्व्हर मरण पावले (जे खरे नाही). आमच्या क्लस्टर योजनेचा हा मुख्य दोष आहे - म्हणूनच आम्हाला त्यापासून दूर जायचे आहे.

त्रुटीसह अयशस्वी झालेल्या विनंत्या इतर सर्व्हरवरील बॅलन्सरद्वारे पुन्हा पाठवल्या जातात.
बॅलन्सर मृत सर्व्हरवर वापरकर्ता रहदारी पाठवणे देखील थांबवतो, परंतु त्यांची स्थिती तपासणे सुरू ठेवतो.

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

आणखी वाईट: बरेच सर्व्हर अनुपलब्ध आहेत

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

जेव्हा डेटा सेंटरमधील अनेक सर्व्हर डाऊन होतात, तेव्हा बॅलन्सरला कळते की हे डेटा सेंटर सर्व ट्रॅफिकवर प्रक्रिया करू शकत नाही.

मग अतिरिक्त रहदारी यादृच्छिकपणे इतर डेटा केंद्रांवर वितरित करणे सुरू होते. सर्व काही कार्य करते, प्रत्येकजण आनंदी आहे.

आम्ही ते कसे करतो: प्रकाशन प्रकाशन

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

नंतर सेवा चाचणीसाठी आणली जाते, जिथे ऑपरेशनची स्थिरता तपासली जाते.

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

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

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

सर्व शुभेच्छा वापरकर्त्याला जातात: A/B चाचणी

सेवेतील बदलांमुळे खरे फायदे होतील की नाही हे नेहमीच स्पष्ट नसते. बदलांची उपयुक्तता मोजण्यासाठी, लोक A/B चाचणी घेऊन आले. मी तुम्हाला Yandex.Market शोध मध्ये ते कसे कार्य करते याबद्दल थोडेसे सांगेन.

हे सर्व नवीन CGI पॅरामीटर जोडण्यापासून सुरू होते जे नवीन कार्यक्षमता सक्षम करते. आमचे पॅरामीटर असू द्या: market_new_functionality=1. नंतर ध्वज उपस्थित असल्यास कोडमध्ये आम्ही ही कार्यक्षमता सक्षम करतो:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

नवीन कार्यक्षमता उत्पादनासाठी आणली जात आहे.

A/B चाचणी स्वयंचलित करण्यासाठी, एक समर्पित सेवा आहे जी तपशीलवार माहिती प्रदान करते येथे वर्णन केले आहे. सेवेत एक प्रयोग तयार केला जातो. रहदारी वाटा सेट केला आहे, उदाहरणार्थ, 15%. टक्केवारी प्रश्नांसाठी नाही तर वापरकर्त्यांसाठी सेट केली आहे. प्रयोगाचा कालावधी देखील दर्शविला जातो, उदाहरणार्थ, एक आठवडा.

एकाच वेळी अनेक प्रयोग केले जाऊ शकतात. इतर प्रयोगांसह छेदन करणे शक्य आहे की नाही हे आपण सेटिंग्जमध्ये निर्दिष्ट करू शकता.

परिणामी, सेवा आपोआप एक युक्तिवाद जोडते market_new_functionality=1 15% वापरकर्त्यांपर्यंत. ते निवडलेल्या मेट्रिक्सची स्वयंचलितपणे गणना देखील करते. प्रयोग पूर्ण झाल्यानंतर, विश्लेषक परिणाम पाहतात आणि निष्कर्ष काढतात. निष्कर्षांवर आधारित, उत्पादन किंवा परिष्करण करण्यासाठी रोल आउट करण्याचा निर्णय घेतला जातो.

बाजाराचा कुशल हात: उत्पादनात चाचणी

हे बर्‍याचदा घडते की आपल्याला उत्पादनातील नवीन कार्यक्षमतेच्या ऑपरेशनची चाचणी घेण्याची आवश्यकता असते, परंतु आपणास खात्री नसते की ते जास्त भार असलेल्या "लढाऊ" परिस्थितीत कसे वागेल.

एक उपाय आहे: CGI पॅरामीटर्समधील ध्वजांचा वापर केवळ A/B चाचणीसाठीच नाही तर नवीन कार्यक्षमतेची चाचणी घेण्यासाठी देखील केला जाऊ शकतो.

आम्ही एक साधन तयार केले आहे जे तुम्हाला सेवा धोक्यात न आणता हजारो सर्व्हरवर कॉन्फिगरेशन त्वरित बदलण्याची परवानगी देते. त्याला स्टॉप टॅप म्हणतात. लेआउटशिवाय काही कार्यक्षमता द्रुतपणे अक्षम करणे ही मूळ कल्पना होती. मग साधन विस्तारले आणि अधिक जटिल झाले.

सेवा प्रवाह आकृती खाली सादर केली आहे:

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

स्टॉप टॅपमध्ये तुम्ही दोन प्रकारची मूल्ये सेट करू शकता:

1) सशर्त अभिव्यक्ती. जेव्हा मूल्यांपैकी एक सत्य असेल तेव्हा लागू करा. उदाहरणार्थ:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

DC3 स्थानावर विनंतीवर प्रक्रिया केल्यावर "1" मूल्य लागू केले जाईल. आणि जेव्हा beru.ru साइटसाठी दुसऱ्या क्लस्टरवर विनंतीवर प्रक्रिया केली जाते तेव्हा मूल्य "4" असते.

2) बिनशर्त मूल्ये. कोणत्याही अटी पूर्ण न झाल्यास डीफॉल्टनुसार अर्ज करा. उदाहरणार्थ:

मूल्य, मूल्य!

जर एखादे मूल्य उद्गार बिंदूने संपत असेल, तर त्यास उच्च प्राधान्य दिले जाते.

CGI पॅरामीटर पार्सर URL पार्स करतो. नंतर स्टॉप टॅप मधील मूल्ये लागू करते.

खालील प्राधान्यांसह मूल्ये लागू केली जातात:

1. स्टॉप टॅप (उद्गारवाचक चिन्ह) वरून वाढीव प्राधान्यासह.
2. विनंतीचे मूल्य.
3. स्टॉप टॅप वरून डीफॉल्ट मूल्य.
4. कोडमधील डीफॉल्ट मूल्य.

सशर्त मूल्यांमध्ये दर्शविलेले बरेच ध्वज आहेत - ते आम्हाला ज्ञात असलेल्या सर्व परिस्थितींसाठी पुरेसे आहेत:

• माहिती केंद्र.
• पर्यावरण: उत्पादन, चाचणी, सावली.
• स्थळ: बाजार, बेरू.
• क्लस्टर क्रमांक.

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

तुम्हाला एखादी समस्या दिसल्यास, तुम्ही ताबडतोब ध्वज त्याच्या मागील मूल्यावर परत करू शकता आणि बदल परत आणले जातील.

या सेवेचे तोटे देखील आहेत: विकसकांना ते खूप आवडते आणि अनेकदा सर्व बदल स्टॉप टॅपमध्ये ढकलण्याचा प्रयत्न करतात. आम्ही दुरुपयोग रोखण्यासाठी प्रयत्न करत आहोत.

जेव्हा तुमच्याकडे उत्पादनासाठी रोल आउट करण्यासाठी स्थिर कोड तयार असेल तेव्हा स्टॉप टॅप दृष्टीकोन चांगले कार्य करते. त्याच वेळी, आपल्याला अद्याप शंका आहेत आणि आपण "लढाई" परिस्थितीत कोड तपासू इच्छित आहात.

तथापि, स्टॉप टॅप विकासादरम्यान चाचणीसाठी योग्य नाही. डेव्हलपरसाठी "शॅडो क्लस्टर" नावाचा एक वेगळा क्लस्टर आहे.

गुप्त चाचणी: छाया क्लस्टर

क्लस्टरपैकी एकाच्या विनंत्या छाया क्लस्टरमध्ये डुप्लिकेट केल्या जातात. परंतु बॅलन्सर या क्लस्टरच्या प्रतिसादांकडे पूर्णपणे दुर्लक्ष करतो. त्याच्या ऑपरेशनचे आकृती खाली सादर केले आहे.

आम्हाला एक चाचणी क्लस्टर मिळतो जो वास्तविक "लढाऊ" परिस्थितीत आहे. सामान्य वापरकर्ता रहदारी तेथे जाते. दोन्ही क्लस्टरमधील हार्डवेअर समान आहे, त्यामुळे कार्यप्रदर्शन आणि त्रुटींची तुलना केली जाऊ शकते.

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

निष्कर्ष

तर, आम्ही मार्केट शोध कसा तयार केला?

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

छाया क्लस्टर देखील आम्हाला मदत करते: आम्ही सेवा विकसित करू शकतो, प्रक्रियेत त्यांची चाचणी करू शकतो आणि वापरकर्त्याला त्रास देऊ शकत नाही.

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

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

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