माइक्रोस्कोप के साथ डीबी स्थिरता

Question

माइक्रोस्कोस-आधारित सिस्टम में डीबी स्थिरता प्राप्त करने का सबसे अच्छा तरीका क्या है?

GOTO in Berlin में मार्टिन Fowler microservices और एक "नियम" उन्होंने कहा "प्रति-सेवा" डेटाबेस जिसका अर्थ है कि सेवाओं सीधे एक डीबी "स्वामित्व" कनेक्ट नहीं कर सकता किसी अन्य सेवा द्वारा रखने के लिए किया गया था, के बारे में बात कर रहा था।

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

• एक दृश्यपटल
• एक आदेश प्रबंधन सेवा
• एक वफादारी कार्यक्रम सेवा

अब, एक ग्राहक को खरीदारी अपने दृश्यपटल पर आपके द्वारा जो आदेश प्रबंधन सेवा को कॉल करेगा, जो डीबी में सब कुछ बचाएगा - कोई समस्या नहीं। इस बिंदु पर, वफादारी-कार्यक्रम सेवा के लिए भी एक कॉल होगा ताकि यह आपके खाते से क्रेडिट/डेबिट अंक हो।

अब, जब सबकुछ एक ही डीबी/डीबी सर्वर पर होता है तो यह सब आसान हो जाता है क्योंकि आप एक लेनदेन में सब कुछ चला सकते हैं: यदि वफादारी कार्यक्रम सेवा डीबी को लिखने में विफल रहता है तो हम पूरी चीज को वापस रोल कर सकते हैं।

जब हम कई सेवाओं में डीबी संचालन करते हैं तो यह संभव नहीं है, क्योंकि हम एक कनेक्शन पर भरोसा नहीं करते हैं/एक लेनदेन चलाने का लाभ उठाते हैं। चीजों को सुसंगत रखने और खुशहाल जीवन जीने के लिए सबसे अच्छे पैटर्न क्या हैं?

मैं आपके सुझाव सुनने के लिए उत्सुक हूं! .. और अग्रिम धन्यवाद!

समस्या को फिर से करने के लिए, प्रणाली तीन स्वतंत्र बल्कि संवाद स्थापित हिस्से होते हैं:

Answer 1

यह सुपर अच्छा और सुरुचिपूर्ण है, लेकिन व्यवहार में यह थोड़ा मुश्किल हो जाता है

क्या यह "व्यवहार में" मतलब है कि आप इस तरह से कि अपनी microservices डिजाइन करने के लिए की जरूरत है नियम का पालन करते समय आवश्यक व्यावसायिक स्थिरता पूर्ण हो जाती है:

कि सेवाएं किसी अन्य सेवा द्वारा सीधे डीबी "स्वामित्व" से कनेक्ट नहीं हो सकती हैं।

दूसरे शब्दों में - अपनी जिम्मेदारियों के बारे में कोई धारणा न करें और जब तक आप उस काम को करने का कोई तरीका नहीं ढूंढ लेते, तब तक सीमाओं को बदल दें।

अब, आपके सवाल का:

सबसे अच्छा पैटर्न बातें लगातार रखने के लिए और एक सुखी जीवन जीने के क्या हैं?

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

यदि आप .NET पर चल रहे हैं तो इस तरह की विश्वसनीयता का समर्थन करने वाले बुनियादी ढांचे के कुछ उदाहरण NServiceBus और MassTransit शामिल हैं। पूर्ण प्रकटीकरण - मैं NServiceBus के संस्थापक हूं।

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

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

Answer 2

मैं आमतौर पर microservices के साथ सौदा नहीं है, और यह काम करने के लिए एक अच्छा तरीका नहीं हो सकता है, लेकिन यहाँ एक विचार है : फ्रंटेंड, ऑर्डर-मैनेजमेंट बैकएंड, और वफादारी-प्रोग्राम बैकएंड। अग्रभाग यह सुनिश्चित करना चाहता है कि कुछ राज्य ऑर्डर-मैनेजमेंट बैकएंड और वफादारी-कार्यक्रम बैकएंड दोनों में सहेजे गए हैं।

1. पहले, दृश्यपटल सभी डेटा के साथ अपने स्वयं के डेटाबेस में एक रिकार्ड देता है:

   एक संभव समाधान two-phase commit किसी प्रकार लागू करने के लिए किया जाएगा। इसे फ्रंटेंड रिकॉर्ड पर कॉल करें।

2. फ्रंटेंड एक लेनदेन आईडी के लिए ऑर्डर-मैनेजमेंट बैकएंड से पूछता है, और इसे पूरा करने के लिए उसे जो भी डेटा चाहिए, उसे पास करता है। ऑर्डर-मैनेजमेंट बैकएंड इस डेटा को एक स्टेजिंग क्षेत्र में संग्रहीत करता है, जिसमें इसके साथ एक नया लेनदेन आईडी शामिल होता है और इसे फ्रंटेंड पर लौटाता है।
3. ऑर्डर-प्रबंधन लेनदेन आईडी फ्रंटेंड रिकॉर्ड के हिस्से के रूप में संग्रहीत है।
4. फ्रंटेंड एक लेनदेन आईडी के लिए वफादारी-कार्यक्रम बैकएंड से पूछता है, और इसे पूरा करने के लिए आवश्यक डेटा को पास करता है। वफादारी-कार्यक्रम बैकएंड इस डेटा को एक स्टेजिंग क्षेत्र में संग्रहीत करता है, जिसमें इसके साथ एक नई लेन-देन आईडी शामिल होती है और इसे आगे की ओर लौटती है।
5. वफादारी-कार्यक्रम लेनदेन आईडी फ्रंटेंड रिकॉर्ड के हिस्से के रूप में संग्रहीत है।
6. फ्रंटेंड ऑर्डर-मैनेजमेंट बैकएंड को लेनदेन आईडी से जुड़े लेनदेन को अंतिम रूप देने के लिए बताता है।
7. फ्रंटेंड लॉन्च-प्रोग्राम बैकएंड को लेनदेन आईडी से जुड़े लेनदेन को अंतिम रूप देने के लिए बताता है।
8. फ्रंटेंड इसके फ्रंटएंड रिकॉर्ड को हटा देता है।

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

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

Answer 3

मैं @Udi Dahan के साथ सहमत हूं। बस उसके जवाब में जोड़ना चाहते हैं।

मुझे लगता है कि आपको वफादारी कार्यक्रम के अनुरोध को जारी रखने की आवश्यकता है ताकि यदि यह विफल हो जाए तो यह किसी अन्य बिंदु पर किया जा सकता है। शब्द/ऐसा करने के कई तरीके हैं।

1) वफादारी कार्यक्रम API विफलता पुनर्प्राप्त करने योग्य बनाएं। ऐसा कहने के लिए कि यह अनुरोध जारी रख सकता है ताकि वे खो न जाए और कुछ बाद के बिंदु पर पुनर्प्राप्त (पुनः निष्पादित) किया जा सके।

2) वफादारी कार्यक्रम अनुरोधों को अतुल्यकालिक रूप से निष्पादित करें। यही कहना है, अनुरोध कहीं पहले जारी रखें, फिर सेवा को इस सतत स्टोर से पढ़ने की अनुमति दें। सफलतापूर्वक निष्पादित होने पर केवल स्थिर स्टोर से हटा दें।

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

सभी तीन एक ही चीज़ को पूरा करते हैं। वे अनुरोध को एक सतत स्थान पर ले जाते हैं जहां इसे सफल समापन तक काम किया जा सकता है। अनुरोध कभी खो नहीं जाता है, और एक संतोषजनक राज्य तक पहुंचने तक आवश्यक होने पर पुनः प्रयास किया जाता है।

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

Answer 4

वितरित लेनदेन के लिए भी आप लेनदेन के बीच में दुर्घटनाग्रस्त होने पर "संदेह स्थिति में लेनदेन" प्राप्त कर सकते हैं। यदि आप सेवाओं को बेवकूफ ऑपरेशन के रूप में डिजाइन करते हैं तो जीवन थोड़ा आसान हो जाता है। कोई XA के बिना व्यावसायिक स्थितियों को पूरा करने के लिए प्रोग्राम लिख सकता है। पैट हेलैंड ने "लाइफ बायोन्ड एक्सए" नामक उत्कृष्ट पेपर लिखा है। मूल रूप से दृष्टिकोण दूरस्थ संस्थाओं के बारे में न्यूनतम मान्यताओं के रूप में संभव है। उन्होंने व्यापार प्रक्रियाओं के मॉडल के लिए ओपन नेस्टेड लेनदेन (http://www.cidrdb.org/cidr2013/Papers/CIDR13_Paper142.pdf) नामक एक दृष्टिकोण को भी चित्रित किया। इस विशिष्ट मामले में, खरीद लेनदेन शीर्ष स्तर का प्रवाह होगा और वफादारी और आदेश प्रबंधन अगले स्तर के प्रवाह होंगे। चाल मुआवजा तर्क के साथ बेवकूफ सेवाओं के रूप में granular सेवाओं को तोड़ने के लिए है। तो अगर कोई भी प्रवाह प्रवाह में कहीं भी विफल रहता है, तो व्यक्तिगत सेवाएं इसके लिए क्षतिपूर्ति कर सकती हैं। तो उदा। अगर आदेश किसी कारण से विफल रहता है, तो वफादारी उस खरीद के लिए अर्जित बिंदु को घटा सकती है।

अन्य दृष्टिकोण सीएमएल या सीआरडीटी का उपयोग कर अंतिम स्थिरता का उपयोग करके मॉडल करना है। मैंने वास्तविक जीवन में सीएएम का उपयोग करके हाइलाइट करने के लिए एक ब्लॉग लिखा है - http://shripad-agashe.github.io/2015/08/Art-Of-Disorderly-Programming मई यह आपकी मदद करेगा।