बैकएंड प्रोसेसिंग के लिए एज़ूर वेब भूमिका का पुन: उपयोग करना अच्छा विचार है?

Question

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

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

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

बैकएंड प्रोसेसिंग के लिए वेब भूमिकाओं का पुन: उपयोग करना अच्छा विचार है? मुझे किस कमी की उम्मीद करनी चाहिए?

Answer 1

ध्वनि आप पहले से ही क्या जब कई भूमिकाएं उपयोग करने के बारे में सोचने के लिए की एक बहुत अच्छा विचार है की तरह:

• 2 उदाहरणों SLA को पूरा करने के लिए (हालांकि कुछ पृष्ठभूमि कार्य वास्तव में अंत अगर SLA की जरूरत नहीं है के लिए लागत उपयोगकर्ता प्रभाव नहीं देखता)
• अलग पैमाने इकाइयों

हालांकि: यदि आप एक भूमिका में सब कुछ चलाते हैं, तो सब कुछ एक साथ मापता है। यदि, कहें, आपके पास पोर्ट 8000 पर एक प्रशासनिक वेबसाइट है, तो आपको ट्रैफ़िक के साथ पोर्ट 80 पर मुख्य साइट को स्लैम करने पर आपका उपयोगकर्ता आधार पहुंचने में कठिनाई हो सकती है।

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

Answer 2

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

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

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

मेरा 2 सेंट।:)

Answer 3

मैं आपको अलग-अलग भूमिकाओं के रूप में विकसित करने का सुझाव दूंगा: एक वेब भूमिका और कार्यकर्ता भूमिका, और फिर उन्हें एक ही वेब भूमिका में संयोजित करें।

इस तरह, भविष्य में आप आसानी से वास्तविक अलग-अलग भूमिकाओं में परिवर्तित हो सकते हैं, यदि आवश्यक हो।

अधिक जानकारी के लिए

: http://www.31a2ba2a-b718-11dc-8314-0800200c9a66.com/2010/12/how-to-combine-worker-and-web-role-in.html http://wely-lau.net/2011/02/25/combining-web-and-worker-role-by-utilizing-worker-role-concept/