उपलब्धता में सुधार के लिए अतुल्यकालिक संदेश का उपयोग करना

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

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

निम्नलिखित अतुल्यकालिक संदेश का उपयोग करते हुए पुस्तक का एक अंश है

उपलब्धता में सुधार के लिए अतुल्यकालिक संदेश का उपयोग करना

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

सबसे पहले, आइए देखें कि समकालिक बातचीत क्या समस्याएं पैदा करती है और यह एक्सेसिबिलिटी को कैसे प्रभावित करती है।

3.4.1। सिंक्रनाइज़ इंटरेक्शन उपलब्धता को कम करता है

REST एक अत्यंत लोकप्रिय IPC इंजन है। आपको इसे चौराहे के संचार के लिए उपयोग करने के लिए लुभाया जा सकता है। लेकिन REST के साथ समस्या यह है कि यह एक सिंक्रोनस प्रोटोकॉल है: HTTP क्लाइंट को तब तक इंतजार करना पड़ता है जब तक सेवा प्रतिक्रिया नहीं देती। हर बार जब सेवाएं एक दूसरे के साथ एक तुल्यकालिक प्रोटोकॉल के माध्यम से संवाद करती हैं, तो इससे एप्लिकेशन की उपलब्धता कम हो जाती है।

ऐसा क्यों होता है यह समझने के लिए, अंजीर में दिखाए गए परिदृश्य पर विचार करें। 3.15। ऑर्डर बनाने के लिए ऑर्डर सेवा में REST API है। आदेश की जांच करने के लिए, वह उपभोक्ता और रेस्तरां सेवाओं की ओर रुख करता है, जिसमें REST API भी है।


एक आदेश बनाना चरणों के इस क्रम में शामिल है।

1. क्लाइंट HTTP POST / ऑर्डर सेवा के लिए अनुरोध करता है।
2. ऑर्डर सेवा ग्राहक को HTTP GET / उपभोक्ताओं / आईडी के लिए ग्राहक सेवा के लिए अनुरोध करके ग्राहक जानकारी प्राप्त करता है।
3. ऑर्डर सेवा रेस्तरां सेवा के लिए HTTP GET / रेस्तरां / आईडी अनुरोध निष्पादित करके रेस्तरां की जानकारी प्राप्त करती है।
4. ऑर्डर लेना ग्राहक और रेस्तरां के बारे में जानकारी का उपयोग करके अनुरोध की जांच करता है।
5. ऑर्डर लेना ऑर्डर बनाता है।
6. ऑर्डर लेना ग्राहक को एक HTTP प्रतिक्रिया भेजता है।

चूंकि ये सेवाएं HTTP का उपयोग करती हैं, इसलिए इन सभी को CreateOrder अनुरोध को संसाधित करने के लिए FTGO के लिए सुलभ होना चाहिए। यह कम से कम सेवाओं में से एक अनुपलब्ध होने पर एक आदेश बनाने में सक्षम नहीं होगा। गणितीय दृष्टिकोण से, सिस्टम ऑपरेशन की उपलब्धता सेवाओं की उपलब्धता का एक उत्पाद है जो इसमें शामिल हैं। यदि ऑर्डर सेवा और कॉल करने वाली दो सेवाओं की उपलब्धता 99.5% है, तो उनकी कुल उपलब्धता 99.5% 3 = 98.5% होगी, जो बहुत कम है। अनुरोध में भाग लेने वाली प्रत्येक बाद की सेवा ऑपरेशन को कम सुलभ बनाती है।

यह समस्या REST- आधारित इंटरैक्शन के लिए अद्वितीय नहीं है। जब भी किसी ग्राहक को जवाब देने के लिए किसी सेवा को अन्य सेवाओं से प्रतिक्रिया प्राप्त करने की आवश्यकता होती है तो उपलब्धता घट जाती है। यहां तक ​​कि अतुल्यकालिक संदेशों के शीर्ष पर एक अनुरोध / प्रतिक्रिया इंटरैक्शन शैली के लिए संक्रमण यहां मदद नहीं करेगा। उदाहरण के लिए, यदि ऑर्डर सेवा ब्रोकर के माध्यम से उपभोक्ता सेवा को संदेश भेजती है और प्रतिक्रिया के लिए इंतजार करना शुरू कर देती है, तो इसकी उपलब्धता बिगड़ जाएगी।

यदि आप पहुंच को अधिकतम करना चाहते हैं, तो सिंक्रोनस इंटरैक्शन की मात्रा कम से कम करें। आइए देखें कि यह कैसे करना है।

3.4.2। सिंक्रोनस इंटरैक्शन से छुटकारा पाएं

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

सौभाग्य से, तुल्यकालिक अनुरोधों को संसाधित करने के लिए, उन्हें स्वयं निष्पादित करना आवश्यक नहीं है। आइए ऐसे विकल्पों के बारे में बात करते हैं।

अतुल्यकालिक सहभागिता शैलियों का उपयोग करना

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


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

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

यदि सेवा में एक तुल्यकालिक एपीआई है, तो डेटा प्रतिकृति के माध्यम से पहुंच में सुधार किया जा सकता है। आइए देखें कि यह कैसे काम करता है।

डेटा प्रतिकृति

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


जब भी उनके डेटा में परिवर्तन होता है तो उपभोक्ता और रेस्तरां सेवाएं घटनाओं को प्रकाशित करती हैं। आदेश सेवा इन घटनाओं की सदस्यता लेती है और इसकी प्रतिकृति को अपडेट करती है।

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

इस समस्या को हल करने के लिए, एक सेवा अन्य सेवाओं के साथ बातचीत में देरी कर सकती है जब तक कि वह अपने ग्राहक को जवाब न दे। इस पर आगे चर्चा की जाएगी।

प्रतिक्रिया वापस करने के बाद प्रोसेसिंग समाप्त करें

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

1. सेवा स्थानीय रूप से उपलब्ध डेटा की मदद से केवल अनुरोध की जांच करती है।
2. यह अपने डेटाबेस को अपडेट करता है, जिसमें OUTBOX तालिका में संदेश शामिल करना शामिल है।
3. अपने ग्राहक की प्रतिक्रिया देता है।

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

कल्पना करें कि ऑर्डर सेवा इस तरह से कार्य करती है। वह PENDING की स्थिति के साथ एक आदेश बनाता है और फिर अन्य सेवाओं के साथ अतुल्यकालिक संदेशों का आदान-प्रदान करके इसकी जांच करता है। अंजीर में। चित्रा 3.18 दिखाता है कि क्या होता है जब createOrder () ऑपरेशन कहा जाता है। घटनाओं की श्रृंखला इस तरह दिखती है।

1. ऑर्डर सेवा PENDING की स्थिति के साथ एक आदेश बनाती है।
2. ऑर्डर सेवा अपने क्लाइंट को ऑर्डर आईडी के साथ प्रतिक्रिया देती है।
3. ऑर्डर सेवा उपभोक्ता सेवा को एक ValidateConsumerInfo संदेश भेजती है।
4. ऑर्डर सेवा रेस्तरां सेवा में एक ValidateOrderDetails संदेश भेजती है।
5. उपभोक्ता सेवा एक ValidateConsumerInfo संदेश प्राप्त करती है, यह देखने के लिए जांचती है कि क्या ग्राहक ऑर्डर दे सकता है, और ऑर्डर सेवा के लिए एक ConsumerValidated संदेश भेजता है।
6. रेस्तरां सेवा एक ValidateOrderDetails संदेश प्राप्त करती है, मेनू आइटमों की शुद्धता की जांच करती है और एक दिए गए पते पर ऑर्डर देने के लिए रेस्तरां की क्षमता, और ऑर्डर सेवा को एक ऑर्डरडेलीटेल संदेश भेजती है।
7. ऑर्डर सेवा ConsumerValidated और OrderDetailsValidated संदेश प्राप्त करती है और आदेश की स्थिति को मान्य में बदल देती है।

और इसी तरह…

ऑर्डर सेवा किसी भी क्रम में ConsumerValidated और OrderDetailsValidated संदेश प्राप्त कर सकती है। यह जानने के लिए कि उसे पहले कौन सा मिला था, उसने आदेश की स्थिति बदल दी। यदि पहला संदेश ConsumerValidated था, तो आदेश स्थिति CONSUMER_VALIDATED में बदल जाती है, और यदि आदेशDDAILails ORDER_DET Colors_VALIDATED में परिवर्तित हो जाता है। दूसरा संदेश प्राप्त करने के बाद, ऑर्डर सेवा मान्य स्थिति को निर्धारित करती है।

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


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

सारांश

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

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर पाई जा सकती है
» सामग्री
» अंश

Khabrozhiteley के लिए एक कूपन पर प्री-ऑर्डर किताबों पर 30% की छूट - माइक्रोसर्विस