हमने ललाट प्रणाली के कॉन्फ़िगरेशन मापदंडों के साथ काम को कैसे तेज किया

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



यह वह जगह है जहां हमने शुरू किया - यह पैरामीटर प्रबंधन सेवा का पहला कार्यान्वयन है:



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

इस दृष्टिकोण का एक फायदा है - सरलता। अधिक नुकसान हैं, हालांकि वे सभी संबंधित हैं:

• नेटवर्क पर भंडारण की लगातार पहुंच,
  
• डेटाबेस तक पहुँच के लिए उच्च प्रतियोगिता (हमारे पास यह एक नोड पर स्थित है),
  
• खराब प्रदर्शन।
  

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

दूसरा चरण: हमने सेवा पक्ष में डेटा को कैश करने का निर्णय लिया।



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

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

विकास का तीसरा चरण क्लाइंट-साइड डेटा कैशिंग है:



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

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

अंत में, हम इस समय अंतिम चरण पर आते हैं। इसमें हमें प्रतिक्रियात्मक घोषणापत्र में तैयार किए गए मूल सिद्धांतों द्वारा मदद की गई थी।

• उत्तरदायी: प्रणाली जितनी जल्दी हो सके जवाब देती है।
  
• लचीला: सिस्टम विफलता की स्थिति में भी प्रतिक्रिया देना जारी रखता है।
  
• इलास्टिक: सिस्टम लोड के अनुसार संसाधनों का उपयोग करता है।
  
• संदेश संचालित: सिस्टम घटकों के बीच अतुल्यकालिक और मुफ्त संदेश प्रदान करता है।
  

इस दृष्टिकोण से संबंधित योजना काफी सरल थी:



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

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

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

प्रौद्योगिकी चयन

योजना को मंजूरी देने के बाद, हमने इसके कार्यान्वयन के लिए उत्पादों की खोज शुरू की। Vertx.io , Akka.io और स्प्रिंग बूट के बीच चयन करें ।



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

परिणामस्वरूप, वर्टेक्स जीत गया। वैसे, उन्होंने JUG सम्मेलन में उनके बारे में बहुत सारी बातें की, और वास्तव में कई कंपनियां इसका उपयोग करती हैं। यहाँ डेवलपर की साइट से एक स्क्रीनशॉट है:



Vertx.io पर, हमारे समाधान की कार्यान्वयन योजना इस प्रकार है:



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

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

इवेंट बस एक वर्टेक्स सेवा है जो वर्टिकल के साथ-साथ पुलों के माध्यम से घटनाओं को भेजती है। वेबसैट पुल के माध्यम से शामिल है, जो इस मामले में उपयोग किया जाता है। जब पैरामीटर परिवर्तन की घटनाएं आती हैं, तो इवेंट बस उन्हें क्लाइंट को भेजता है।

अंत में, क्लाइंट साइड पर, एक साधारण वेब क्लाइंट यहां लागू किया जाता है, जो ईवेंट (पैरामीटर परिवर्तन) की सदस्यता लेता है और इन परिवर्तनों को पृष्ठों पर प्रदर्शित करता है।

यह कैसे काम करता है

हम दिखाते हैं कि वेब एप्लिकेशन के माध्यम से सब कुछ कैसे काम करता है।


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

वह सब है। आप मेरे गिट रिपॉजिटरी में डेमो का स्रोत कोड पा सकते हैं, और टिप्पणियों में सवाल पूछ सकते हैं।