सिक्योरिंग माइक्रोसर्विस डेटाबेस

10

एक मॉडल को नियंत्रित करने वाली सेवा A (CMS) को देखते हुए (उत्पाद, चलो मान लेते हैं कि यह आईडी, शीर्षक, मूल्य) और सेवाएं B (शिपिंग) और C (ईमेल) हैं, जिन्हें दिए गए मॉडल को प्रदर्शित करना है कि दृष्टिकोण क्या होना चाहिए इवेंट सोर्सिंग दृष्टिकोण में उन सेवाओं में दी गई मॉडल जानकारी को सिंक्रनाइज़ करने के लिए? चलो मान लेते हैं कि उत्पाद सूची शायद ही कभी बदलती है (लेकिन परिवर्तन होता है) और यह कि वहाँ प्रवेश हैं जो बहुत बार शिपमेंट और ईमेल के डेटा का उपयोग कर सकते हैं (उदाहरण के प्रकार हैं: बी: display titles of products the order containedऔर सी display content of email about shipping that is going to be sent:)। प्रत्येक सेवाओं का अपना डीबी है।

समाधान 1

घटना के भीतर उत्पाद के बारे में सभी आवश्यक जानकारी भेजें - इसका मतलब निम्नलिखित संरचना है order_placed:

{
    order_id: [guid],
    product: {
        id: [guid],
        title: 'Foo',
        price: 1000
    }
}

सेवा पर बी और सी उत्पाद जानकारी मेज productपर JSON विशेषता में संग्रहीत की जाती हैorders

जैसे, आवश्यक जानकारी प्रदर्शित करने के लिए केवल घटना से प्राप्त डेटा का उपयोग किया जाता है

समस्याएं : बी और सी में कौन सी अन्य जानकारी प्रस्तुत करने की आवश्यकता पर निर्भर करता है, घटना में डेटा की मात्रा बढ़ सकती है। B और C को उत्पाद के बारे में समान जानकारी की आवश्यकता नहीं हो सकती है, लेकिन ईवेंट में दोनों को समाहित करना होगा (जब तक कि हम ईवेंट को दो में अलग नहीं करते)। यदि दिया गया डेटा दिए गए ईवेंट के भीतर मौजूद नहीं है, तो कोड उसका उपयोग नहीं कर सकता है - यदि हम दिए गए उत्पाद में एक रंग विकल्प जोड़ेंगे , तो B और C में मौजूदा आदेशों के लिए, दिया गया उत्पाद तब तक बेरंग हो जाएगा जब तक कि हम घटनाओं को अपडेट नहीं करते हैं और फिर उन्हें फिर से चलाएँ। ।

समाधान २

घटना के भीतर उत्पाद का केवल गाइड भेजें - इसका मतलब निम्नलिखित संरचना है order_placed:

{
    order_id: [guid],
    product_id: [guid]
}

सेवाओं पर बी और सी उत्पाद जानकारी तालिका में product_idविशेषता में संग्रहीत की जाती हैorders

उत्पाद जानकारी को बी एंड सी द्वारा तब प्राप्त किया जाता है जब A/product/[guid]एंडपॉइंट के लिए एपीआई कॉल की आवश्यकता होती है

समस्याएं : यह B और C को A (हर समय) पर निर्भर करता है। यदि उत्पाद का स्कीमा A पर बदलता है, तो उन सभी सेवाओं पर परिवर्तन किए जाने चाहिए जो उन पर निर्भर हैं (अचानक)

समाधान 3

घटना के भीतर उत्पाद का केवल गाइड भेजें - इसका अर्थ है ऑर्डर के लिए निम्नलिखित संरचना:

{
    order_id: [guid],
    product_id: [guid]
}

सेवाओं पर बी और सी उत्पाद की जानकारी productsतालिका में संग्रहीत है ; अभी भी मेज product_idपर ordersहै, लेकिन productsए, बी और सी के बीच डेटा की प्रतिकृति है; B और C में A के मुकाबले उत्पाद के बारे में अलग-अलग जानकारी हो सकती है

जब बी और सी सेवाओं का निर्माण किया जाता है और A/productएंडपॉइंट (जो सभी उत्पादों की आवश्यक जानकारी प्रदर्शित करता है) या डायरेक्ट डी तक पहुंच प्राप्त करके और आवश्यक उत्पाद जानकारी की प्रतिलिपि बनाकर उत्पाद जानकारी के बारे में जानकारी बदल दी जाती है और जब भी आवश्यक हो, उसके लिए आवश्यक उत्पाद जानकारी की प्रतिलिपि बनाकर अद्यतन किया जाता है। सर्विस।

समस्याएं : यह B और C को A (जब बीजारोपण) पर निर्भर करता है। यदि उत्पाद का स्कीमा A पर बदलता है, तो उन सभी सेवाओं पर परिवर्तन किए जाने चाहिए जो उन पर निर्भर करती हैं (जब सीडिंग)

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

microservices event-sourcing

— eithed
स्रोत

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

— नहीं

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

— नोप

@ updating event historyमेरा मतलब नहीं है: सभी घटनाओं के माध्यम से जाना, उन्हें एक धारा (v1) से दूसरे स्ट्रीम (v2) में कॉपी करके लगातार घटना स्कीमा बनाए रखना है।

— eithed

एक तरफ, वाणिज्य / ई-कॉमर्स क्षेत्र में, आप मूल्य को कैप्चर करना चाहते हैं, जैसा कि कहा गया है कि मूल्य निर्धारण में अक्सर परिवर्तन होता है। उपयोगकर्ता द्वारा प्रदर्शित मूल्य उस समय भिन्न हो सकता है जिस समय वास्तविक ऑर्डर दिया गया है। समस्या को हल करने के कई तरीके हैं, लेकिन यह एक है जिस पर विचार किया जाना चाहिए।

— CPERS

@ कर्सन यूप - मूल्य एक विशेषता हो सकती है जो घटना के भीतर ही पास हो जाती है। दूसरी ओर, छवि के लिए URL घटना के भीतर मौजूद कर सकते हैं (के इरादे का प्रतिनिधित्व display image at the point when purchase was made) या नहीं (के इरादे का प्रतिनिधित्व कर सकते हैं display current image as it within catalog)

— eithed

3

समाधान # 3 वास्तव में सही विचार के करीब है।

इस बारे में सोचने का एक तरीका: बी और सी प्रत्येक कैशिंग "स्थानीय" डेटा की प्रतियां हैं जिनकी उन्हें आवश्यकता है। B पर संसाधित संदेश (और इसी तरह C) स्थानीय रूप से कैश्ड जानकारी का उपयोग करते हैं। इसी तरह, स्थानीय रूप से कैश्ड जानकारी का उपयोग करके रिपोर्ट तैयार की जाती हैं।

डेटा को एक स्थिर एपीआई के माध्यम से स्रोत से कैश में दोहराया जाता है। B और C को समान API का उपयोग करने की भी आवश्यकता नहीं है - वे अपनी जरूरतों के लिए जो भी प्रोटोकॉल लाते हैं, उसका उपयोग करते हैं। वास्तव में, हम एक अनुबंध - प्रोटोकॉल और संदेश स्कीमा को परिभाषित करते हैं - जो प्रदाता और उपभोक्ता को विवश करता है। फिर उस अनुबंध के लिए कोई भी उपभोक्ता किसी भी आपूर्तिकर्ता से जुड़ा हो सकता है। पिछड़े असंगत परिवर्तनों के लिए एक नए अनुबंध की आवश्यकता होती है।

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

यह आपको "स्वायत्तता" देता है, इस अर्थ में कि B और C व्यावसायिक मूल्य प्रदान करना जारी रख सकते हैं जब A अस्थायी रूप से अनुपलब्ध है।

अनुशंसित पढ़ने: बाहर पर डेटा, अंदर पर डेटा , पैट हेलैंड 2005।

— VoiceOfUnreason
स्रोत

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

— 12

1

मुझे लगता है कि आपको यह w / समाधान # 3 मिल गया है। यदि आपको कैटलॉग, इवेंट स्रोत के साथ भी पुनरावृत्ति की आवश्यकता है। जब आप फिर से शुरू करते हैं, तो आपको केवल पुनरावृत्ति करने की आवश्यकता होती है - शायद आप स्टार्टअप पर हैं - एक बार जब आप उठते हैं तो आपको केवल नई घटनाओं को देखने की आवश्यकता होती है, इसलिए डेटा की मात्रा शायद एक वास्तविक समस्या नहीं है। हालांकि, फिर भी आप विकल्प होता है (यदि आवश्यक हो) चौकियों का उपयोग कर, यानी "यहाँ है की राज्य , घटना 1000 की के रूप में" ताकि आप उस लेते हैं और अब आप केवल घटना 1,001 करने के लिए वर्तमान पूरे इतिहास के बजाय पुनः चलाने के लिए है ।

— माइक बी

2

कंप्यूटर विज्ञान में दो कठिन चीजें हैं , और उनमें से एक कैश अमान्य है।

समाधान 2 बिल्कुल मेरी डिफ़ॉल्ट स्थिति है, और आपको आमतौर पर केवल कैशिंग लागू करने पर विचार करना चाहिए यदि आप निम्नलिखित परिदृश्यों में से एक में भाग लेते हैं:

सेवा A में API कॉल प्रदर्शन समस्याओं का कारण बन रही है।
सेवा A की लागत कम होने और डेटा को पुनर्प्राप्त करने में असमर्थ होना व्यवसाय के लिए महत्वपूर्ण है।

प्रदर्शन की समस्याएं वास्तव में मुख्य चालक हैं। # 2 को हल करने के कई तरीके हैं जिसमें कैशिंग शामिल नहीं है, जैसे कि सेवा ए अत्यधिक उपलब्ध है।

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

से इस उत्कृष्ट लेख उदी दहन द्वारा:

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

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

— फिल सैंडलर
स्रोत

1

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

— फिल सैंडलर 16

1

@SavvasKleanthous भी विचार करें (जैसा कि मैंने अपने जवाब में उल्लेख किया है) कि कई मामलों में बासी डेटा वापस करना एक त्रुटि को फेंकने की तुलना में बहुत खराब हो सकता है ।

— फिल सैंडलर 16

1

@eeded मैं इस टिप्पणी का उल्लेख कर रहा था: "यदि, हालांकि, हम कैटलॉग में परिवर्तनों का ट्रैक रखना चाहते हैं, इसके लिए इवेंट सोर्सिंग की भी आवश्यकता है"। किसी भी मामले में, आपके पास सही विचार है - उत्पाद सेवा को समय के साथ परिवर्तनों पर नज़र रखने के लिए ज़िम्मेदार होना चाहिए, न कि डाउनस्ट्रीम सेवाओं को।

— फिल सैंडलर

1

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

— सव्वा क्लीथस

1

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

— फिल सैंडलर

2

यह कहना बहुत मुश्किल है कि एक समाधान दूसरे से बेहतर है। समाधान # 2 और # 3 में से किसी एक को चुनना अन्य कारकों पर निर्भर करता है (कैश अवधि, स्थिरता सहिष्णुता, ...)

मेरे 2 सेंट:

कैश अमान्य होना कठिन हो सकता है लेकिन समस्या कथन में उल्लेख किया गया है कि उत्पाद सूची शायद ही कभी बदलती है। यह तथ्य उत्पाद डेटा को कैशिंग के लिए एक अच्छा उम्मीदवार बनाते हैं

समाधान # 1 (NOK)

डेटा को कई प्रणालियों में दोहराया गया है

समाधान # 2 (ठीक है)

मजबूत स्थिरता प्रदान करता है
केवल तभी काम करता है जब उत्पाद सेवा अत्यधिक उपलब्ध हो और अच्छा प्रदर्शन प्रदान करे
यदि ईमेल सेवा एक सारांश (बहुत सारे उत्पादों के साथ) तैयार करती है, तो समग्र प्रतिक्रिया समय लंबा हो सकता है

समाधान # 3 (जटिल लेकिन पसंदीदा)

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

— सुधीर
स्रोत

1

सामान्यतया, मैं उन दो सेवा के बीच अस्थायी युग्मन के कारण विकल्प 2 के खिलाफ दृढ़ता से सिफारिश करूंगा (जब तक कि इन सेवाओं के बीच संचार सुपर स्थिर नहीं है, और बहुत अक्सर नहीं)। टेम्पोरल कपलिंग वह है जो आप के रूप में वर्णन करते हैं this makes B and C dependant upon A (at all times), और इसका मतलब है कि अगर ए नीचे है या बी या सी से अप्राप्य है, तो बी और सी अपने कार्य को पूरा नहीं कर सकते हैं।

मैं व्यक्तिगत रूप से मानता हूं कि दोनों विकल्पों 1 और 3 में ऐसी परिस्थितियां हैं जहां वे वैध विकल्प हैं।

यदि ए और बी और सी के बीच संचार बहुत अधिक है, या घटना में जाने के लिए आवश्यक डेटा की मात्रा काफी बड़ी है, तो यह चिंता का विषय है, तो विकल्प 3 सबसे अच्छा विकल्प है, क्योंकि नेटवर्क पर बोझ बहुत कम है , और संदेश का आकार घटने के साथ संचालन की विलंबता कम हो जाएगी। यहाँ विचार करने के लिए अन्य चिंताएँ हैं:

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

विकल्प 1 कुछ ऐसा नहीं है जिसे मैं खारिज कर दूंगा। युग्मन की समान मात्रा है, लेकिन विकास-वार यह करना आसान है (विशेष कार्यों की कोई आवश्यकता नहीं है), और डोमेन की स्थिरता का मतलब यह होना चाहिए कि ये अक्सर नहीं बदलेंगे (जैसा कि मैंने पहले ही उल्लेख किया है)।

एक अन्य विकल्प मैं सुझाता हूं कि 3 से थोड़ी भिन्नता है, जो स्टार्ट-अप के दौरान प्रक्रिया को चलाने के लिए नहीं है, लेकिन इसके बजाय B और C पर "ProductAdded और" ProductDetailsChanged "इवेंट देखें, जब उत्पाद सूची में कोई परिवर्तन होता है। ए में। इससे आपकी तैनाती और तेज़ हो जाएगी (और यदि आपको कोई समस्या मिल जाए तो समस्या / बग को ठीक करना आसान होगा)।

संपादित करें 2020-03-03

एकीकरण दृष्टिकोण निर्धारित करते समय मेरे पास प्राथमिकताओं का एक विशिष्ट क्रम है:

संगति की लागत क्या है? क्या हम A में बदली हुई चीजों के बीच असंगतता के कुछ मिलीसेकेंड को स्वीकार कर सकते हैं और उन्हें B & C में परिलक्षित किया जा सकता है?
क्या आपको समय-समय पर प्रश्नों (जिसे लौकिक प्रश्न भी कहा जाता है) की आवश्यकता है?
क्या डेटा के लिए सच्चाई का कोई स्रोत है? एक सेवा जो उनका मालिक है और उसे अपस्ट्रीम माना जाता है?
अगर सच का मालिक / एकल स्रोत है तो क्या वह स्थिर है? या क्या हम बार-बार टूटने वाले परिवर्तनों को देखने की उम्मीद करते हैं?

यदि असंगति की लागत अधिक है, (मूल रूप से ए और बी में उत्पाद के साथ संगत उत्पाद डेटा को जल्द से जल्द संगत करने की आवश्यकता है), तो यूएवी अप्रतिस्पर्धीता स्वीकार करने की आवश्यकता से नहीं बच सकते हैं, और एक तुल्यकालिक अनुरोध कर सकते हैं (जैसे एक वेब डेटा को लाने के लिए B & C से A तक / बाकी अनुरोध)। जागरूक रहें! यह अभी भी व्यवहारिक रूप से सुसंगत नहीं है, लेकिन असंगतता के लिए सिर्फ विंडोज़ को कम करता है। यदि आप पूरी तरह से, सकारात्मक रूप से तुरंत सुसंगत होना चाहते हैं, तो आपको अपनी सेवा सीमाओं को पुनः प्राप्त करने की आवश्यकता है। हालांकि, मैं बहुत दृढ़ विश्वास है कि यह एक समस्या नहीं होनी चाहिए। अनुभव से, यह वास्तव में अत्यंत दुर्लभ है कि कंपनी असंगतता के कुछ सेकंड को स्वीकार नहीं कर सकती है, इसलिए आपको समकालिक अनुरोध करने की आवश्यकता नहीं होनी चाहिए।

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

यदि आपको समय में एक बिंदु की आवश्यकता नहीं है, और डेटा का एक स्पष्ट, एकल स्वामी नहीं है (जो कि मेरे प्रारंभिक उत्तर में मैंने आपके प्रश्न के आधार पर यह मान लिया था), तो एक बहुत ही उचित पैटर्न का प्रतिनिधित्व करना होगा उत्पाद की प्रत्येक सेवा में अलग से। जब आप उत्पादों के लिए डेटा अपडेट करते हैं, तो आप हर एक के समानांतर वेब अनुरोध करके समानांतर में A, B और C को अपडेट करते हैं, या आपके पास एक कमांड API है जो प्रत्येक, A, B और C. B & C में से प्रत्येक को कई कमांड भेजते हैं। अपना काम करने के लिए डेटा का स्थानीय संस्करण, जो बासी हो सकता है या नहीं भी हो सकता है। यह ऊपर दिए गए विकल्पों में से कोई भी नहीं है (हालाँकि इसे विकल्प 3 के करीब बनाया जा सकता है), क्योंकि A, B और C में डेटा भिन्न हो सकता है, और उत्पाद का "पूरा" तीनों डेटा की एक संरचना हो सकती है सूत्रों का कहना है।

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

यदि आपके पास एक स्पष्ट स्वामी है, तो एक कंट्रास्ट के साथ जो स्थिर होने की उम्मीद है, सबसे अच्छा विकल्प विकल्प 1 होगा; एक आदेश में सभी आवश्यक जानकारी होगी और फिर बी और सी घटना में डेटा का उपयोग करके अपना कार्य करेंगे।

यदि अनुबंध आपके विकल्प 3 का अनुसरण करने या बदलने के लिए अक्सर उत्तरदायी होता है, तो उत्पाद डेटा प्राप्त करने के लिए वेब अनुरोधों पर वापस आना वास्तव में एक बेहतर विकल्प है, क्योंकि कई संस्करणों को बनाए रखना बहुत आसान है। तो बी उत्पाद के v3 पर एक अनुरोध करेगा।

— सववस क्लेन्थस
स्रोत

हाँ, मैं सहमत हूँ। जबकि ProductAddedया ProductDetailsChangedट्रैकिंग उत्पाद सूची में परिवर्तन हम चाहते हैं कि डेटा किसी तरह से डेटाबेस के बीच सिंक्रनाइज़ रखने के लिए, मामले की घटनाओं पुनः बजाया जाता है में जरूरत की जटिलता जोड़ सकते हैं और हम अतीत से पहुँच सूची डेटा की जरूरत है।

— 12

@ मेरे साथ मैंने कुछ मान्यताओं पर विस्तार करने के उत्तर को अद्यतन किया जो मैंने किए।

— सव्वस क्लींथस