अहो हाब्र!

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

या लेखात मी लोकप्रिय पद्धतींबद्दल थोडक्यात बोलेन जे आपल्याला जलद आणि दोष-सहिष्णु सेवा तयार करण्यास अनुमती देईल. तथापि, संभाव्य विकास योजनांमधून मी सध्याच्या योजनांचीच निवड केली आहे वापरण्यास सोप. प्रत्येक आयटमसाठी, आपल्याकडे एकतर तयार लायब्ररी आहेत किंवा आपल्याकडे क्लाउड प्लॅटफॉर्म वापरून समस्या सोडवण्याची संधी आहे.

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

सर्वात सोपा आणि सुप्रसिद्ध मुद्दा. पारंपारिकपणे, सर्वात सामान्य दोन लोड वितरण योजना क्षैतिज आणि अनुलंब स्केलिंग आहेत. पहिल्या प्रकरणात तुम्ही सेवांना समांतर चालवण्यास अनुमती देता, ज्यामुळे त्यांच्या दरम्यान भार वितरीत होतो. दुसऱ्यामध्ये तुम्ही अधिक शक्तिशाली सर्व्हर ऑर्डर करा किंवा कोड ऑप्टिमाइझ करा.

उदाहरणार्थ, मी ॲबस्ट्रॅक्ट क्लाउड फाइल स्टोरेज घेईन, म्हणजे, OwnCloud, OneDrive इत्यादीचे काही ॲनालॉग.

अशा सर्किटचे एक मानक चित्र खाली आहे, परंतु ते केवळ सिस्टमची जटिलता दर्शवते. शेवटी, आम्हाला सेवा कशा प्रकारे सिंक्रोनाइझ करणे आवश्यक आहे. जर वापरकर्त्याने टॅब्लेटवरून फाइल सेव्ह केली आणि नंतर ती फोनवरून पहायची असेल तर काय होईल?

दृष्टिकोनांमधील फरक: उभ्या स्केलिंगमध्ये, आम्ही नोड्सची शक्ती वाढवण्यास तयार आहोत आणि क्षैतिज स्केलिंगमध्ये, आम्ही लोड वितरित करण्यासाठी नवीन नोड्स जोडण्यासाठी तयार आहोत.

CQRS

कमांड क्वेरी रिस्पॉन्सिबिलिटी सेग्रिगेशन एक महत्त्वाचा नमुना, कारण तो वेगवेगळ्या क्लायंटना केवळ वेगवेगळ्या सेवांशी कनेक्ट होऊ देत नाही, तर समान इव्हेंट प्रवाह देखील प्राप्त करू देतो. साध्या अनुप्रयोगासाठी त्याचे फायदे इतके स्पष्ट नाहीत, परंतु व्यस्त सेवेसाठी ते अत्यंत महत्वाचे (आणि सोपे) आहे. त्याचे सार: येणारे आणि जाणारे डेटा प्रवाह एकमेकांना छेदू नयेत. म्हणजेच, तुम्ही विनंती पाठवू शकत नाही आणि प्रतिसादाची अपेक्षा करू शकत नाही; त्याऐवजी, तुम्ही सेवा A ला विनंती पाठवा, परंतु सेवे B कडून प्रतिसाद प्राप्त करा.

या दृष्टिकोनाचा पहिला बोनस म्हणजे एक दीर्घ विनंती अंमलात आणताना कनेक्शन (शब्दाच्या व्यापक अर्थाने) तोडण्याची क्षमता. उदाहरणार्थ, अधिक किंवा कमी मानक क्रम घेऊ:

1. क्लायंटने सर्व्हरला विनंती पाठवली.
2. सर्व्हरने बराच वेळ प्रक्रिया सुरू केली.
3. सर्व्हरने निकालासह क्लायंटला प्रतिसाद दिला.

चला कल्पना करूया की बिंदू 2 मध्ये कनेक्शन तुटले आहे (किंवा नेटवर्क पुन्हा कनेक्ट केले आहे, किंवा वापरकर्ता दुसर्या पृष्ठावर गेला आहे, कनेक्शन तोडून). या प्रकरणात, सर्व्हरला नक्की काय प्रक्रिया केली गेली याबद्दल माहितीसह वापरकर्त्यास प्रतिसाद पाठविणे कठीण होईल. CQRS वापरून, क्रम थोडा वेगळा असेल:

1. क्लायंटने अद्यतनांची सदस्यता घेतली आहे.
2. क्लायंटने सर्व्हरला विनंती पाठवली.
3. सर्व्हरने "विनंती स्वीकारली" असा प्रतिसाद दिला.
4. सर्व्हरने बिंदू “1” वरून चॅनेलद्वारे निकालासह प्रतिसाद दिला.

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

विशेष म्हणजे, येणाऱ्या संदेशांवर प्रक्रिया करण्याचा कोड क्लायंटद्वारेच प्रभावित झालेल्या इव्हेंटसाठी आणि इतर क्लायंटसह इतर इव्हेंटसाठी समान (100% नाही) बनतो.

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

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

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

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

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

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

तथापि, मूळ कार्याकडे वळूया. जर प्रणालीचा भाग सह बांधला जाऊ शकतो अंतिम सुसंगतता, नंतर आपण खालील आकृती तयार करू शकतो.

या पद्धतीची महत्त्वपूर्ण वैशिष्ट्ये:

• प्रत्येक येणारी विनंती एका रांगेत ठेवली जाते.
• विनंतीवर प्रक्रिया करताना, सेवा इतर रांगेत कार्ये देखील ठेवू शकते.
• प्रत्येक इनकमिंग इव्हेंटमध्ये एक आयडेंटिफायर असतो (जे डुप्लिकेशनसाठी आवश्यक आहे).
• रांग वैचारिकदृष्ट्या "केवळ संलग्न करा" योजनेनुसार कार्य करते. तुम्ही त्यातून घटक काढू शकत नाही किंवा त्यांची पुनर्रचना करू शकत नाही.
• रांग FIFO योजनेनुसार कार्य करते (टॉटोलॉजीबद्दल क्षमस्व). जर तुम्हाला समांतर अंमलबजावणी करायची असेल, तर एका टप्प्यावर तुम्ही वस्तू वेगवेगळ्या रांगेत हलवाव्यात.

मी तुम्हाला आठवण करून देतो की आम्ही ऑनलाइन फाइल स्टोरेजच्या बाबतीत विचार करत आहोत. या प्रकरणात, सिस्टम यासारखे काहीतरी दिसेल:

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

आणि दोन वापरकर्त्यांसाठी आकृती असे दिसेल (वेगवेगळ्या वापरकर्त्यांसाठी असलेल्या सेवा वेगवेगळ्या रंगात दर्शविल्या जातात):

अशा संयोजनातून बोनस:

• माहिती प्रक्रिया सेवा विभक्त केल्या आहेत. रांगाही वेगळ्या केल्या आहेत. जर आम्हाला सिस्टम थ्रूपुट वाढवायची असेल तर आम्हाला फक्त अधिक सर्व्हरवर अधिक सेवा सुरू करण्याची आवश्यकता आहे.
• जेव्हा आम्हाला वापरकर्त्याकडून माहिती मिळते, तेव्हा आम्हाला डेटा पूर्णपणे सेव्ह होईपर्यंत प्रतीक्षा करावी लागत नाही. त्याउलट, आपल्याला फक्त “ठीक आहे” असे उत्तर द्यावे लागेल आणि नंतर हळूहळू काम सुरू करावे लागेल. त्याच वेळी, रांग शिखरांना गुळगुळीत करते, कारण नवीन ऑब्जेक्ट जोडणे त्वरीत होते आणि वापरकर्त्याला संपूर्ण चक्रातून पूर्ण पास होण्याची प्रतीक्षा करावी लागत नाही.
• उदाहरण म्हणून, मी एक डीडुप्लिकेशन सेवा जोडली आहे जी एकसारख्या फाइल्स विलीन करण्याचा प्रयत्न करते. जर ते 1% प्रकरणांमध्ये बराच काळ कार्य करत असेल, तर क्लायंटला ते क्वचितच लक्षात येईल (वर पहा), जे एक मोठे प्लस आहे, कारण आम्हाला यापुढे XNUMX% वेग आणि विश्वासार्ह असणे आवश्यक नाही.

तथापि, तोटे त्वरित दृश्यमान आहेत:

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

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

परिणामी:

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

सामायिकरण

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

• प्रकारानुसार फायली विभक्त करा. उदाहरणार्थ, चित्रे/व्हिडिओ डीकोड केले जाऊ शकतात आणि अधिक कार्यक्षम स्वरूप निवडले जाऊ शकतात.
• देशानुसार वेगळी खाती. अनेक कायद्यांमुळे याची गरज भासू शकते, परंतु ही वास्तुरचना योजना आपोआप अशी संधी उपलब्ध करून देते

जर तुम्हाला एका स्टोरेजमधून दुसऱ्या स्टोरेजमध्ये डेटा ट्रान्सफर करायचा असेल, तर स्टँडर्ड साधन यापुढे पुरेसे नाहीत. दुर्दैवाने, या प्रकरणात, आपल्याला रांग थांबवावी लागेल, स्थलांतर करावे लागेल आणि नंतर ते सुरू करावे लागेल. सर्वसाधारणपणे, डेटा "ऑन द फ्लाय" हस्तांतरित केला जाऊ शकत नाही, तथापि, जर इव्हेंट रांग पूर्णपणे संग्रहित केली गेली असेल आणि तुमच्याकडे मागील स्टोरेज स्थितींचे स्नॅपशॉट असतील, तर आम्ही खालीलप्रमाणे इव्हेंट पुन्हा प्ले करू शकतो:

• इव्हेंट सोर्समध्ये, प्रत्येक इव्हेंटचा स्वतःचा आयडेंटिफायर असतो (आदर्शपणे, कमी होत नाही). याचा अर्थ आपण स्टोरेजमध्ये फील्ड जोडू शकतो - शेवटच्या प्रक्रिया केलेल्या घटकाचा आयडी.
• आम्ही रांगेची डुप्लिकेट करतो जेणेकरून सर्व इव्हेंट्सवर अनेक स्वतंत्र स्टोरेजसाठी प्रक्रिया केली जाऊ शकते (पहिला तो आहे ज्यामध्ये डेटा आधीपासूनच संग्रहित आहे आणि दुसरा नवीन आहे, परंतु तरीही रिक्त आहे). दुसरी रांग अर्थातच अद्याप प्रक्रिया केली जात नाही.
• आम्ही दुसरी रांग लाँच करतो (म्हणजे, आम्ही इव्हेंट रीप्ले करणे सुरू करतो).
• जेव्हा नवीन रांग तुलनेने रिकामी असते (म्हणजे, घटक जोडणे आणि ते पुनर्प्राप्त करणे यामधील सरासरी वेळेतील फरक स्वीकार्य आहे), तुम्ही वाचकांना नवीन स्टोरेजवर स्विच करणे सुरू करू शकता.

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

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

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

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

हा मुद्दा अगदी स्पष्ट वाटू शकतो, परंतु अधिक किंवा कमी मानक लोड केलेल्या अनुप्रयोगासाठी ते अद्याप आवश्यक आहे. त्याचे सार सोपे आहे: सर्व स्थिर सामग्री त्याच सर्व्हरवरून वितरित केली जात नाही जिथे अनुप्रयोग स्थित आहे, परंतु विशेषत: या कार्यासाठी समर्पित केलेल्या विशिष्ट सामग्रीमधून. परिणामी, ही ऑपरेशन्स जलद केली जातात (सशर्त nginx जावा सर्व्हरपेक्षा फायली अधिक जलद आणि कमी खर्चात सर्व्ह करते). प्लस CDN आर्किटेक्चर (सामग्री वितरण नेटवर्क) आम्हाला आमच्या फायली अंतिम वापरकर्त्यांच्या जवळ शोधण्याची परवानगी देते, ज्याचा सेवेसह काम करण्याच्या सोयीवर सकारात्मक परिणाम होतो.

स्थिर सामग्रीचे सर्वात सोपे आणि मानक उदाहरण म्हणजे वेबसाइटसाठी स्क्रिप्ट आणि प्रतिमांचा संच. त्यांच्याबरोबर सर्व काही सोपे आहे - ते आगाऊ ओळखले जातात, नंतर संग्रहण CDN सर्व्हरवर अपलोड केले जाते, तेथून ते अंतिम वापरकर्त्यांना वितरित केले जातात.

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

• सर्व्हर डाउनलोड URL प्रदान करतो. हे फाईल_आयडी + की फॉर्मचे असू शकते, जेथे की ही एक मिनी-डिजिटल स्वाक्षरी असते जी पुढील 24 तासांसाठी संसाधनात प्रवेश करण्याचा अधिकार देते.
• फाईल खालील पर्यायांसह साध्या nginx द्वारे वितरीत केली जाते:
  • सामग्री कॅशिंग. ही सेवा वेगळ्या सर्व्हरवर स्थित असल्याने, आम्ही डिस्कवर सर्व नवीनतम डाउनलोड केलेल्या फायली संचयित करण्याच्या क्षमतेसह भविष्यासाठी राखीव ठेवल्या आहेत.
  • कनेक्शन तयार करताना की तपासत आहे
• पर्यायी: प्रवाह सामग्री प्रक्रिया. उदाहरणार्थ, जर आपण सेवेतील सर्व फायली कॉम्प्रेस केल्या तर आपण या मॉड्यूलमध्ये थेट अनझिप करू शकतो. परिणामस्वरुप: IO ऑपरेशन्स जेथे आहेत तेथे केल्या जातात. Java मधील आर्काइव्हर सहजपणे बरीच अतिरिक्त मेमरी वाटप करेल, परंतु व्यवसाय तर्कासह सेवा रस्ट/C++ कंडिशनलमध्ये पुन्हा लिहिणे देखील कुचकामी असू शकते. आमच्या बाबतीत, वेगवेगळ्या प्रक्रिया (किंवा अगदी सेवा) वापरल्या जातात आणि म्हणून आम्ही व्यवसाय तर्कशास्त्र आणि IO ऑपरेशन्स प्रभावीपणे वेगळे करू शकतो.

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

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

तथापि, जर आम्ही आमच्या सिस्टमवर परतलो, तर आम्हाला एक समान आकृती मिळेल:

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

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

निष्कर्ष

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

तथापि, सर्वात महत्त्वाचे म्हणजे, हे सर्व नमुने आधुनिक अनुप्रयोगांमध्ये लागू करणे खूप सोपे झाले आहे (जर ते योग्य असतील तर नक्कीच). क्लाउड्स लगेच शार्डिंग आणि क्षैतिज स्केलिंग ऑफर करतात, जे वेगवेगळ्या डेटा सेंटर्समध्ये स्वतःहून भिन्न समर्पित सर्व्हर ऑर्डर करण्यापेक्षा खूप सोपे आहे. RX सारख्या ग्रंथालयांच्या विकासामुळे CQRS खूप सोपे झाले आहे. सुमारे 10 वर्षांपूर्वी, एक दुर्मिळ वेबसाइट याचे समर्थन करू शकते. Apache Kafka सह तयार कंटेनर धन्यवाद सेट करणे देखील इव्हेंट सोर्सिंग आश्चर्यकारकपणे सोपे आहे. 10 वर्षांपूर्वी ही एक नावीन्यपूर्ण गोष्ट होती, आता हे सामान्य झाले आहे. स्टॅटिक कंटेंट होस्टिंगच्या बाबतीतही असेच आहे: अधिक सोयीस्कर तंत्रज्ञानामुळे (तपशीलवार दस्तऐवजीकरण आणि उत्तरांचा मोठा डेटाबेस आहे या वस्तुस्थितीसह), हा दृष्टिकोन आणखी सोपा झाला आहे.

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

आणि सर्वात महत्त्वाचे: जर तुमच्याकडे साधा अनुप्रयोग असेल तर कृपया या पद्धतींचा वापर करू नका. होय, ते सुंदर आणि मनोरंजक आहेत, परंतु 100 लोकांच्या शिखर भेटीच्या साइटसाठी, आपण बऱ्याचदा क्लासिक मोनोलिथसह जाऊ शकता (किमान बाहेरील, आतील सर्व काही मॉड्यूलमध्ये विभागले जाऊ शकते इ.).

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