डाउनस्ट्रीम और अपस्ट्रीम सेवाएं किस तरह की हैं?


45

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


3
दिलचस्प बात यह है कि HTTP विनिर्देश RFC 7230 धारा 2.3 में "अपस्ट्रीम" और "डाउनस्ट्रीम" शब्दों की परिभाषाओं को शामिल करने के लिए होता है: tools.ietf.org/html/rfc7230#section-2.3
जैक

जवाबों:


56

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

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


मुझे लगता है कि "सेवाओं के डाउनस्ट्रीम" के स्थान पर " डाउनस्ट्रीम सर्विसेज" होना चाहिए ।
नवाज

8

दुर्भाग्य से अपस्ट्रीम / डाउनस्ट्रीम के अर्थ पर मतभेद हैं। सिस्टम आर्किटेक्चर के बारे में बात करते समय, मैं इसे निम्नानुसार परिभाषित करता हूं:

चिंता की एक प्रणाली को देखते हुए, सिस्टम जो चिंता की प्रणाली के लिए संदेश / डेटा विनिमय शुरू करते हैं, अपस्ट्रीम सिस्टम हैं, और सिस्टम जो चिंता का विषय है (यानी जिन लोगों को मेरा सिस्टम डेटा एक्सचेंज शुरू करता है) डाउनस्ट्रीम सिस्टम हैं।

उनके उत्पादों में से एक के साथ बातचीत का वर्णन करने वाले ibm का यह लिंक इस दृश्य को पुष्टि करता है: अपस्ट्रीम और डाउनस्ट्रीम सिस्टम के साथ एकीकरण https://www.ibm.com/support/knowledgecenter/en/SSWSR9_11.3.0/com.ibm.pim.dev.doc /integration/pim_con_dev_creatingjobsforintegrationcontainer.html

अपस्ट्रीम सिस्टम कोई भी सिस्टम है जो डेटा को सर्वर सर्वर सिस्टम पर भेजता है। डाउनस्ट्रीम सिस्टम एक ऐसी प्रणाली है जो सहयोग सर्वर सिस्टम से डेटा प्राप्त करता है।

शब्दावली 'अपस्ट्रीम' और 'डाउनस्ट्रीम' को देखते हुए नदी के साथ एक सादृश्य बनाने में मदद मिल सकती है। यदि आप नदी में एक संदेश (डेटा) छोड़ते हैं तो यह नदी के ऊपर (सर्जक) से नीचे की ओर (रिसीवर) में बहती है।

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

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

जैसा कि @Jack नोट RFC7230 tools.ietf.org/html/rfc7230#section-2.3 है:

"अपस्ट्रीम" और "डाउनस्ट्रीम" शब्द का उपयोग
संदेश प्रवाह के संबंध में दिशात्मक आवश्यकताओं का वर्णन करने के लिए किया जाता है : सभी
संदेश ऊपर से नीचे की ओर प्रवाहित होते हैं

मुझे वोटों को देखने में दिलचस्पी होगी, जो सबसे आम उपयोग है!


1
यह सिर्फ भ्रमित करने वाला है क्योंकि आप इस मामले पर खुद भ्रमित हैं। कोई विसंगति नहीं है, बस दृष्टिकोण में अंतर है।
मार्टिन मेट

@MartinMaat मैं आपके पहले वाक्य से असहमत हूं, और आपके दूसरे से सहमत हूं।
रोज

3

इसके बारे में सोचने का सबसे अच्छा तरीका एक नदी है।

नदी के कैंट नदी के बहाव वाले हिस्से को तब तक कोई पानी नहीं मिलता जब तक कि वह नदी के ऊपर से न आ जाए यानी नीचे की तरफ उसके पानी के लिए अपस्ट्रीम पर निर्भर है।

यदि कोई नदी के बहाव वाले हिस्से को नष्ट कर देता है, तो इसका कोई प्रभाव नहीं पड़ेगा। अगर किसी ने नदी के ऊपर के हिस्से को नष्ट कर दिया, तो यह बहाव को प्रभावित करेगा अर्थात इसे कोई पानी नहीं मिलेगा।

इसलिए डाउनस्ट्रीम सेवाएं अपस्ट्रीम सेवाओं पर निर्भर करती हैं। यदि अपस्ट्रीम सेवाएं हटा दी जाती हैं, तो डाउनस्ट्रीम सेवाएं ठीक से काम नहीं करती हैं।


और स्पष्टता के अतिरिक्त बिट के लिए; एक मानक CRUD क्लाइंट-सर्वर रिलेशनशिप में, दोनों छोर एक दूसरे के ऊपर और नीचे दोनों तरफ होते हैं। यदि सर्वर डाउन है, तो क्लाइंट को कोई डेटा या अपडेट नहीं मिल सकता है और अगर क्लाइंट नहीं है, तो सर्वर को निष्पादित करने के लिए कोई निर्देश नहीं है।
16

1
@ डेलियथ असहमत। बैकएंड में कई क्लाइंट हो सकते हैं, लेकिन उनमें से किसी एक पर निर्भर नहीं है। यदि आपने एक ग्राहक को हटा दिया है, तो बैकएंड अभी भी काम करेगा। ग्राहक कई बैकएंड का उपयोग कर सकता है। यदि एक बैकएंड क्लाइंट को जाने बिना हटा दिया जाता है, तो क्लाइंट ठीक से काम नहीं कर सकता है। ग्राहक नीचे की ओर है। बैकेंड अपस्ट्रीम है।
गज़_एज

1

यह तकनीकी की तुलना में अधिक भाषाई और भौगोलिक समस्या हो सकती है।

  • जानकारी के लिए अनुरोध ऊपर की ओर जाता है। यह एक डाउनस्ट्रीम सिस्टम से आता है।

  • सूचना के लिए अनुरोध की प्रतिक्रिया (अनुरोधित जानकारी) नीचे की ओर जाती है और एक अपस्ट्रीम सिस्टम द्वारा भेजी जाती है।

क्लासिक आईबीएम के विचार और आज के वेब समुदाय की शर्तों के उपयोग के बीच कोई अंतर नहीं है।

  • एक सेवा प्रदाता (सर्वर) एक सेवा उपभोक्ता की तुलना में ऊपर की ओर स्थित होगा और उपभोक्ता को नीचे की ओर सूचना भेजता है।

  • एक सेवा उपभोक्ता (क्लाइंट) सेवा प्रदाता की तुलना में नीचे की ओर स्थित होगा और प्रदाता को अनुरोध भेज देगा

भौतिक प्रणालियों की सैद्धांतिक भूमिकाएं तुरंत बदल सकती हैं और इसलिए उन प्रणालियों के बीच धारा की दिशा होगी। एक सहकर्मी से सहकर्मी नेटवर्क में यह मामला हो सकता है।

अपलोड करने और डाउनलोड करने की शर्तें क्लाइंट केंद्रित शब्द हैं। ग्राहक के दृष्टिकोण से एक अनुरोध अपलोड किया जाता है और एक प्रतिक्रिया डाउनलोड की जाती है, जो स्ट्रीम रूपक के अनुरूप होती है।

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