हाल के वर्षों में, आवेदन की आवश्यकताओं में काफी बदलाव आया है। दर्जनों सर्वर, कुछ सेकंड में प्रतिक्रिया समय, ऑफ़लाइन रखरखाव, जो घंटों तक चल सकता है, डेटा के गीगाबाइट - ये कुछ साल पहले बड़े अनुप्रयोग थे। आज, एप्लिकेशन बिल्कुल सामान्य मोबाइल फोन से लेकर हजारों प्रोसेसर के क्लस्टर तक, सब कुछ पर काम करते हैं। उपयोगकर्ताओं को एक मिलीसेकंड प्रतिक्रिया समय और एक सौ प्रतिशत अपटाइम की उम्मीद है, जबकि डेटा पेटाबाइट्स में बढ़ गया है।
प्रारंभ में, यह आला Google या ट्विटर जैसी बड़ी अभिनव इंटरनेट कंपनियों द्वारा कब्जा कर लिया गया था, लेकिन उद्योग के कई क्षेत्रों में इस तरह की एप्लिकेशन आवश्यकताएं उभरने लगीं। नई आवश्यकताओं को पूरा करने के लिए वित्त और दूरसंचार कंपनियों ने पहले नई प्रथाओं को पेश किया था, और अब बाकी को खींचा जा रहा है।
नई आवश्यकताओं के लिए नई तकनीकों की आवश्यकता है। पिछले निर्णय प्रबंधित सर्वर और कंटेनरों पर केंद्रित हैं। कूलर सर्वर की खरीद और मल्टीथ्रेडिंग के उपयोग के माध्यम से स्केलिंग हासिल की गई थी। नए सर्वर जोड़ने के लिए, हमें जटिल, अक्षम और महंगे मालिकाना समाधानों का उपयोग करना पड़ा।
हालाँकि, प्रगति अभी भी नहीं है। बदलती जरूरतों को पूरा करने के लिए एप्लीकेशन आर्किटेक्चर विकसित हुआ है। इस वास्तुकला के आधार पर विकसित किए गए अनुप्रयोग, हम
प्रतिक्रियात्मक अनुप्रयोग कहते हैं। यह आर्किटेक्चर प्रोग्रामर्स को
ईवेंट-ओरिएंटेड, स्केलेबल, फॉल्ट-टॉलरेंट और रेस्पॉन्सिव ऐप्स बनाने की अनुमति देता है - रियल-टाइम एप्लिकेशन जो एक स्केलेबल और फॉल्ट-टॉलरेंट स्टैक के आधार पर अच्छी प्रतिक्रिया समय प्रदान करते हैं और जो मल्टी-कोर और क्लाउड आर्किटेक्चर पर तैनात करना आसान है। ये विशेषताएं प्रतिक्रियात्मकता के लिए महत्वपूर्ण हैं।
प्रतिक्रियाशील अनुप्रयोग
मरियम वेबस्टर शब्दकोश
"बाहरी घटनाओं पर प्रतिक्रिया देने के लिए तैयार" के रूप में प्रतिक्रियाशील को परिभाषित करता है, जिसका अर्थ है कि घटक हमेशा सक्रिय होते हैं और संदेश प्राप्त करने के लिए हमेशा तैयार रहते हैं। यह परिभाषा प्रतिक्रियाशील अनुप्रयोगों के सार को प्रकट करती है, जो सिस्टम पर ध्यान केंद्रित करती है:
- घटनाओं पर प्रतिक्रिया
इवेंट ओरिएंटेशन का मतलब निम्न गुणों से है - बढ़े हुए भार का जवाब
मापनीयता पर ध्यान दें, सार्वजनिक संसाधनों तक प्रतिस्पर्धी पहुंच कम से कम हो। - विफलताओं का जवाब
सभी स्तरों पर पुनर्प्राप्त करने की क्षमता के साथ फेलसेफ सिस्टम बनाए जा रहे हैं। - उपयोगकर्ताओं के लिए प्रतिक्रिया
लोड-स्वतंत्र प्रतिक्रिया समय की गारंटी
इन विशेषताओं में से प्रत्येक एक प्रतिक्रियाशील अनुप्रयोग के लिए आवश्यक है। वे सभी एक-दूसरे पर निर्भर हैं, लेकिन मानक बहु-स्तरीय वास्तुकला के स्तरों के रूप में नहीं। इसके विपरीत, वे संपूर्ण प्रौद्योगिकी स्टैक पर लागू गुणों का वर्णन करते हैं:
आगे, हम इन चार विशेषताओं में से प्रत्येक पर एक नज़र डालेंगे और देखेंगे कि वे एक-दूसरे से कैसे संबंधित हैं।
इवेंट ओरिएंटेशन
यह महत्वपूर्ण क्यों है?
अतुल्यकालिक मॉडल का उपयोग करने वाले अनुप्रयोग विशुद्ध रूप से तुल्यकालिक कॉल के आधार पर अनुप्रयोगों की तुलना में बहुत कम
कनेक्टिविटी प्रदान करते हैं। प्रेषक और रिसीवर को इस बात का विवरण दिए बिना कार्यान्वित किया जा सकता है कि सिस्टम में घटनाओं को कैसे वितरित किया जाता है, जो इंटरफेस को ट्रांसमिशन की सामग्री पर ध्यान केंद्रित करने की अनुमति देता है। इससे एक कार्यान्वयन होता है जो विस्तार करना, संशोधित करना और बनाए रखना आसान होता है, अधिक लचीलापन प्रदान करता है, और समर्थन की लागत को कम करता है।
चूंकि अतुल्यकालिक बातचीत के प्राप्तकर्ता एक संदेश प्राप्त होने तक निष्क्रिय होते हैं, इसलिए यह दृष्टिकोण संसाधनों के कुशल उपयोग की अनुमति दे सकता है, जिससे बड़ी संख्या में प्राप्तकर्ता उसी हार्डवेयर स्ट्रीम में काम कर सकते हैं। इस प्रकार, एक गैर-अवरोधक अनुप्रयोग में अवरुद्ध तुल्यकालन और संचार प्राइमेटिव के आधार पर एक पारंपरिक अनुप्रयोग की तुलना में
कम विलंबता और
उच्चतर थ्रूपुट हो सकता है। इससे लेनदेन की लागत कम होती है, प्रोसेसर संसाधनों का उपयोग बढ़ता है और अंत उपयोगकर्ताओं को अधिक खुश करता है।
प्रमुख भवन खंड
घटना-उन्मुख अनुप्रयोग में, घटक
संदेश भेजने और प्राप्त करने के लिए एक दूसरे के साथ बातचीत करते हैं - तथ्यों का वर्णन करने वाले जानकारी के असतत टुकड़े। इन संदेशों को अतुल्यकालिक और गैर-अवरुद्ध मोड में भेजा और प्राप्त किया जाता है। इवेंट-ओरिएंटेड सिस्टम में
पुल या
पोल की तुलना में मॉडल को
धक्का देने की अधिक संभावना है। यानी वे अपने उपभोक्ताओं को डेटा तब उपलब्ध करवाते हैं, जब डेटा उपलब्ध होने के बजाय, लगातार अनुरोध या डेटा की प्रतीक्षा करके संसाधनों को बर्बाद करते हैं।
- एसिंक्रोनस मैसेजिंग का मतलब है कि इसकी प्रकृति के अनुप्रयोग में उच्च स्तर की प्रतियोगिता है और यह मल्टी-कोर आर्किटेक्चर पर बदलाव के बिना काम कर सकता है। कोई भी सीपीयू कोर किसी भी संदेश को संसाधित कर सकता है, जो अधिक से अधिक समानांतर क्षमता देता है।
- गैर-अवरोधन का मतलब काम करने की क्षमता को जारी रखना है ताकि आवेदन हर समय उत्तरदायी हो , यहां तक कि विफलता या चरम भार की स्थितियों में भी। ऐसा करने के लिए, सीपीयू, मेमोरी और नेटवर्क जैसे जवाबदेही सुनिश्चित करने के लिए आवश्यक सभी संसाधनों का एकाधिकार नहीं होना चाहिए। यह कम विलंबता, अधिक बैंडविड्थ और बेहतर मापनीयता का परिणाम देगा।
पारंपरिक सर्वर आर्किटेक्चर सार्वजनिक उत्परिवर्तनीय स्थिति और एकल थ्रेड पर अवरुद्ध संचालन का उपयोग करते हैं। इससे सिस्टम को स्केल करना मुश्किल हो जाता है। एक सार्वजनिक परिवर्तनशील राज्य को सिंक्रनाइज़ेशन की आवश्यकता होती है, जो जटिलता और गैर-नियतात्मकता को जोड़ता है, जिससे कोड को समझना और बनाए रखना मुश्किल हो जाता है। थ्रेड को स्लीप मोड में स्विच करना सीमित संसाधनों का उपभोग करता है, और जागना महंगा है।
घटनाओं की पीढ़ी और उनके प्रसंस्करण को अलग करते हुए, हम प्लेटफ़ॉर्म को प्रवाह के बीच सिंक्रनाइज़ेशन और प्रेषण घटनाओं के विवरण का ध्यान रखने की अनुमति देते हैं, जबकि हम स्वयं उच्च स्तर के अमूर्त और व्यावसायिक तर्क पर ध्यान केंद्रित करते हैं। हम सोचते हैं कि कहाँ से और कहाँ से घटनाओं को भेजा जाता है, और कैसे घटक एक-दूसरे के साथ बातचीत करते हैं, बजाय थ्रेड्स या लॉक्स जैसे निम्न-स्तरीय प्राइमेटिव में खुदाई करने के लिए।
इवेंट-उन्मुख सिस्टम घटकों और उप-प्रणालियों के बीच खराब कनेक्टिविटी प्रदान करते हैं। इस तरह की कनेक्टिविटी, जैसा कि हम बाद में देखेंगे, स्केलेबिलिटी और फॉल्ट टॉलरेंस के लिए आवश्यक शर्तों में से एक है। घटकों के बीच जटिल और मजबूत निर्भरता के बिना, सिस्टम का विस्तार करने के लिए न्यूनतम प्रयास की आवश्यकता होती है।
जब किसी एप्लिकेशन को उच्च प्रदर्शन और अच्छी मापनीयता की आवश्यकता होती है, तो यह अनुमान लगाना मुश्किल होता है कि अड़चनें कहां हो सकती हैं। इसलिए, यह बहुत महत्वपूर्ण है कि संपूर्ण समाधान अतुल्यकालिक और गैर-अवरुद्ध है। एक विशिष्ट अनुप्रयोग के लिए, इसका मतलब है कि वास्तुकला पूरी तरह से घटना-उन्मुख होना चाहिए, एक ग्राफिकल इंटरफ़ेस (ब्राउज़र, आरईएसटी, आदि) के माध्यम से उपयोगकर्ता के अनुरोधों के साथ शुरू होता है और वेब परत में सेवाओं, कैश और डेटाबेस के साथ समाप्त होता है। यदि इनमें से कम से कम एक परत इस आवश्यकता को पूरा नहीं करती है - यह डेटाबेस में अवरोधक प्रश्न बनाएगी, एक सार्वजनिक परिवर्तनशील स्थिति का उपयोग करेगी, महंगी समकालिक संचालन को कॉल करेगी - तो पूरे स्टैक की मृत्यु हो जाएगी और वृद्धि में देरी और स्केलेबिलिटी गिरने के कारण उपयोगकर्ताओं को नुकसान होगा।
आवेदन को
ऊपर से नीचे तक प्रतिक्रियाशील होना चाहिए।
श्रृंखला में कमजोर कड़ी को खत्म करने की आवश्यकता को
अमदहल के कानून द्वारा अच्छी तरह से चित्रित
किया गया है, जो विकिपीडिया राज्यों के अनुसार है:
एक कार्यक्रम को गति देकर इसे समानांतर करना कार्यक्रम के अनुक्रमिक भाग तक सीमित है। उदाहरण के लिए, यदि कम्प्यूटेशनल वॉल्यूम के 95% को समानांतर किया जा सकता है, तो सैद्धांतिक अधिकतम त्वरण 20 से अधिक नहीं हो सकता है, चाहे उपयोग किए गए प्रोसेसर की संख्या।
scalability
यह महत्वपूर्ण क्यों है?
शब्द स्केलेबल को मरियम वेबस्टर डिक्शनरी द्वारा
"आसानी से विस्तार या आधुनिकीकरण करने में सक्षम" के रूप में परिभाषित किया गया है। स्केलेबल एप्लिकेशन को स्केल तक बढ़ाया जा सकता है। यह आवेदन लोच देने से प्राप्त होता है, एक संपत्ति जो सिस्टम को मांग पर खिंचाव या अनुबंध (नोड्स जोड़ने या हटाने) की अनुमति देती है। इसके अलावा, यह आर्किटेक्चर एप्लिकेशन को फिर से डिज़ाइन या फिर से लिखने की आवश्यकता के बिना विस्तार या अनुबंध (अधिक या कम प्रोसेसर पर तैनात) करना संभव बनाता है। लोच, क्लाउड में कार्य करने की लागत को कम करता है, जबकि हम केवल उसी चीज का भुगतान करते हैं जो हम वास्तव में उपयोग करते हैं।
स्केलेबिलिटी जोखिमों को प्रबंधित करने में भी मदद करती है: बहुत कम उपकरण ग्राहक के असंतोष और हानि का कारण बन सकते हैं, और बहुत अधिक बस निष्क्रिय (कर्मचारियों के साथ) और अनावश्यक लागतों का नेतृत्व करेंगे। एक और स्केलेबल एप्लिकेशन उपकरण उपलब्ध होने पर एक स्थिति के जोखिम को कम करता है, लेकिन एप्लिकेशन इसका उपयोग नहीं कर सकता है: अगले 10 वर्षों में हमारे पास सैकड़ों प्रोसेसर होंगे, यदि हजारों हार्डवेयर थ्रेड नहीं हैं, और उनकी क्षमता के उपयोग के लिए सूक्ष्म स्तर पर स्केलेबिलिटी की आवश्यकता होती है।
प्रमुख भवन खंड
अतुल्यकालिक संदेश पर आधारित एक घटना-आधारित प्रणाली स्केलेबिलिटी का आधार है। घटकों और उप-प्रणालियों की कमजोर कनेक्टिविटी और स्थान की स्वतंत्रता आपको एक ही शब्दार्थ के साथ एक ही सॉफ्टवेयर मॉडल के भीतर रहते हुए कई नोड्स पर सिस्टम को तैनात करने की अनुमति देती है। जब नए नोड जोड़े जाते हैं, तो सिस्टम थ्रूपुट बढ़ता है। कार्यान्वयन के संदर्भ में, क्लस्टर या डेटा केंद्र में अधिक कोर या अधिक नोड पर एक सिस्टम को तैनात करने के बीच कोई अंतर नहीं होना चाहिए। अनुप्रयोग टोपोलॉजी कॉन्फ़िगरेशन समस्या और / या अनुकूली रन-टाइम एल्गोरिदम बन जाता है जो सिस्टम पर लोड की निगरानी करता है। इसे ही हम
स्थान पारदर्शिता कहते हैं।
यह समझना महत्वपूर्ण है कि लक्ष्य - पारदर्शी वितरित कंप्यूटिंग, वितरित वस्तुओं, या आरपीसी संचार का आविष्कार करने के लिए नहीं - पहले ही कोशिश की जा चुकी है और यह विचार विफल हो गया है। इसके बजाय, हमें एक अतुल्यकालिक संदेश तंत्र के माध्यम से सीधे
नेटवर्क मॉडल में इसका प्रतिनिधित्व करके
नेटवर्क को
गले लगाना चाहिए। सही मापनीयता स्वाभाविक रूप से वितरित कंप्यूटिंग और उनके अंतर-नोड इंटरैक्शन पर निर्भर करती है, जिसका अर्थ है कि एक नेटवर्क को दरकिनार करना जो स्वाभाविक रूप से
अविश्वसनीय है । इसलिए, यह महत्वपूर्ण है कि प्रोग्राम मॉडल में असाधारण स्थितियों की सीमाओं, व्यापार-उतार और परिदृश्यों को ध्यान में रखते हुए लीक मॉडल के स्क्रीन के पीछे छिपने के बजाय उन्हें स्पष्ट रूप से "सरलीकृत" करने की कोशिश करें। परिणामस्वरूप, सॉफ़्टवेयर उपकरणों के साथ खुद को प्रदान करना उतना ही महत्वपूर्ण है, जिसमें एक वितरित वातावरण में उत्पन्न होने वाली विशिष्ट समस्याओं को हल करने के लिए बिल्डिंग ब्लॉक होते हैं - जैसे कि आम सहमति तक पहुंचने के लिए तंत्र या मैसेजिंग इंटरफेस जिसमें विश्वसनीयता का उच्च स्तर होता है।
दोष सहिष्णुता
यह महत्वपूर्ण क्यों है?
आवेदन की विफलता सबसे नुकसानदायक चीजों में से एक है जो किसी व्यवसाय के लिए हो सकती है। आमतौर पर यह इस तथ्य की ओर जाता है कि सेवा केवल बंद हो जाती है, लाभ की धारा में एक अंतर छोड़कर। लंबे समय में, यह ग्राहक असंतोष और खराब प्रतिष्ठा का कारण बन सकता है, जो व्यवसाय को और भी अधिक गंभीर रूप से चोट पहुंचाएगा। हैरानी की बात है कि, आवेदन की आवश्यकता की आवश्यकता को तदर्थ तकनीशियनों द्वारा सार्वभौमिक रूप से अनदेखा या संबोधित किया जाता है। इसका मतलब अक्सर यह होता है कि समस्या को गलत तरीके से उन उपकरणों के उपयोग से संबोधित किया जाता है जो बहुत गलत और कच्चे हैं। एक सामान्य समाधान क्रैश रिकवरी के साथ एप्लिकेशन सर्वर क्लस्टरिंग का उपयोग करना है। दुर्भाग्य से, ऐसे तैयार किए गए समाधान बेहद महंगे हैं और, इसके अलावा, खतरनाक - वे पूरे क्लस्टर को संभावित रूप से "कैस्केड" कर सकते हैं। कारण यह है कि गलती प्रबंधन की समस्या को बहुत छोटे पैमाने के नक्शे पर हल किया जा रहा है, हालांकि इसे छोटे घटकों की बातचीत के स्तर पर विस्तार से काम किया जाना चाहिए।
एक प्रतिक्रियात्मक अनुप्रयोग में, दोष सहिष्णुता बाद के लिए नहीं छोड़ी जाती है, लेकिन शुरुआत से ही वास्तुकला का हिस्सा है। प्रोग्राम मॉडल में प्रथम श्रेणी की वस्तुओं के रूप में विफलताओं का रवैया उन्हें जवाब देने और उन्हें प्रबंधित करने के कार्य को सुविधाजनक बनाएगा, जो आवेदन को विफलताओं के प्रति सहिष्णु बना देगा और सिस्टम को ऑपरेशन के दौरान "ठीक" और "मरम्मत" करने की अनुमति देगा। असाधारण स्थितियों को संभालने के लिए पारंपरिक तरीके इसे प्राप्त नहीं कर सकते हैं, क्योंकि समस्याएं गलत स्तरों पर हल नहीं होती हैं - हम या तो अपवादों को संभालते हैं जहां वे होते हैं, या हम पूरे आवेदन के लिए एक पुनर्प्राप्ति प्रक्रिया शुरू करते हैं।
प्रमुख भवन खंड
विफलताओं को प्रबंधित करने के लिए, हमें उन्हें अलग करने के लिए एक रास्ता चाहिए ताकि वे अन्य स्वस्थ घटकों में न फैलें और उन्हें एक सुरक्षित स्थान से संदर्भ से बाहर की निगरानी करें जिसमें विफलताएं हो सकती हैं। एक तरीका जो दिमाग में आता है वह है सिस्टम को इस तरह से डिब्बों में विभाजित करने वाले बुल्केहेड्स यदि किसी एक डिब्बे में पानी भर जाता है (फेल हो जाता है), तो यह दूसरे डिब्बों को प्रभावित नहीं करता है। यह कैस्केडिंग विफलताओं की क्लासिक समस्या को रोकता है और आपको अलगाव में समस्याओं को हल करने की अनुमति देता है।
एक घटना-चालित मॉडल जो स्केलेबिलिटी प्रदान करता है, दोष सहिष्णुता समस्या को हल करने के लिए आवश्यक प्राइमेटिव भी प्रदान करता है। एक इवेंट-संचालित मॉडल में कमजोर कनेक्टिविटी हमें पूरी तरह से पृथक घटकों के साथ प्रदान करती है जिसमें विफलताओं को आवश्यक विवरणों के साथ संदेशों में एन्क्रिप्ट किया जाता है और अन्य घटकों को अग्रेषित किया जाता है, जो त्रुटियों का विश्लेषण करते हैं और तय करते हैं कि उन्हें कैसे जवाब दिया जाए।
यह दृष्टिकोण एक प्रणाली बनाता है जिसमें:
- व्यापार तर्क साफ रहता है, त्रुटि से निपटने से अलग;
- विफलताओं को स्पष्ट रूप से प्रतिरूपित किया जाता है ताकि संकलित, निगरानी, नियंत्रण और विन्यास को घोषित रूप से परिभाषित किया जा सके;
- सिस्टम खुद को "ठीक" कर सकता है और अपने आप ठीक हो सकता है।
सबसे अच्छा, अगर डिब्बों को एक बड़े निगम की तरह, पदानुक्रमित तरीके से आयोजित किया जाता है, जहां समस्याएं एक स्तर तक बढ़ जाती हैं, जिसमें उचित कार्रवाई करने की पर्याप्त शक्ति होती है।
इस मॉडल की शक्ति यह है कि यह विशुद्ध रूप से घटना-उन्मुख है - यह प्रतिक्रियाशील घटकों और अतुल्यकालिक घटनाओं पर आधारित है, और इसलिए इसमें
स्थान पारदर्शिता है । व्यवहार में, इसका अर्थ है कि इसका शब्दार्थ इस बात पर निर्भर नहीं करता है कि यह स्थानीय सर्वर पर काम करता है या वितरित वातावरण में।
कोमलता
यह महत्वपूर्ण क्यों है?
उत्तरदायी को मरियम-वेबस्टर डिक्शनरी द्वारा
"जल्दी से जवाब देने या उचित रूप से
जवाब देने" के रूप में परिभाषित किया गया
है। ध्यान दें कि हम इस शब्द का प्रयोग नीचे दिए गए सामान्य अर्थों में करेंगे और इसे CSS
वेब प्रश्नों और
प्रगतिशील सुधारों के साथ
उत्तरदायी वेब डिज़ाइन के साथ भ्रमित नहीं करेंगे।
उत्तरदायी अनुप्रयोग वास्तविक समय के अनुप्रयोग हैं, वे आकर्षक हैं, कार्यक्षमता में समृद्ध हैं और साझाकरण प्रदान करते हैं। जवाबदेही और सहभागिता के माध्यम से ग्राहकों के साथ एक खुला और निरंतर संवाद बनाए रखा जाता है। यह ग्राहकों को अधिक उत्पादक बनाता है, समस्याओं और पूर्ण कार्यों को हल करने के लिए किसी भी समय स्थिरता और तत्परता की भावना पैदा करता है। ऐसा ही एक उदाहरण Google डॉक्स है, जो वास्तविक समय के सह-संपादन का समर्थन करता है, जिससे उपयोगकर्ता सीधे एक-दूसरे के संपादन देख सकते हैं।
अनुप्रयोगों को समय पर ढंग से घटनाओं का जवाब देना चाहिए, यहां तक कि विफलता की स्थिति में भी। यदि एप्लिकेशन उचित समय के भीतर प्रतिक्रिया नहीं करता है (जिसे विलंबता भी कहा जाता है), तो वास्तव में यह उपलब्ध नहीं है और इसलिए इसे
गलती सहिष्णु नहीं माना जा सकता है।
कुछ अनुप्रयोगों के लिए एक तंग वास्तविक समय के ढांचे में रहने में विफलता, जैसे कि हथियारों या चिकित्सा से संबंधित, पूरी तरह से सिस्टम विफलता के लिए टेंटामाउंट है। सभी अनुप्रयोगों की ऐसी सख्त आवश्यकताएं नहीं हैं। कई अनुप्रयोग जल्दी से बेकार हो जाते हैं यदि वे अस्थायी आवश्यकताओं को पूरा करने के लिए बंद हो जाते हैं, उदाहरण के लिए, एक ऑपरेशन जो व्यापारिक संचालन करता है वह वर्तमान लेनदेन को खो सकता है यदि इसके पास समय पर जवाब देने का समय नहीं है।
ऑनलाइन रिटेल स्टोर जैसे अधिक सामान्य अनुप्रयोग, प्रतिक्रिया समय बढ़ने पर राजस्व खो देते हैं। उपयोगकर्ता संवेदनशील अनुप्रयोगों के साथ अधिक गहनता से बातचीत करते हैं , जिससे बड़ी मात्रा में खरीदारी होती है।प्रमुख भवन खंड
प्रतिक्रियाशील एप्लिकेशन अवलोकन मॉडल, ईवेंट फ़्लो और राज्य क्लाइंट का उपयोग करते हैं।अवलोकन किए गए मॉडल अन्य प्रणालियों को घटनाओं को प्राप्त करने की अनुमति देते हैं जब उनका राज्य बदलता है। यह उपयोगकर्ताओं और प्रणालियों के बीच वास्तविक समय का संचार प्रदान करता है। उदाहरण के लिए, जब कई उपयोगकर्ता एक ही मॉडल पर एक साथ काम कर रहे हैं, तो मॉडल को लॉक करने की आवश्यकता को समाप्त करते हुए, परिवर्तन उनके बीच प्रतिक्रियात्मक रूप से सिंक्रनाइज़ किए जा सकते हैं।घटनाओं की धाराएं मूल अमूर्तता का निर्माण करती हैं, जिस पर ऐसे रिश्ते बनाए जाते हैं। उन्हें प्रतिक्रियाशील रखकर, हम अवरुद्ध करने से बचते हैं और रूपांतरणों और संचारों को अतुल्यकालिक और गैर-अवरुद्ध करने की अनुमति देते हैं।प्रतिक्रियात्मक अनुप्रयोगों को एल्गोरिदम के आदेशों का ज्ञान होना चाहिएयह सुनिश्चित करने के लिए कि घटनाओं की प्रतिक्रिया का समय भार की परवाह किए बिना ओ (1) या कम से कम ओ (लॉग एन) से अधिक नहीं है। स्केलिंग फैक्टर को शामिल किया जा सकता है, लेकिन यह ग्राहकों, सत्रों, उत्पादों या सौदों की संख्या पर निर्भर नहीं होना चाहिए।लोड प्रोफ़ाइल से स्वतंत्र विलंबता को बनाए रखने में मदद के लिए यहां कुछ रणनीतियाँ दी गई हैं:- विस्फोटक ट्रैफ़िक के मामले में, प्रतिक्रियात्मक अनुप्रयोगों को महंगे संचालन की लागत को कम करना चाहिए, जैसे कि I / O या प्रतिस्पर्धी डेटा विनिमय, समझ के साथ बैचिंग का उपयोग करना और अंतर्निहित संसाधनों की बारीकियों को ध्यान में रखना।
- प्रवाह की तीव्रता को ध्यान में रखते हुए कतारों को सीमित किया जाना चाहिए, प्रतिक्रिया समय के लिए इन आवश्यकताओं के साथ कतारों की लंबाई को लिटिल के नियम के अनुसार निर्धारित किया जाना चाहिए ।
- .
- .
एक उदाहरण के रूप में, उच्च गुणवत्ता वाले इंटरैक्शन अनुभव के साथ उपयोगकर्ता को प्रदान करने के लिए समृद्ध क्लाइंट (ब्राउज़र, मोबाइल एप्लिकेशन) के साथ एक उत्तरदायी वेब एप्लिकेशन पर विचार करें। यह एप्लिकेशन क्लाइंट पक्ष पर तर्क और स्टोर स्टेट को निष्पादित करता है, जिसमें प्रेक्षित मॉडल वास्तविक समय में डेटा में बदलाव होने पर यूजर इंटरफेस को अपडेट करने के लिए एक तंत्र प्रदान करते हैं। वेबसॉकेट्स या सर्वर-सेंटेड ईवेंट जैसी तकनीकें यूजर इंटरफेस को घटनाओं के प्रवाह से सीधे जुड़ने की अनुमति देती हैं, जिससे पूरा सिस्टम बैक-एंड लेयर से शुरू होकर क्लाइंट के साथ समाप्त होता है। यह प्रतिक्रियाशील अनुप्रयोगों को स्केलेबिलिटी और फॉल्ट टॉलरेंस को बनाए रखते हुए, अतुल्यकालिक और गैर-ब्लॉकिंग डेटा ट्रांसफर के माध्यम से ब्राउज़र और मोबाइल एप्लिकेशन को घटनाओं को आगे बढ़ाने की अनुमति देता है।अब यह स्पष्ट हो गया है कि कैसे प्रतिक्रिया के चार "व्हेल": घटना-उन्मुख , मापनीयता , दोष सहिष्णुता, और जवाबदेही एक दूसरे के साथ जुड़े हुए हैं और एक पूरे का निर्माण करते हैं:
निष्कर्ष
सॉफ्टवेयर सिस्टम के विकास में आधुनिक समस्याओं को हल करने के लिए प्रतिक्रियाशील अनुप्रयोग एक संतुलित दृष्टिकोण है। वे एक ईवेंट-ओरिएंटेड और मैसेजिंग- ओरिएंटेड फ्रेमवर्क पर बनाए गए हैं और स्केलेबिलिटी और रिसिलिएशन के लिए उपकरण प्रदान करते हैं । इसके शीर्ष पर, वे समृद्ध और उत्तरदायी उपयोगकर्ता इंटरैक्शन इंटरफेस का समर्थन करते हैं । हम उम्मीद करते हैं कि सिस्टम, जिनकी संख्या तेजी से बढ़ रही है, निकट भविष्य में इस प्रकटीकरण का पालन करेंगे।