बड़े आवेदन के लिए Node.js विश्वसनीयता

Question

मैं नोड.जेएस के लिए नया हूं और वर्तमान में इसकी विश्वसनीयता पर सवाल उठा रहा हूं।

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

1. उपयोग डेमॉन या forever तरह मॉड्यूल स्वचालित रूप से सर्वर को पुनः आरंभ करने जब यह दुर्घटनाओं: वहाँ 2 समाधान है कि मैंने पाया है। जिस चीज़ को मुझे इस बारे में पसंद नहीं है वह यह है कि सर्वर अभी भी एक या दो के लिए नीचे है (एक बड़ी साइट के लिए, जो अनुरोध के सैकड़ों (हजारों?) हो सकता है)।

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

क्या कोई भी नोड.जेएस अनुभवी पिच कर सकता है?

Answer 1

अपवाद सर्वर को क्रैश नहीं करते हैं, वे अपवाद उठाते हैं।

नोड.जेएस में त्रुटियां जो पूरी प्रक्रिया को कम करती हैं, एक अलग कहानी है।

आपकी सर्वश्रेष्ठ शर्त (जिसे आपको तकनीक के साथ करना चाहिए), यह आपके आवेदन के साथ जल्द से जल्द यह जांचने के लिए जांच कर रहा है कि यह फिट बैठता है या नहीं।

Answer 2

आपको आधार प्रक्रिया का पूरा नियंत्रण मिला है, और यह एक विशेषता है।

यदि आप नोड को अपाचे/PHP सेटअप में तुलना करते हैं तो उत्तरार्द्ध वास्तव में एक साधारण नोड सर्वर होने के बराबर है जो प्रत्येक आने वाले अनुरोध को अपनी प्रक्रिया में भेजता है जिसे अनुरोध संभालने के बाद समाप्त कर दिया जाता है।

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

नोड एक बहुत ही लचीला उपकरण है, यदि आपको यह लचीलापन की आवश्यकता है तो यह अच्छा है, लेकिन इसे संभालने के लिए कुछ कौशल लेता है।

Answer 3

स्वत: पुनरारंभ और लोड संतुलन के लिए, मैं सुझाव दूंगा कि आप Learnboost's up बैलेंसर देखें।

यह आपको किसी भी अनुरोध को छोड़ दिए बिना लोड-बैलेंसर के पीछे एक कर्मचारी को फिर से लोड करने की अनुमति देता है। यह कार्यकर्ता की ओर नए अनुरोधों निर्देशन बंद हो जाता है, लेकिन मौजूदा अनुरोध करता है कि पहले से ही कार्य किया जा रहा है के लिए, यह अनुरोध सही मायने में प्रक्रिया को बंद करने से पहले समाप्त होने की प्रतीक्षा करने के लिए workerTimeout रियायती अवधि प्रदान करता है।

आप इस रणनीति को uncaughtException ईवेंट से ट्रिगर करने के लिए अनुकूलित कर सकते हैं।

Answer 4

एक अपवाद अपवाद होगा, अगर पकड़ा नहीं गया है, तो सर्वर को क्रैश करें। कुछ गलत वर्तनी फ़ंक्शन को कॉल करने जैसा है। मैं ऐसे अपवादों को पकड़ने के लिए process.on('uncaughtException') का उपयोग करता हूं।यदि आप इसका उपयोग करते हैं, तो हाँ, process.on('uncaughtException') पर भेजी गई त्रुटि कम जानकारीपूर्ण है।

मैं आमतौर पर कमांड लाइन झंडे की अनुमति देने के लिए nomnom जैसे मॉड्यूल को शामिल करता हूं। मैं --exceptions नामक एक को शामिल करता हूं, जो सेट करते समय process.on('uncaughtException') को बाईपास करता है। असल में, अगर मुझे लगता है कि बेजोड़ अपवाद हो रहे हैं तो मैं, विकास में, --exceptions के साथ ऐप शुरू करता हूं ताकि जब यह त्रुटि उठाई जाए तो इसे कैद नहीं किया जाएगा, जिससे नोड स्टैक ट्रेस को थूकने और फिर मरने का कारण बनता है। यह आपको बताता है कि यह किस लाइन पर हुआ, और किस फाइल में।

अपवादों को कैप्चर करना इसका एक तरीका है। लेकिन, जैसा कि आपने कहा था, इसका मतलब है कि यदि कोई त्रुटि होती है तो परिणामस्वरूप उपयोगकर्ता प्रतिक्रिया प्राप्त नहीं कर सकते हैं, और cetera। मैं वास्तव में त्रुटि दुर्घटना सर्वर को देने की सिफारिश करेंगे। (मैं ऐप्स में process.on('uncaughtException') का उपयोग करता हूं, वेबसर्वर नहीं)। और forever का उपयोग कर। तथ्य यह है कि वेबसर्वर को दुर्घटनाग्रस्त होने की संभावना बेहतर है और उसके बाद आपको जो ठीक करने की आवश्यकता है उसे बेनकाब करें।

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

तथ्य यह है कि किसी भी प्रणाली में भाषा या प्लेटफॉर्म से स्वतंत्र बग मौजूद होंगे। और यह जानना आपके लिए घातक होना बेहतर है कि वे जानते हैं कि वे क्या हुआ। और समय के साथ यह आपको इस त्रुटि के बारे में और अधिक जागरूक होने का कारण बनता है। मैं तुम्हारे बारे में नहीं जानता, लेकिन मुझे बहुत से PHP देवताओं को पता है जो समय के बाद समान सामान्य गलतियों को करते हैं।