हे हबर!

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

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

क्षैतिज स्केलिंग

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

उदाहरण के लिए, मैं एब्सट्रैक्ट क्लाउड फ़ाइल स्टोरेज लूंगा, यानी ओनक्लाउड, वनड्राइव इत्यादि का कुछ एनालॉग।

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

दृष्टिकोणों के बीच अंतर: ऊर्ध्वाधर स्केलिंग में, हम नोड्स की शक्ति बढ़ाने के लिए तैयार हैं, और क्षैतिज स्केलिंग में, हम लोड वितरित करने के लिए नए नोड्स जोड़ने के लिए तैयार हैं।

सीक्यूआरएस

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

इस दृष्टिकोण का पहला बोनस एक लंबे अनुरोध को निष्पादित करते समय कनेक्शन (शब्द के व्यापक अर्थ में) को तोड़ने की क्षमता है। उदाहरण के लिए, आइए अधिक या कम मानक अनुक्रम लें:

क्लाइंट ने सर्वर को एक अनुरोध भेजा।
सर्वर ने लंबी प्रोसेसिंग समय शुरू किया।
सर्वर ने क्लाइंट को परिणाम के साथ जवाब दिया।

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

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

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

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

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

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

इवेंट सोर्सिंग

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

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

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

हालाँकि, आइए मूल कार्य पर वापस जाएँ। यदि सिस्टम का हिस्सा बनाया जा सकता है आखिरकार संगति, तो हम निम्नलिखित आरेख का निर्माण कर सकते हैं।

इस दृष्टिकोण की महत्वपूर्ण विशेषताएं:

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

मैं आपको याद दिला दूं कि हम ऑनलाइन फ़ाइल भंडारण के मामले पर विचार कर रहे हैं। इस स्थिति में, सिस्टम कुछ इस तरह दिखेगा:

यह महत्वपूर्ण है कि आरेख में सेवाओं का मतलब एक अलग सर्वर नहीं है। यहां तक कि प्रक्रिया भी समान हो सकती है. एक और बात महत्वपूर्ण है: वैचारिक रूप से, इन चीज़ों को इस तरह से अलग किया जाता है कि क्षैतिज स्केलिंग आसानी से लागू की जा सके।

और दो उपयोगकर्ताओं के लिए आरेख इस तरह दिखेगा (विभिन्न उपयोगकर्ताओं के लिए इच्छित सेवाओं को अलग-अलग रंगों में दर्शाया गया है):

ऐसे संयोजन से बोनस:

सूचना प्रसंस्करण सेवाएँ अलग हो गई हैं। कतारें भी अलग हो गई हैं. यदि हमें सिस्टम थ्रूपुट को बढ़ाने की आवश्यकता है, तो हमें बस अधिक सर्वर पर अधिक सेवाएँ लॉन्च करने की आवश्यकता है।
जब हम किसी उपयोगकर्ता से जानकारी प्राप्त करते हैं, तो हमें डेटा पूरी तरह से सहेजे जाने तक इंतजार नहीं करना पड़ता है। इसके विपरीत, हमें बस "ठीक" उत्तर देना होगा और फिर धीरे-धीरे काम करना शुरू करना होगा। उसी समय, कतार चोटियों को सुचारू कर देती है, क्योंकि एक नई वस्तु को जोड़ना जल्दी से होता है, और उपयोगकर्ता को पूरे चक्र से गुजरने के लिए इंतजार नहीं करना पड़ता है।
उदाहरण के तौर पर, मैंने एक डिडुप्लीकेशन सेवा जोड़ी जो समान फ़ाइलों को मर्ज करने का प्रयास करती है। यदि 1% मामलों में यह लंबे समय तक काम करता है, तो ग्राहक शायद ही इसे नोटिस करेगा (ऊपर देखें), जो एक बड़ा प्लस है, क्योंकि अब हमें XNUMX% गति और विश्वसनीय होने की आवश्यकता नहीं है।

हालाँकि, नुकसान तुरंत दिखाई देते हैं:

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

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

नतीजतन:

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

Sharding

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

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

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

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

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

इस प्रकार, फ़ाइलों के लिए ऑनलाइन भंडारण के बारे में हमारे उदाहरण को जारी रखते हुए, ऐसी वास्तुकला हमें पहले से ही कई बोनस देती है:

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

स्थैतिक सामग्री होस्टिंग

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

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

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

सर्वर एक डाउनलोड यूआरएल प्रदान करता है। यह फ़ाइल_आईडी + कुंजी के रूप में हो सकता है, जहां कुंजी एक मिनी-डिजिटल हस्ताक्षर है जो अगले XNUMX घंटों के लिए संसाधन तक पहुंचने का अधिकार देता है।
फ़ाइल को निम्नलिखित विकल्पों के साथ सरल nginx द्वारा वितरित किया गया है:
- सामग्री कैशिंग. चूंकि यह सेवा एक अलग सर्वर पर स्थित हो सकती है, इसलिए हमने डिस्क पर सभी नवीनतम डाउनलोड की गई फ़ाइलों को संग्रहीत करने की क्षमता के साथ भविष्य के लिए खुद को आरक्षित छोड़ दिया है।
- कनेक्शन निर्माण के समय कुंजी की जाँच करना
वैकल्पिक: स्ट्रीमिंग सामग्री प्रसंस्करण। उदाहरण के लिए, यदि हम सेवा में सभी फ़ाइलों को संपीड़ित करते हैं, तो हम सीधे इस मॉड्यूल में अनज़िपिंग कर सकते हैं। परिणामस्वरूप: IO ऑपरेशन वहीं किए जाते हैं जहां वे होते हैं। जावा में एक संग्रहकर्ता आसानी से बहुत सारी अतिरिक्त मेमोरी आवंटित कर देगा, लेकिन व्यावसायिक तर्क के साथ रस्ट/सी++ सशर्त में एक सेवा को फिर से लिखना भी अप्रभावी हो सकता है। हमारे मामले में, विभिन्न प्रक्रियाओं (या यहां तक कि सेवाओं) का उपयोग किया जाता है, और इसलिए हम व्यावसायिक तर्क और आईओ संचालन को काफी प्रभावी ढंग से अलग कर सकते हैं।

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

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

हालाँकि, यदि हम अपने सिस्टम पर लौटते हैं, तो हमें एक समान आरेख मिलता है:

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

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

निष्कर्ष

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

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

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

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

स्रोत: www.habr.com

सुविधाजनक वास्तुशिल्प पैटर्न