डेटा दोहराव के बिना माइक्रोसॉफ़्ट


20

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

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

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

इसे लागू करने का सही / सर्वोत्तम तरीका क्या है?


5
सूक्ष्म सेवाओं के विरोधाभास में आपका स्वागत है। जो चीजों को सरल बनाने के लिए प्रकट होता है वह वास्तव में चीजों को अधिक जटिल बना सकता है।
रॉबर्ट हार्वे

"सही" तरीका वही है जो हमेशा रहा है: उन चीजों को करने का एक तरीका है जो आपके विशिष्ट उद्देश्यों के लिए सबसे अच्छा है।
रॉबर्ट हार्वे

1
@RobertHarvey यह हमेशा मामला है, लेकिन मैं पाठ्यपुस्तक microservices तरीका समझने की कोशिश कर रहा हूँ। एक बार जब मैं समझ गया कि इसे एक आदर्श दुनिया में कैसे काम करना चाहिए तो मैं इसे अपने उपयोग के मामले में फिट होने के लिए खुशी से बदलूंगा।
गेरेट एंडरसन

1
लेकिन आपकी दक्षता के संदर्भ में आपका प्रश्न तैयार करना, जो एक गैर-कार्यात्मक सॉफ़्टवेयर आवश्यकता है। जिस तरह से आप दक्षता की समस्या को हल करते हैं वह डेटाबेस से सीधे पूछकर होता है।
रॉबर्ट हार्वे

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

जवाबों:


10

मैं पूरी तरह से चूक गया जहाँ आपको डुप्लिकेट करने की आवश्यकता है।

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

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

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

तो हर मामले में, जब आप नवीनतम उपयोगकर्ता जानकारी चाहते हैं तो आप उपयोगकर्ता जानकारी सेवा से पूछते हैं।


@ संत: क्या आप इस बारे में अधिक विशिष्ट हो सकते हैं कि आपके सिस्टम में किस तरह का दोहराव हो रहा है?
रॉबर्ट हार्वे

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

अगर यह दोनों को प्रबंधित करता है तो यह डीबी का उपयोग करेगा। आप उपयोगकर्ता जानकारी को इन्वेंट्री टेबल में कॉपी नहीं करते हैं। आप इसे एक विदेशी कुंजी देते हैं। उपयोगकर्ता ID सेवाओं में समान कार्य कर रही है। बस इसे अद्वितीय बनाते हैं।
candied_orange

It seems counter-intuitive to move from a single relational database where I could get the inventory data and the user data with a joinध्यान रखें कि "आदर्श रूप से" प्रति सेवा एक स्टोर (या अधिक!) है। तो, "सीमाओं" के बीच "जॉइन" जैसा कुछ भी नहीं है। कारण सरल है, DB सेवाओं के बीच युग्मन उत्पन्न करता है। @CandiedOrange के सुझाव के विपरीत, मुझे लगता है कि हम न्यूनतम डेटा को एक सेवा से दूसरी सेवा में डुप्लिकेट कर सकते हैं। मैं ऐसे डेटा का जिक्र कर रहा हूं जो बदलने की संभावना नहीं है। यदि यह डूप्स दक्षता और प्रदर्शन में सुधार करता है (और दोनों की आवश्यकता होती है) "पेशेवरों" शायद "विपक्ष" को बंद कर देगा
लैवि

@GeraintAnderson मेरा मतलब है, अगर आपको दक्षता की आवश्यकता है (जो कि एक गैर-कार्यात्मक आवश्यकता है), तो ऐसा करने के तरीके हैं। यानी इन्वेंटरी सर्विस (जैसे 10 तत्व) से डेटा के पेज मांगे जाते हैं, प्रत्येक पेज को लेते हैं और उस पेज का इस्तेमाल यूजर सर्विस से डेटा मांगने के लिए करते हैं, और अंत में एकत्र करते हैं। इस तरह आप स्वतंत्र सेवाओं के समानता का लाभ उठाते हुए अपनी सीमाओं को बनाए रखते हैं। फिर भी, परेशान न हों जब तक कि आपने इसे उस एप्लिकेशन की वास्तविक अड़चन के रूप में पहचान नहीं लिया है जिसे हल किया जाना चाहिए - 1 सेकंड के अतिरिक्त नौकरी पर एक अतिरिक्त 1/2 सेकंड की प्रतीक्षा करना किसी के लिए भी मायने नहीं रखता है।
डेलीगोथ

11

डेटा डुप्लीकेशन से बचने के लिए मुझे बहुत मुश्किल हो रहा है ...।

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

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


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

1
@AlanSereb इसे बनाए रखना कठिन है, लेकिन कभी-कभी आपके पास कोई अन्य विकल्प नहीं होता है। उदाहरण के लिए, क्या होगा यदि आपको दो डेटाबेस में रहने वाली वस्तुओं के बीच एक एफके बनाने की आवश्यकता है? स्थानीय DB में प्रश्न करते समय स्थिरता सुनिश्चित करने का एकमात्र तरीका, डेटा प्रतिकृति है। एक नज़र डालें: stackoverflow.com/a/4452586/2255491
डेविड डी।

मैं सहमत हूँ। एक और शानदार तरीका यह है कि इवेंट सोर्सिंग रूट लिया जाए। और सभी म्यूटेशन को इवेंट पाइपलाइन के माध्यम से निष्पादित किया जाता है
एलन सेरेब

4

इन्वेंट्री सेवा से अनुरोध किया जाएगा कि वह उन सभी वस्तुओं के आइटम विवरणों को पुनः प्राप्त करें जहां मात्रा 5 से कम है। यह उपयोगकर्ता आईडी सहित एक सूची लौटाएगा। फिर इन्वेंट्री सेवा से प्राप्त उपयोगकर्ता आईडी की सूची के लिए उपयोगकर्ता नाम और संपर्क विवरण प्राप्त करने के लिए उपयोगकर्ताओं की सेवा के लिए एक अलग अनुरोध किया जाएगा।

वास्तव में हाँ।

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

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

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

आपको जिस प्रश्न का उत्तर देने की आवश्यकता है, वह प्रदर्शन और रखरखाव और अन्य "नरम" गुणों के बारे में है।

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

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

यदि आपको स्केलिंग की आवश्यकता नहीं है, तो माइक्रोसर्विस का एक और लाभ है: वे मॉड्यूलर हैं । बेशक, अखंड एप्लिकेशन भी मॉड्यूलर हो सकते हैं, और आपके पास एक सामान्यीकृत डेटाबेस और ... लेकिन व्यवहार में मॉड्यूल के बीच की दीवारें सबसे अच्छी स्थिति में कांच की दीवारों की तरह होती हैं, और सबसे खराब रेत में लाइनें। माइक्रोसिस्टम्स को ठोस स्टील द्वारा अलग किया जाता है।

यदि आपका उपयोगकर्ता सिस्टम शाब्दिक रूप से आग पकड़ता है, तो यह आपके इन्वेंट्री सिस्टम को थोड़ी सी भी प्रभावित नहीं करेगा। आप इस बारे में सुंदर रिपोर्ट नहीं छाप सकते हैं कि किसने क्या स्टॉक किया है, लेकिन ग्राहक ऑर्डर को इस ज्ञान में सुरक्षित रखने में सक्षम होंगे कि स्टॉक किए गए आइटम हैं।

और आप माइक्रोसॉफ़्ट में डेटा की नकल नहीं करते हैं , जितना आप किसी रिलेशनल डेटाबेस (*) में करते हैं। एक रिलेशनल डेटाबेस में आप एक जॉइन कर सकते हैं , और समतुल्य सूची में वर्णित कोड को मर्ज करना है।

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

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

(*) अगर यह एक microservice झुंड में डेटा डुप्लिकेट करने के लिए समझ में आता है तो यह संभवतः समकक्ष रिलेशनल डेटाबेस में समझ में आता है।


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

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

@PeterPompeii कैशिंग के बारे में जोड़ा गया खंड आपकी कुछ चिंताओं को दूर करता है।
ओड्रालिक

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

1
@Brandon प्रतिकृति और कैशिंग के बीच एक और अंतर यह है कि आप कैसे जानते हैं कि अंतर होने पर कौन सा डेटा गलत है। डेटा को मर्ज करने के तरीके पर प्रतिकृति कुछ नियमों को परिभाषित करती है। दूसरी ओर कैशिंग हमेशा होता है : कैश गलत है।
Odalrick
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.