मेरा वेब ऐप कितना लचीला होना चाहिए?

हाल ही में, मैंने अपने वेब ऐप (एक सी # एएसपीनेट एमवीसी एप्लिकेशन) के भीतर अपवादों के संचालन के बारे में अपने मालिक के साथ कुछ तर्कों में खुद को पाया है।मेरा वेब ऐप कितना लचीला होना चाहिए?

बॉस::

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

मी: "अधिकतर एप्लिकेशन में प्रत्येक पृष्ठ डेटाबेस (त्रुटि पृष्ठ को छोड़कर) के लिए डेटाबेस का उपयोग करता है, त्रुटि पृष्ठ दिखाने के अलावा कोई उचित विकल्प नहीं है।"

बॉस: "हमारा आवेदन अधिक लचीला होना चाहिए - उस एप्लिकेशन का हिस्सा जिसे डेटाबेस एक्सेस की आवश्यकता नहीं है, अभी भी कार्य करना चाहिए।"

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

सामान्यतः, "सामान्य" वेब एप्लिकेशन (मिशन-महत्वपूर्ण, आदि नहीं ...) के लिए "अच्छे" डेवलपर्स इस तरह की स्थितियों को संभालने के लिए पर्याप्त रूप से अपने कोड को लचीला बनाने की कोशिश करते समय कितना समय व्यतीत करते हैं। मेरे मालिक को लगता है कि कोड लगभग किसी भी स्थिति को संभालने में सक्षम होना चाहिए (क्या आप सिर्फ अपवाद नहीं ले सकते हैं?)। मैं नहीं देखता कि विफलता के कई संभावित बिंदु होने पर यह आर्थिक कैसे हो सकता है।

स्रोत

2010-06-30 Krazzy

यह विकी नहीं होना चाहिए? – AGoodDisplayName

इस अर्थव्यवस्था में, जो बॉस आपको बताता है वह करें। –

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

मैं इसे तय करने के लिए मालिक को छोड़ दूंगा। उसे घंटों में एक अनुमान बताएं कि ऐप को "लचीला" बनाने में कितना समय लगेगा और वह तय करेगा कि यह निवेश के लायक है या नहीं।

स्रोत

2010-06-30 19:13:09 Vitalik

वास्तव में, यह दृष्टिकोण वास्तव में लेता है। यह आमतौर पर काफी प्रभावी होता है हालांकि मुझे कभी-कभी भावनाएं होती हैं कि मेरे अनुमान अधिक हैं और यह "केवल अपवाद को पकड़ने" का मामला होना चाहिए, जो शायद ही कभी है। – Krazzy

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

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

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

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

स्रोत

2010-06-30 19:15:28 Polaris878

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

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

स्रोत

2010-06-30 19:16:04 bpeterson76

शायद डेटाबेस उदाहरण एक अच्छा नहीं था क्योंकि यह थोड़ा चरम है। यह आमतौर पर तीसरे पक्ष की वेब सेवाओं और इसी तरह के साथ एकीकृत करने का विषय है। – Krazzy

अधिकांश एप्लिकेशन कि मुझे लगता है कि पर काम किया है कर रहे हैं मुख्य डेटा संचालित होने पर मुख्य डेटा संचालित होता है जब मुख्य डेटाबेस (यानी 99% पृष्ठों को शक्ति देता है) नीचे है। (आप उन्हें एक कस्टम स्क्रीन दिखाना चाहते हैं, न कि उन्हें सर्वर त्रुटि पृष्ठ प्राप्त करने के लिए)

बाहरी सेवाओं के लिए जैसे कि एक SMTP सर्वर या डेटाबेस जो कि बाकी के अधिकांश द्वारा उपयोग नहीं किया जाता है ऐप में हमारे पास आमतौर पर कोड होगा जो सेवा/डेटाबेस डाउन/पहुंच योग्य होने पर केवल पृष्ठ फ़ीडबैक प्रदर्शित करता है।

यह वास्तव में ग्राहक/हितधारक ऊपर है, बस यह निर्धारित करें कि वे क्या करना चाहते हैं जब डेटाबेस डाउन हो और उनके लिए ऐसा करें। इसमें समय लगेगा, लेकिन यह एक अनजान ऐप या किसी अन्य कोडिंग डरावनी नहीं होनी चाहिए।

स्रोत

2010-06-30 19:16:08 heisenberg

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

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

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

स्रोत

2010-06-30 19:34:44 Paco

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

आप पहले से ही इस छोटे पैटर्न के बारे में पता हो सकता है, लेकिन यहाँ यह वैसे भी है:

 try 
     { 
      //get data 
     } 
     catch (Exception ex) 
     { 
      if (ExceptionPolicy.HandleException(ex, "Data Access Exception")) 
       throw ex; 
     }

स्रोत

2010-07-01 00:30:46

शायद तुम सिर्फ एक सामान्य त्रुटि पृष्ठ जब साथ डेटा की एक खाली सेट और एक "उपयोगकर्ता के अनुकूल दिखा रहे हैं "त्रुटि संदेश होगा।

तो, उदाहरण के लिए, यदि आप उपयोगकर्ताओं/संदेशों/तारीख की सूची प्रदर्शित कर रहे हैं लेकिन सेवा जहां आप इसे एकत्र करते हैं, तो नीचे है, तो आप शायद एक खाली सेट दिखा सकते हैं।

तो बजाय दिखा:

500 Server Error 




.

आप की तरह कुछ दिखा सकता है:

User | Message  | Date 
------------------------------ 
    No data available* 




* Xyz service is be down.

आपका ऐप अब भी काम करेंगे नहीं, क्योंकि डेटा उपलब्ध नहीं है, लेकिन इसके बजाय फेंक करने के लिए इस बात का अंतिम उपयोगकर्ता चेहरा, आप प्लेसहोल्डर को बिना डेटा के रख सकते हैं।

यह आपको क्या उपयोग पर निर्भर करता है एक बहुत भिन्न है, लेकिन सामान्य शब्दों में यह उतना ही आसान के रूप में हो सकता है: है, तो साथ के साथ भरने

List<Data> data = EmptyList<Data>(); 

try 
{ 
    data = service.GetData(); 
} catch(ServiceUnavailableException error) 
{ 
    errorPage.SetMessage(service.GetName() + " service is down "); 
    // log the error message 
    logger.doLog(error); 
}

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

स्रोत

2010-07-01 00:51:22 OscarRyz

-1

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

लचीला ऐप्स सुनिश्चित करने के लिए अधिक प्रयास निश्चित रूप से आवश्यक है, हालांकि एक बार ज्ञान प्राप्त और लागू हो जाने पर, अगली बार, यह बहुत आसान हो जाता है। वसंत या नेटफ्लिक्स के सर्किट ब्रेकर जैसे जेनेरिक पुस्तकालय पहले से ही उपलब्ध हैं जो एकीकरण पर, कुछ पहलुओं में असफलताओं के साथ सौदा कर सकते हैं। एक बेवकूफ ऑपरेशन को पुनः प्रयास करना भी लागू करना आसान है।

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

स्रोत

2017-08-19 10:52:51

प्रश्न स्वयं (अब) ऑफ-विषय (नोटिस यह 7 साल पहले प्रकाशित हुआ था)। यहां तक कि स्वीकृत उत्तर केवल एक राय है। कृपया अधिक राय के साथ इसमें शामिल न करें (आपका एन-स्तरीय विविधता है, और आधुनिक माइक्रोस्कोप आर्किटेक्चर पर विचार नहीं कर रहा है)। इसके अलावा, मैंने आपके ब्लॉग के लिंक को हटा दिया - यह इसके लिए जगह नहीं है। –

मेरा वेब ऐप कितना लचीला होना चाहिए?

उत्तर

संबंधित मुद्दे