Microservices: विदेशी प्रमुख संबंधों को कैसे संभालना है

Question

माइक्रोसर्विस आर्किटेक्चर का सुझाव है कि प्रत्येक सेवा को अपने स्वयं के डेटा को संभालना चाहिए। इसलिए अन्य सेवा (सेवा बी) के स्वामित्व वाले डेटा पर निर्भर किसी भी सेवा (सेवा ए) को सीधे डीबी कॉल करके नहीं बल्कि दूसरी सेवा (सेवा बी) द्वारा प्रदान की गई एपीआई के माध्यम से ऐसे डेटा का उपयोग करना चाहिए।

तो विदेशी प्रमुख बाधाओं की जाँच करने के लिए माइक्रोसिस्टर्स सर्वोत्तम प्रथाओं का क्या सुझाव देता है।

उदाहरण: मैं उत्पादों के लिए एक डिलीवरी सुविधा (माइक्रोसर्विस 1) विकसित कर रहा हूं और कुछ उत्पादों को केवल कुछ स्थानों तक ही पहुंचाया जा सकता है, जो कि केवल उत्पाद माइक्रो सेवा (mircoservice 2) के लिए सुलभ उत्पाद तालिका में उल्लिखित हैं।

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

Answer 1

कई माइक्रोसॉर्क्स के लिए साझा डेटाबेस का उपयोग करना संभव है। आप इस लिंक में microservices के डेटा प्रबंधन के लिए पैटर्न पा सकते हैं: http://microservices.io/patterns/data/database-per-service.html । वैसे, यह माइक्रोसर्विस आर्किटेक्चर के लिए बहुत उपयोगी ब्लॉग है।

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

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

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

Comments

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

— ट्रान्सहोलिक

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

— अली सहलाम

बहुत बढ़िया जवाब!

— टीएस

लेकिन, क्या आप विदेशी कुंजी रखते हैं? Ex: हर ब्लॉग पोस्ट में कई टिप्पणियां होंगी। मोनोलिथ में ब्लॉग पोस्ट के लिए विदेशी कुंजी के साथ टिप्पणी तालिका होगी। हालाँकि, माइक्रोसैस सर्विस में, हमारी दो सेवाएँ होंगी। सेवा 1: इन टेबल फ़ील्ड्स (पोस्टआईडी, नाम, सामग्री) के साथ माइक्रोस्वेरी पोस्ट करें सेवा 2: इन टेबल फ़ील्ड्स (टिप्पणी, पोस्टआईडी, Cpmment) के साथ माइक्रोस्वेरी का सवाल है, क्या हमें सेवा 2 (टिप्पणियाँ माइक्रोसॉर्स्ट) में "पोस्टआईडी" की आवश्यकता है? मुझे लगता है कि उत्तर हां है, क्योंकि हमें यह जानना होगा कि कौन सी टिप्पणी किस पद से संबंधित है। क्या मेरी समझ सही है?

— राकेश मेहरा

सिस्टम को माइक्रोसर्विस में कैसे विभाजित किया जाए यह पूरी तरह से एक अलग कहानी है, लेकिन अगर आपने पोस्ट की तरह 2 माइक्रोसर्विस बनाने का फैसला किया है और टिप्पणी के लिए आपको टिप्पणी पहचानकर्ता पर पोस्ट पहचानकर्ता की आवश्यकता है क्योंकि प्रत्येक टिप्पणी एक पोस्ट की है। हालांकि, इसका मतलब यह नहीं है कि आपको उन तालिकाओं के बीच एफके को परिभाषित करने की आवश्यकता है। FK RDBMS दुनिया में केवल एक बाधा है जो डेटा अखंडता और स्थिरता सुनिश्चित करने में मदद करता है। यदि आप अलग-अलग स्कीमाओं पर इन माइक्रो-सर्विस का डेटा रखते हैं, तो आप FK को परिभाषित नहीं कर सकते हैं या यहां तक ​​कि आप किसी के डेटा को nosql db (जो कि टिप्पणी microservice के लिए कोई मतलब होगा) पर रख सकते हैं जहां FK लागू नहीं है।

— अली सआलम

Answer 2

कम युग्मन प्राप्त करने के लिए अपने कोड को वितरित करते समय, आप संसाधन साझाकरण से बचना चाहते हैं, और डेटा एक संसाधन है जिसे आप साझा करने से बचना चाहते हैं।

एक और बिंदु यह है कि आपके सिस्टम में केवल एक घटक डेटा का मालिक है (राज्य बदलते हुए संचालन के लिए), अन्य घटक READ लेकिन NOT WRITE हो सकते हैं, उनके पास डेटा की प्रतियां हो सकती हैं या आप एक दृश्य मॉडल साझा कर सकते हैं जिसका उपयोग वे नवीनतम स्थिति प्राप्त करने के लिए कर सकते हैं किसी वस्तु का।

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

अधिक विवरण के लिए एनडीसी ओस्लो में उदी दहन की बात पर एक नज़र डालें

उम्मीद है की यह मदद करेगा

Comments

उदी दहन की बातचीत का लिंक बहुत दिलचस्प है

— कॉमेंकाऊ

Answer 3

पहला समाधान: एपीआई संरचना

 Implement a query by defining an API Composer, which invoking the
 services that own the data and performs an in-memory join of the
 results

दूसरा समाधान: CQRS

Define a view database, which is a read-only replica that is designed to support that 
query. The application keeps the replica up to data by subscribing to Domain events 
published by the service that own the data.

Answer 4

इस उत्तर के लिए एक 2020 अद्यतन डेबीज़ियम जैसे चेंज डेटा कैप्चर टूल का उपयोग करना है। डेबेज़ियम परिवर्तनों के लिए आपके डेटाबेस तालिकाओं की निगरानी करेगा और उन्हें काफ्का / पल्सर (अन्य पाइप) पर स्ट्रीम करेगा और आपके ग्राहक फिर परिवर्तनों को पकड़ सकते हैं और उन्हें सिंक्रनाइज़ कर सकते हैं।