माइक्रो सेवा संचार

Question

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

सबसे पहले, मैंने आरईएसटी स्टाइल सेवा की खोज की, लेकिन यदि प्रत्येक सेवा HTTP आरईएसटी आधारित है तो वे एक दूसरे के साथ "बात" कैसे करते हैं?

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

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

मैं जावा, स्प्रिंग टेक्नोलॉजीज का उपयोग कर रहा हूं।

मुझे खुशी होगी अगर कोई मुझे बेहतर तस्वीर देगा कि चीजें कैसे होनी चाहिए।

Answer 1

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

आपको शायद एक गेटवे की भी आवश्यकता है जो सही सेवा के अनुरोधों को पुनर्निर्देशित करता है। मेरा सुझाव है कि आप नेटफ्लिक्स क्लाउड स्टैक को आजमाएं:

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

यदि आप स्प्रिंग बूट का उपयोग कर रहे हैं तो आप कुछ एनोटेशन के साथ जल्दी से इस आर्किटेक्चर को सेट कर सकते हैं। https://cloud.spring.io/spring-cloud-netflix/

Answer 2

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

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

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

Answer 3

मैं व्यक्तिगत रूप से एक यूरेका खोजने की सेवा का इस्तेमाल किया है:

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

बहुत कम कॉन्फ़िगरेशन के साथ आप इस पूरे ढांचे को कार्य करने के लिए प्राप्त कर सकते हैं।

यह नेटफ्लिक्स द्वारा उपयोग किए गए ढांचे पर आधारित है। मेरा मानना ​​है कि यूरेका उस मामले के लिए नेटफ्लिक्स लाइब्रेरी भी है।

Answer 4

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

Answer 5

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

आप राज्य बदलते परिचालनों और पढ़ने के संचालन (सीक्यूएस कमांड क्वेरी सेपरेशन) के बीच स्पष्ट अंतर बनाना चाहते हैं। राज्य बदलते संचालन के लिए आप किसी प्रकार के संदेश बुनियादी ढांचे का उपयोग कर सकते हैं और आग के लिए जा सकते हैं और संचार भूल सकते हैं। प्रश्नों के लिए आप सिंक्रोनस अनुरोध प्रतिक्रिया संचार का उपयोग करेंगे और एक http API का उपयोग कर सकते हैं या सीधे अपने डेटा स्टोर पर जा सकते हैं।

यदि आप मैसेजिंग का उपयोग कर रहे हैं तो आप सेवाओं के बीच घटनाओं को बढ़ाने के लिए सब्सक्राइब प्रकाशित भी देख सकते हैं।

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

अंतिम लेकिन कम से कम नहीं, अपनी सेवाओं को स्वायत्त रखने के लिए आप जो कुछ भी कर सकते हैं, कम से कम तार्किक स्तर पर करने का प्रयास करें।

आशा है कि यह समझ में आता है।