ओपनस्टैक एलबास यूआई कार्यान्वयन

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

मेरी राय में, समस्या का समाधान काफी रचनात्मक निकला और मुझे बहुत सीमित ढांचे में इसकी तलाश करनी थी, इसलिए मुझे लगता है कि यह दिलचस्प हो सकता है।

सामने की भूमिका

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

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

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

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

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

समस्या का बयान

OpenStack LBaaS, मेरी राय में, सर्वरों के बीच लोड को संतुलित करने के लिए आवश्यक उपकरणों का एक हार्डवेयर-सॉफ़्टवेयर परिसर है। मेरे लिए यह महत्वपूर्ण है कि इसका कार्यान्वयन भौतिक प्रदर्शन पर, वस्तुनिष्ठ कारकों पर निर्भर करता है। इस वजह से, एपीआई में और इस एपीआई के साथ बातचीत करने के तरीकों में कुछ ख़ासियतें हैं।

उपयोगकर्ता इंटरफ़ेस विकसित करते समय, मुख्य रुचि बैकएंड की तकनीकी विशेषताएं नहीं है, बल्कि इसकी मौलिक क्षमताएं हैं। इंटरफ़ेस उपयोगकर्ता के लिए बनाया गया है, और उपयोगकर्ता को संतुलन मापदंडों के प्रबंधन के लिए एक इंटरफ़ेस की आवश्यकता है, और उपयोगकर्ता को बैकएंड कार्यान्वयन की आंतरिक विशेषताओं में गोता लगाने की आवश्यकता नहीं है।

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

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

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

OpenStack LBaaS की विशेषताएं

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

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

पहली विशेषता जो मुझे विकास के दौरान मिली, वह है बड़ी संख्या में मॉडल और रिश्तों के लिए आवश्यक है कि बैलेंसर को प्रदर्शित किया जा सके। ऑक्टेविया एपीआई 12 मॉडलों का वर्णन करता है, लेकिन क्लाइंट पक्ष के लिए केवल 7 की आवश्यकता होती है। इन मॉडलों में कनेक्शन होते हैं, अक्सर इसे अपभ्रंश किया जाता है, नीचे दी गई छवि एक अनुमानित आरेख दिखाती है:



"सेवन" बहुत प्रभावशाली नहीं लगता है, लेकिन वास्तव में, यह सुनिश्चित करने के लिए कि इंटरफ़ेस ठीक से काम करता है, इस पाठ को लिखने के समय, मुझे 16 डेटा मॉडल और उनके बीच लगभग 30 संबंधों का उपयोग करना था। चूंकि ओक्टाविया केवल एक बैलेंसर है, इसलिए इसे काम करने के लिए अन्य ओपनस्टैक मॉड्यूल की आवश्यकता होती है। और यह सब उपयोगकर्ता इंटरफ़ेस में केवल दो पृष्ठों के लिए आवश्यक है।

दूसरी और तीसरी विशेषताएं एसिंक्रोनस और ट्रांसेक्शनल ऑक्टेविया हैं। डेटा मॉडल में एक स्थिति फ़ील्ड होती है जो किसी ऑब्जेक्ट पर किए गए ऑपरेशन की स्थिति को दर्शाती है।
किसी ऑब्जेक्ट को पढ़ने की कार्रवाई समकालिक रूप से होती है और इसमें कोई प्रतिबंध नहीं है। लेकिन बनाने, अद्यतन करने और हटाने के संचालन में अनिश्चित समय लग सकता है। यह इस तथ्य के कारण ठीक है कि डेटा मॉडल में मोटे तौर पर बोलना, भौतिक अर्थ है।

निर्माण के लिए एक अनुरोध भेजने के बाद, हम जान सकते हैं कि रिकॉर्ड दिखाई दिया है, हम इसे पढ़ सकते हैं, लेकिन जब तक निर्माण कार्य पूरा नहीं हो जाता, हम इस रिकॉर्ड पर कोई अन्य कार्रवाई नहीं कर सकते। इस तरह के किसी भी प्रयास के परिणामस्वरूप त्रुटि होगी। ऑब्जेक्ट को बदलने का कार्य केवल तभी शुरू किया जा सकता है जब ऑब्जेक्ट ACTIVE स्थिति में हो; आप ACTIVE और ERROR स्थितियों में विलोपन के लिए ऑब्जेक्ट भेज सकते हैं।

ये स्टेटस वेबस्केट के माध्यम से आ सकते हैं, जो उनके प्रसंस्करण की सुविधा प्रदान करते हैं, लेकिन लेनदेन एक बहुत बड़ी समस्या है। किसी भी वस्तु में परिवर्तन करते समय, सभी संबंधित मॉडल लेन-देन में भी भाग लेंगे। उदाहरण के लिए, सदस्य में परिवर्तन करते समय, संबंधित पूल , श्रोता और लोडबेलर अवरुद्ध हो जाएंगे। यह वेब सॉकेट पर प्राप्त घटनाओं के संदर्भ में ऐसा दिखता है:

• पहले चार ईवेंट PENDING_UPDATE स्थिति में ऑब्जेक्ट्स का स्थानांतरण हैं: लक्ष्य फ़ील्ड में लेनदेन में भाग लेने वाली ऑब्जेक्ट का मॉडल नाम शामिल है;
• पांचवीं घटना सिर्फ एक डुप्लिकेट है (मुझे नहीं पता कि यह किससे जुड़ा है);
• अंतिम चार सक्रिय स्थिति में वापसी है। इस मामले में, यह एक वजन परिवर्तन ऑपरेशन है, और इसमें एक सेकंड से भी कम समय लगता है, लेकिन कभी-कभी इसमें बहुत अधिक समय लगता है।

आप स्क्रीनशॉट में भी देख सकते हैं कि घटनाओं का क्रम सख्त नहीं है। इस प्रकार, यह पता चला है कि किसी भी ऑपरेशन को शुरू करने के लिए, न केवल वस्तु की स्थिति को जानना आवश्यक है, बल्कि सभी निर्भरता की स्थिति भी है जो लेनदेन में भी भाग लेंगे।

उपयोगकर्ता इंटरफ़ेस सुविधाएँ

अब अपने आप को एक ऐसे उपयोगकर्ता के स्थान पर कल्पना करें, जिसे दो सर्वरों के बीच संतुलन के लिए कहीं और जानने की आवश्यकता है:

1. एक श्रोता बनाना आवश्यक है जिसमें संतुलन एल्गोरिथ्म को परिभाषित किया जाएगा।
2. एक पूल बनाएँ।
3. श्रोता को एक पूल सौंपें।
4. संतुलित पोर्ट के लिंक को पूल में जोड़ें।

हर बार ऑपरेशन के पूरा होने की प्रतीक्षा करना आवश्यक होता है, जो पहले से निर्मित सभी वस्तुओं पर निर्भर करता है।

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

मुझे नहीं पता कि इंटरफ़ेस धारणा के लिए कितना जटिल होना चाहिए, जहां उपयोगकर्ता को स्वयं ऊपर वर्णित बैकएंड की सभी तकनीकी विशेषताओं का पालन करना चाहिए। कंसोल के लिए, यह अनुमेय हो सकता है, क्योंकि इसके उपयोग से प्रौद्योगिकी में एक उच्च स्तर का विसर्जन होता है, लेकिन वेब के लिए ऐसा इंटरफ़ेस भयानक है।

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

इंटरफ़ेस को इस तरह से डिज़ाइन किया गया था जिसमें ऑपरेशन का कैस्केडिंग उपयोग शामिल है: इंटरफ़ेस में एक कार्रवाई में कई ऑपरेशन शामिल हो सकते हैं। इंटरफ़ेस का अर्थ यह नहीं है कि उपयोगकर्ता ऐसी क्रियाएं कर सकता है जो वर्तमान में संभव नहीं हैं, लेकिन इंटरफ़ेस मानता है कि उपयोगकर्ता को यह समझना चाहिए कि ऐसा क्यों है। इंटरफ़ेस एक संपूर्ण है, और इसलिए, इसके व्यक्तिगत तत्व मेटा-सूचना सहित विभिन्न निर्भर संस्थाओं से जानकारी का उपयोग कर सकते हैं।



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

विरोधाभासों का समाधान

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

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

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

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

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

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

समाधान वास्तुकला

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



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

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

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

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

सामान्य तौर पर, ऐसा भंडार काफी तुच्छ होता है और मैंने इसे स्वयं किया है, क्योंकि किसी तैयार कोड को किसी मौजूदा कोड बेस में एकीकृत करना अधिक कठिन होगा, लेकिन कार्य कतार में तैयार समाधान को संलग्न करना और भी कठिन होगा।

सभी कार्यों, जैसे संग्रह, में एक घोषणात्मक विवरण होता है और कारखाने द्वारा बनाया जाता है। कार्य विवरण में शुरू करने के लिए शर्तें और कार्यों की एक सूची हो सकती है जिन्हें वर्तमान एक के पूरा होने के बाद कतार में जोड़ना होगा।


ऊपर दिया गया उदाहरण पूल बनाने के कार्य का वर्णन करता है। निर्भरता में, बैलेंसर और श्रोता को संकेत दिया जाता है, डिफ़ॉल्ट रूप से, सक्रिय स्थिति के लिए एक चेक किया जाता है। बैलेंसर की वस्तु को अवरुद्ध कर दिया जाता है, क्योंकि कतार में प्रसंस्करण कार्य समकालिक रूप से हो सकते हैं, अवरुद्ध उस समय से टकराव से बचाते हैं जब निष्पादन के लिए अनुरोध भेजा गया था, लेकिन स्थिति अभी तक नहीं बदली है, लेकिन यह माना जाता है कि यह बदल जाएगा। PARENT के बजाय, यदि कार्यों के कैस्केड के परिणामस्वरूप पूल बनाया जाता है, तो ID को स्वचालित रूप से प्रतिस्थापित किया जाएगा।

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

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

निष्कर्ष

स्केलेबिलिटी की आवश्यकता ने एक घोषणात्मक दृष्टिकोण को जन्म दिया है। मॉडल और उनके बीच संबंधों को प्रदर्शित करने की आवश्यकता ने एक एकल भंडार का नेतृत्व किया है। आश्रित वस्तुओं के प्रसंस्करण की आवश्यकता कतार में चली गई है।

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

चयनकर्ता नियंत्रण कक्ष की ओर से , संतुलन प्रक्रिया सरल और सीधी है, जो सेवा ग्राहकों को लचीले ढंग से यातायात को नियंत्रित करने की क्षमता बनाए रखते हुए, बैलेंसर के स्वतंत्र कार्यान्वयन पर संसाधन खर्च नहीं करने की अनुमति देती है।

अब हमारे बैलेन्सर को एक्शन में आज़माएं और अपनी समीक्षा टिप्पणियों में लिखें।