हे हबर!

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

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

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

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

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

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

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

सीक्यूआरएस

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ऐसे संयोजन से मिलने वाले बोनस:

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

हालाँकि, इसके नकारात्मक पहलू तुरंत स्पष्ट हो जाते हैं:

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

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

नतीजतन:

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

Sharding

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

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

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

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

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

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

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

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

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

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

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

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

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

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

हालाँकि, अगर हम अपनी प्रणाली पर वापस लौटें, तो हमें इस तरह की योजना मिलती है:

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

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

निष्कर्ष

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

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

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

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

स्रोत: www.habr.com