कई-से-कई संघों में माइक्रोसर्विसेस

Question

वर्तमान में मेरे पास दो माइक्रोसर्विसेज हैं। हम उन्हें फोन करता हूँ Aऔर B।

Microservice के तहत डेटाबेस Aमें निम्नलिखित तालिका है:

A
|-- users

Microservice के तहत डेटाबेस Bमें निम्नलिखित तालिका है:

B
|-- trackers

आवश्यकताएं बताई गई हैं usersऔर trackersजिनके कई-कई संबंध हैं।

मुझे यकीन नहीं है कि यह कैसे एक microservices वास्तुकला के भीतर ठीक से संभाल करने के लिए है।

मैं इस काम को तीन तरीकों से देख सकता था:

1. एक user_trackersतालिका को माइक्रोसर्विस में जोड़ा जाता है A। यह "विदेशी कुंजियों" से युक्त एक सम्मिलित तालिका के समान है usersऔर trackers।
2. एक ownersतालिका को माइक्रोसर्विस में जोड़ा जाता है B। यह तालिका एक पॉलीमॉर्फिक जॉइन टेबल के समान कार्य करती है। यह किसी भी सेवा को ट्रैकर के साथ जुड़ाव बनाने की अनुमति देगा। यह कुछ इस तरह लग सकता है: B |-- trackers |-- owners |-- owner_id |-- owner_type |-- tracker_id
3. के लिए रिकॉर्ड रखें usersऔर trackersप्रत्येक microservice में। उन्हें किसी प्रकार के पबसूब सिस्टम के साथ सिंक में रखें।

मैं मूल रूप से विकल्प 2 के साथ जाने वाला था क्योंकि मुझे पसंद था कि यह लेनदेन सीमाओं को संरक्षित रखे। मैं एक ट्रैकर बना सकता हूं और इसे परमाणु रूप से कुछ के साथ जोड़ सकता हूं। हालांकि, यह माइक्रोसॉर्स्क के लिए गुंजाइश से बाहर लगता है B। माइक्रोसर्विस को इस बात की Bपरवाह क्यों करनी चाहिए कि माइक्रोसॉर्फ़ Aएसोसिएशन बनाना चाहता है?

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

Answer 1

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

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

दूसरी बात यह है कि आपने शायद अपने डोमेन के माध्यम से पर्याप्त रूप से काम नहीं किया है। usersतालिका के साथ किस अवधारणा का प्रतिनिधित्व किया जाता है? क्या यह registered userपंजीकरण के लिए आवश्यक सभी जानकारी और व्यवहार के साथ है? क्या आप सुनिश्चित हैं कि यह trackers(जो भी है) के साथ संवाद करने के लिए सही अवधारणा है? इसलिए अगर मुझे यह सही लगा, तो आपका विकल्प 2 बिल्कुल उसी के बारे में है: उस ownerअवधारणा को पेश करना जो आपके डोमेन के बहुत करीब है। यदि यह वास्तव में ऐसा है, तो मैं विकल्प 2 के लिए भी हूँ।

हालांकि, यह माइक्रोसॉर्स्ट बी के लिए गुंजाइश से बाहर लगता है। माइक्रोसेवेर्स बी को इस बात का ध्यान क्यों रखना चाहिए कि माइक्रोसॉर्स ए एसोसिएशन बनाना चाहता है?

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

जब उपयोगकर्ता पंजीकृत हो जाता है, तो UserCreatedईवेंट को उत्सर्जित किया जा सकता है। मुझे लगता है कि आपकी दूसरी सेवा इसमें रुचि रखती है। इसलिए इसे प्राप्त करने पर एक पूरी तरह से अलग इकाई बनाई जा सकती है, कहते हैं, Ownerइकाई (जो भी है, या तो)। मुझे पूरा यकीन है कि इसके और trackerइकाई के बीच बहुत सारे दिलचस्प सहयोग हैं - उन्हें एक ही सेवा में रखें।

3. विकल्प के साथ अत्यंत सतर्क रहें। यदि आप डेटा की प्रतिलिपि बनाते हैं, तो कार्यक्षमता इस प्रकार है। इसके परिणामस्वरूप तंग युग्मन होता है। और CQRS शब्द के साथ कवर नहीं है , यह घटनाओं के माध्यम से सेवाओं के बीच डेटा सिंक्रनाइज़ेशन के बारे में नहीं है।

Comments

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

— जिमीजैम 18

मैंने हमेशा "वितरित मोनोलिथ" श्रेणी में चैट सेवाओं को शामिल किया है, जो व्यापक रूप से, सामान्य तरीके से नहीं फैला है।

— वादिम समोखिन

Answer 2

Zapadlo के उत्तर में बहुत सारी अच्छी जानकारी और तर्क हैं। मैं यहां थोड़ी व्यावहारिक सलाह देने जा रहा हूं जिससे आपके मुद्दों और उस उत्तर में सलाह के माध्यम से काम करना आसान हो जाए।

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

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

इससे पहले कि कोई भी यह निर्धारित कर सके कि यह डेटाबेस में कैसा दिखता है या आप यह कहाँ चाहते हैं, आपको वास्तव में यह समझाने की आवश्यकता है कि इस जानकारी का उपयोग कैसे किया जा रहा है। क्या यह कुछ ऐसा है जिसे किसी सेवा के माध्यम से उजागर किया जाएगा या यह कुछ प्रकार का डेटा है जिसे आप एनालिटिक्स के लिए फेरबदल करना चाहते हैं?

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

Answer 3

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

Answer 4

प्रश्न: डेटाटैबल्स के साथ आपका डेटा अलग क्यों किया गया है?

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

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

Comments

यह माइक्रोसर्विस के धर्म का हिस्सा है, कि प्रत्येक सेवा को पूर्ण स्वायत्तता की आवश्यकता है। थॉमस एर्ल इसे "प्रिंसेस ऑफ़ सर्विस डिज़ाइन" c में सेवा अभिविन्यास के सिद्धांतों में से एक के रूप में वर्णित करते हैं । 2008.

— जिमीजैम 15

@JimmyJames एक ऐसे व्यक्ति के रूप में जो खुद एमएस-आर्किटेक्चर लिखता है: इस सवाल पर बहुत बहस होती है कि एमएस कितना बड़ा होना चाहिए। इस स्थिति में, आकार भी मायने नहीं रख सकता क्योंकि सेवा (एस) को सही तरीके से अलग नहीं किया जा सकता है - जैसे कि व्यापार के डोमेन के साथ तालिकाओं में कटौती नहीं की जाती है।

— क्रिश्चियन सॉयर

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

— जिमीजैम

@JimmyJames मुझे लगता है कि यह तकनीक के बारे में भी हो सकता है, खासकर जब सर्टिफिकेशन तकनीकें कुछ डोमेन के लिए अच्छी तरह से अनुकूल हों, लेकिन दूसरों के लिए नहीं। हम अपने MS के लिए C # और Python का उपयोग करते हैं। उस में से कुछ संगठनात्मक समस्याओं के कारण है ("मैंने 20 साल के लिए सी # प्रोग्राम किया है, मुझे नई अपरिचित भाषाओं को सीखने की आवश्यकता नहीं है!")। - लेकिन हमारी प्रणाली की प्रकृति के कारण भी। अजगर में डेटा विज्ञान के अंग सबसे अच्छे हैं, जबकि कुछ बुनियादी ढांचे और वेब कार्यों को सी # में सबसे अच्छा किया जाता है।

— क्रिश्चियन सॉयर

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

— जिमीजैम