एज़्योर सर्विस बस: एक गैर-क्लासिक अनुप्रयोग

बड़े ग्राहक-सर्वर अनुप्रयोगों के लिए मैसेजिंग सिस्टम के रूप में एज़्योर सर्विस बस

मैं आपको नमस्कार करता हूं, खब्रोविट्स!

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

आप कौन हैं और क्या कर रहे हैं?

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

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

पर्याप्त शब्द, चलो व्यापार के लिए नीचे उतरो!

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

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

इस तथ्य के बावजूद कि Microsoft के "स्वतंत्र इंजीलवादी" चेपल ने अपने लेख में इस तकनीक के केवल संकेतित अनुप्रयोग पर विचार किया है, अब Azure के इस हिस्से में एक काफी बड़ा और सुविधाजनक संदेश Broker-a कार्यक्षमता है। लेख के लेखन के बाद से, दो बदलाव हुए हैं: Microsoft ने कार्यक्षमता को जोड़ा है और इसकी मूल्य नीति में बदलाव किया है। थोड़ी देर बाद कार्यक्षमता के बारे में, और अब एक पल के लिए हम कीमतों में बदल जाते हैं। सामान्य तौर पर, सर्विस बस के लिए मूल्य निर्धारण नीति, जिसे शुरू में Microsoft द्वारा चलाया गया था, ने सर्विस बस के दायरे को बहुत सीमित कर दिया: बस के प्रत्येक कनेक्शन के लिए भुगतान किया गया था। दिसंबर में, मूल्य निर्धारण नीति को बदल दिया गया था, और अब हर लेनदेन का भुगतान सेवा बस में किया जाता है। कोई कनेक्शन शुल्क नहीं है, लेकिन उनकी संख्या सीमित है। संक्षेप में, सर्विस बस की कीमत अब Azure Storage के समान है। आप आधिकारिक वेबसाइट पर नई सेवा बस मूल्य निर्धारण के बारे में अधिक पढ़ सकते हैं ।

नतीजतन, सर्विस बस एप्लिकेशन रेंज में काफी विस्तार हुआ है। लेकिन इस तकनीक के संभावित अनुप्रयोगों का वर्णन करने से पहले, मैं आपको इसके उपकरण के बारे में बताऊंगा।

हुर्रे, चित्र!

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

सेवा बस की मुख्य विशेषताएं:

• सुरक्षित रूप से बाहरी WCF- आधारित वेब सेवाओं तक पहुँच खोलता है जो फ़ायरवॉल और NAT राउटर द्वारा बंद की जाती हैं, और ऐसा किसी भी आने वाले पोर्ट को खोलने या किसी तरह फ़ायरवॉल या राउटर को फिर से कॉन्फ़िगर करने के बिना करता है।
• फ़ायरवॉल के बाहर उपकरणों से सुरक्षित इनबाउंड कनेक्शन प्रदान करता है।
• एक एकल नाम स्थान प्रदान करता है जो भौगोलिक स्थिति से पूरी तरह से अलग है। इसका अर्थ है कि ऐसी जानकारी सेवा नाम में निहित नहीं है।
• नामस्थान में एंडपॉइंट को प्रकाशित करने और खोजने के लिए तंत्र प्रदान करता है।
• संदेशों को अग्रेषित करने की क्षमता प्रदान करता है। एक तरफ़ा संदेश, अनुरोध / प्रतिक्रिया संदेश और P2p इंटरैक्शन का समर्थन करता है।
• यह एक संदेश ब्रोकर के कार्यों को प्रदान करता है, विशेष रूप से, यह संदेशों के अतुल्यकालिक आदान-प्रदान को सक्षम करता है (संदेश के प्रेषक और रिसीवर को एक साथ ऑनलाइन नहीं होना पड़ता है)। बुनियादी ढांचे को इस तरह से डिज़ाइन किया गया है कि संदेश सुरक्षित रूप से संग्रहीत किए जाते हैं जब तक कि प्राप्तकर्ता उन्हें प्राप्त करने के लिए तैयार न हो।
• सेवाओं के एंडपॉइंट्स बनाता और बनाए रखता है, दो अंत बिंदुओं के बीच सुरंग बनाने की भी अनुमति देता है, जिससे द्विदिश डेटा ट्रांसफर की अनुमति मिलती है।

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



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



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



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

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

सुरक्षा के बारे में क्या?

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

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

अंत में

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

कम-विलंबता / उच्च थ्रूपुट / इन-रैम:

• NoSQL storages / caches प्रकाशित / सदस्यता कार्यक्षमता के साथ - उदाहरण के लिए, रेडिस (हाँ, यूनिक्स रिपॉजिटरी एज़्योर में रहता है, हालांकि स्केलिंग के साथ अभी भी समस्याएं हैं)
• कॉम्प्लेक्स इवेंट प्रोसेसिंग पैटर्न का कार्यान्वयन - उदाहरण के लिए, माइक्रोसॉफ्ट का स्ट्रीमआईनाइट , जो न केवल डेटा स्थानांतरित कर सकता है, बल्कि वास्तविक समय में विस्तृत सिग्नल प्रोसेसिंग भी कर सकता है। (और हाँ, यह जल्द ही एज़्योर में भी आ जाएगा)
• ZeroMQ और अन्य मैसेजिंग कतार सिस्टम

गारंटी वितरण / निरर्थक:

• MSMQ
• एंटरप्राइज़ सर्विस बस पैटर्न के सभी प्रकार के कार्यान्वयन (माना azure को छोड़कर), "भेजें-भूलो, खो न जाओ" के सिद्धांत पर काम करना

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