आप परिवर्तनशील निर्भरता संघर्षों को कैसे देखते हैं जो केवल रन-टाइम में ज्ञात हैं? [बन्द है]


9

आप आम तौर पर बड़े सॉफ्टवेयर प्रोजेक्ट्स में रन-टाइम पर होने वाली ट्रांसेटिव डिपेंडेंसी मुद्दों पर कैसे पहुँचते हैं?

पिछले तीन हफ्तों से, मैं सॉफ़्टवेयर के एक अन्य घटक के भीतर सॉफ़्टवेयर के एक बड़े टुकड़े के एक घटक को शुरू करने की कोशिश कर रहा हूं, लेकिन यह संक्रमणीय निर्भरता के कारण मर जाता है जो केवल रन-टाइम पर ज्ञात होते हैं।

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

उपयोग में सैकड़ों निर्भरताएं हैं, और उपकरण से जुड़े लगभग 50 उप-प्रोजेक्ट हैं जो अन्य टीमों द्वारा अलगाव में काम किए जाते हैं, जहां सभी मॉड्यूल एक-दूसरे के बीच गहरी निर्भरता रखते हैं। किसी को नहीं पता कि परियोजना के पैमाने, और जटिलता को देखते हुए सभी उप-परियोजनाओं का उपयोग किस लिए किया जाता है।

इस स्थिति में, क्या आप प्रभावित घटक की निर्भरता में से प्रत्येक के लिए डीएजी के एक दृश्य प्रतिनिधित्व को उत्पन्न करने की कोशिश करेंगे, और यह निर्धारित करने का प्रयास करेंगे कि रन-टाइम में कहां टक्कर हो सकती है? अन्य उप-परियोजनाओं में निर्भरता कैसे प्रबंधित की जाती है, इस पर मेरा कोई नियंत्रण नहीं है, और अन्य डेवलपर्स द्वारा लिखे गए किसी भी जावा कोड को नहीं बदल सकते

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


अन्य अनुरोधों पर , मैं इस जानकारी को शामिल करने जा रहा हूं कि किस तकनीक का उपयोग किया जा रहा है, बहुत अधिक जानकारी प्रदान करने के लिए प्रश्न बंद होने के जोखिम पर, या शरीर बहुत लंबा हो रहा है:

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

सामान्य तौर पर, मैं किसी दिए गए प्रोजेक्ट की निर्भरता के सभी संभावित संयोजनों के माध्यम से गणना किए बिना निर्भरता संघर्षों को हल करने के तरीकों की पहचान करने के लिए एक भाषा-अज्ञेयवादी दृष्टिकोण की तलाश कर रहा हूं

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


क्या आप डीआई कंटेनर की तरह कुछ के बारे में बात कर रहे हैं, यह जानने के लिए ठीक से सेटअप नहीं है कि क्या IFooImpl का उपयोग करता है?
एंडी

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

2
चलो, "निर्भरता मुद्दा" एक बहुत ही सामान्य शब्द है, और हर कोई जो इसे पढ़ता है वह संभवतः कुछ अलग करता है। वास्तविक दुनिया के लिए यह प्रौद्योगिकी पर निर्भर है, इसलिए कृपया एक विशिष्ट तकनीक के लिए एक वास्तविक उदाहरण दें जो आपके मन में हो। क्या समस्याएँ उत्पन्न हो रही हैं क्योंकि उन्हें आवश्यक घटक गायब हैं? या क्योंकि एक गलत संस्करण प्रदान किया गया है? किस प्रकार की निर्भरता संकल्प तंत्र पहले से ही है? कृपया स्पष्ट करें।
डॉक्टर ब्राउन

1
.Net दुनिया में मैं इस समस्या को हल करता हूं बस अपने मुख्य एप्लिकेशन प्रोजेक्ट में पैकेज स्थापित कर रहा हूं। हालांकि कोई भी एप्लिकेशन कोड वास्तव में प्लगइन पुस्तकालयों का उपयोग नहीं करता है। नेट कंपाइलर सुनिश्चित करता है कि DLL बिल्ड के दौरान सही स्थान पर है और इस प्रकार तैनाती है।
एंडी

2
"इस बात पर मेरा कोई नियंत्रण नहीं है कि निर्भरता कैसे प्रबंधित की जाती है, और कोई भी कोड नहीं बदल सकता है" - वास्तव में आप क्या बदल सकते हैं? यदि आप कुछ भी नहीं बदल सकते हैं, तो प्रश्न व्यर्थ लगता है।
डॉक ब्राउन

जवाबों:


6

यह संभव हो सकता है कि आपकी समस्या को हल करने के लिए कस्टम क्लास लोडर का उपयोग करके प्रत्येक मॉड्यूल को अपने स्वयं के निष्पादन वातावरण में दिया जाए।

मूल रूप से, आप एक मुख्य वातावरण को परिभाषित करेंगे जिसमें अनुप्रयोग का एक छोटा कर्नेल होता है, साथ ही जो कुछ निर्भरता सार्वभौमिक रूप से सहमत हैं और सभी इंटरफेस जो मॉड्यूल के लिए एक दूसरे के साथ संवाद करने के लिए आवश्यक हैं। फिर, आपके द्वारा लोड किए गए प्रत्येक मॉड्यूल को अपना स्वयं का क्लास लोडर मिलता है जो रनटाइम वातावरण से (1) वर्गों, एप्लिकेशन कोर से (2) वर्गों और उस मॉड्यूल और इसकी प्रत्यक्ष निर्भरता से (3) वर्गों तक पहुंच सकता है। सभी अंतर-मॉड्यूल संचार कोर में परिभाषित इंटरफेस के माध्यम से जाते हैं ताकि कोई भी मॉड्यूल सीधे दूसरे पर निर्भर न हो।

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


1
मुझे निर्भरता समस्या को हल करने के लिए परियोजना को फिर से आर्किटेक्ट करने की अनुमति नहीं है। हालांकि, एक माइक्रोकर्नेल जैसी वास्तुकला में स्विच करना एक तरह से अच्छा होगा।
टायलर

2
@ टायलर: फिर भी मुझे लगता है कि यह सवाल के सामान्य हिस्से का एक अच्छा, सामान्य जवाब है।
डॉक्टर ब्राउन

1
यह थोड़ा आसन जैसा लगता है।
स्पेसटुकर

4

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

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

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

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

उदाहरण के लिए, यदि आपका सिस्टम एक वेब शॉप है, और "न्यूज़लेटर सदस्यता" के लिए आपका सबमॉडल कुछ घंटों के लिए लोड नहीं किया जा सकता है, तो यह कुछ ऐसा है जिसे आसानी से सहन किया जा सकता है जैसे कि पूरी दुकान किसी भी काम नहीं करती है।

अंत में, यह आपके मामले में एक विकल्प नहीं हो सकता है, लेकिन अगर घटकों को एक-दूसरे के खिलाफ बेहतर अलगाव में चलाया जा सकता है, और अगर यह निर्भरता टकराव से बच सकता है, तो इसके बारे में सोचने लायक एक दृष्टिकोण हो सकता है।


2

यहाँ मुझे जोर से सोचने पर विचार करें। आवश्यकताओं / समय की कमी के आधार पर मैं इस पर विचार कर सकता हूं:

1) इंटरफेस और उनके कार्यान्वयन की एक सूची बनाएं (प्रतिबिंब का उपयोग करते हुए, यदि उपलब्ध हो)

2) अपने DI के चारों ओर एक प्रकार का आवरण बनाएं। जब DI को ठोस कार्यान्वयन प्रदान करने के लिए कहा जाता है, तो देखें कि क्या पहले से ही DI नियम है; यदि नियम मौजूद है - बस वही वापस करें जो आपका DI प्रदान करता है; अन्यथा अगर एक इंटरफ़ेस का एक ही कार्यान्वयन है और आप एक उदाहरण बनाने में सक्षम हैं - लॉग करें, और एक उदाहरण वापस करें; अन्यथा लॉग इन करें और विफल।

इस बात पर निर्भर करता है कि आप कितना प्राप्त करना चाहते हैं, मुझे लगता है, लेकिन अंत में आप बस एक पूरी सूची रखना चाहते हैं कि किस चीज की आवश्यकता है - यह समाधान अंततः उस सूची को उत्पन्न करेगा।

हालाँकि, यकीनन यह बहुत काम की चीज है और विश्वसनीय नहीं है - क्या होगा अगर आपके पास एक नीली चाँद में एक बार कुछ निर्भरता की आवश्यकता होती है?

जब आप कहते हैं कि "अपस्ट्रीम घटकों में परिवर्तन" का क्या मतलब है?


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

2

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

मैं अनुमान लगा रहा हूं जब आप अपने सहयोगियों से पूछते हैं कि 'मुझे यह काम करने के लिए कैसे मिलता है?', तो वे कहते हैं 'जाहिर है कि आपको 35 मॉड्यूल और संस्करणों की इस सूची की आवश्यकता है , आप यह कैसे नहीं जान सकते?'

संभवतः जब एकीकरण परीक्षण किया जाता है, तो आवश्यक मॉड्यूल को परीक्षण निर्भरता के रूप में घोषित किया जाता है। इसलिए व्यवस्थित समाधान यह सुनिश्चित करने के लिए एकीकरण परीक्षण पोम के निरीक्षणों को स्थापित करना है कि उनके पास कुछ भी नहीं है, लेकिन तृतीय-पक्ष परीक्षण उपकरण निर्भरता के रूप में घोषित किए गए हैं। यह भी maven enforcer प्लगइन द्वारा स्वचालित किया जा सकता है ।

जाहिरा तौर पर आप ऐसा नहीं कर सकते, इसलिए आपका सबसे अच्छा विकल्प यहां पाया जाता है


वास्तव में वही हो रहा है, जो मैं बता सकता हूं। अब तक मैं 30 आश्रितों का मजाक उड़ा रहा हूं, और टक्करों को खत्म करने के लिए स्कूप्स को ट्विडलिंग कर रहा हूं, लेकिन, सहकर्मी की समीक्षा यहां आवश्यक है।
टायलर
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.