🌿 🐵 💅🏽 ऑर्केस्ट्रेटेड गाथा या प्रति सेवा पैटर्न के साथ डेटाबेस में सेवाओं में व्यापार लेनदेन का निर्माण कैसे करें 🚾 👩🏾‍✈️ 🖕

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

मैं आपको यह बताना चाहता हूं कि हमने माइक्रोसवर्क आर्किटेक्चर की चुनौतियों में से एक को कैसे हल किया - डेटाबेस प्रति सेवा पैटर्न का उपयोग करके निर्मित सेवाओं के बुनियादी ढांचे में व्यापार लेनदेन का संचालन करना। मैंने इस विषय पर हाई लोड + साइबेरिया 2018 सम्मेलन में एक प्रस्तुति दी।

सिद्धांत। जितना संभव हो उतना कम

मैं सगा के सिद्धांत का विस्तार से वर्णन नहीं करूंगा। मैं आपको केवल एक संक्षिप्त परिचय दूंगा ताकि आप संदर्भ को समझ सकें।

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

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

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

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

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

व्यावसायिक महत्वपूर्ण डेटा के लिए निर्भर डेटा परिवर्तन प्रदान करें
एक सख्त आदेश सेट करने में सक्षम होना;
एक सौ प्रतिशत स्थिरता का निरीक्षण करें - दुर्घटनाओं के मामले में भी डेटा का समन्वय करें;
सभी स्तरों पर लेनदेन के संचालन की गारंटी।

उपरोक्त आवश्यकताओं के तहत, एक आर्केस्ट्रा गाथा के रूप में समाधान सबसे उपयुक्त है।

एक पीजी सागा सेवा के रूप में एक आर्केस्ट्रा गाथा का कार्यान्वयन

यह पीजी सागा सेवा जैसा दिखता है।

नाम में PG, क्योंकि तुल्यकालिक PostgreSQL का उपयोग सेवा भंडार के रूप में किया जाता है। और क्या है अंदर:

एपीआई;
निष्पादक;
चेकर;
healthchecker;
कम्पेसाटर।

आरेख सगाओं के सेवा स्वामी को भी दिखाता है, और नीचे वे सेवाएँ हैं जो गाथा के चरणों का प्रदर्शन करेंगी। उनके पास अलग-अलग रिपोजिटरी हो सकते हैं।

यह कैसे काम करता है

वीएएस पैकेज खरीदने के उदाहरण पर विचार करें। वीएएस (मूल्य वर्धित सेवाएं) - विज्ञापन प्रचार के लिए भुगतान की गई सेवाएं।

सबसे पहले, गाथा के सेवा मालिक को गाथा सेवा में गाथा के निर्माण को पंजीकृत करना होगा

उसके बाद, यह पहले से ही पेलोड के साथ एक सागा वर्ग उत्पन्न करता है।

इसके अलावा, पहले से ही sag सेवा में, निष्पादक स्टोर से पहले से बनाई गई गाथा कॉल को उठाता है और इसे चरणों में निष्पादित करना शुरू करता है। हमारे मामले में पहला कदम प्रीमियम सदस्यता खरीदना है। इस समय, बिलिंग सेवा में पैसा आरक्षित है।

फिर उपयोगकर्ता की सेवा में वीएएस संचालन लागू होते हैं।

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

दुर्घटना

किसी भी सेवा में दुर्घटनाएं हो सकती हैं, लेकिन उनके लिए तैयार करने के तरीके पर अच्छी तरह से ज्ञात चालें हैं। एक वितरित प्रणाली में, इन तकनीकों के बारे में जानना महत्वपूर्ण है। उदाहरण के लिए, सबसे महत्वपूर्ण सीमाओं में से एक यह है कि नेटवर्क हमेशा विश्वसनीय नहीं होता है। स्वीकृतियां जो वितरित सिस्टम में सहभागिता की समस्याओं को हल करेंगी:

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

लेनदेन मुआवजा: यह कैसे काम करता है

प्रत्येक सकारात्मक लेनदेन के लिए, हमें रिवर्स एक्शन का वर्णन करना चाहिए: कुछ गलत होने पर कदम का एक व्यापारिक परिदृश्य।

हमारे कार्यान्वयन में, हम निम्नलिखित मुआवजा परिदृश्य प्रदान करते हैं:

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

हमारे उदाहरण में, यह इस तरह दिखेगा:

VAS पैकेज बंद करें।

उपयोगकर्ता कार्रवाई रद्द करें।

हम धन के आरक्षण को रद्द करते हैं।

अगर मुआवजा काम नहीं करेगा तो क्या करें

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

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

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

एक और दुर्घटना परिदृश्य

कल्पना करें कि हम उसी प्रीमियम सदस्यता को फिर से कर रहे हैं।

हम वीएएस पैकेज खरीदते हैं और पैसे आरक्षित करते हैं।

हम उपयोगकर्ता के लिए सेवाएं लागू करते हैं।

हम VAS पैकेज बनाते हैं।

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

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

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

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

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

सागा पीढ़ी के तर्क का एक उदाहरण जिसे क्लाइंट लाइब्रेरी में छिपाया जा सकता है

यह अलग तरीके से किया जा सकता है, लेकिन मैं निम्नलिखित दृष्टिकोण का प्रस्ताव करता हूं।

हमें अनुरोध आईडी मिलती है जिसके द्वारा हमें गाथा बनानी चाहिए।
हम sag सेवा में जाते हैं, इसकी विशिष्ट पहचानकर्ता प्राप्त करते हैं, इसे बिंदु 1 से अनुरोध आईडी के साथ संयोजन में स्थानीय भंडारण में सहेजते हैं।
गाथा सेवा में पेलोड के साथ गाथा चलाएँ। एक महत्वपूर्ण बारीकियों: मैं उस सेवा के स्थानीय संचालन का प्रस्ताव करता हूं जो गाथा को डिजाइन करती है, गाथा के पहले चरण के रूप में।
एक निश्चित दौड़ है जब गाथा सेवा इस चरण (बिंदु 3) का प्रदर्शन कर सकती है, और हमारी पीठ, जो गाथा के निर्माण की पहल करती है, वह भी प्रदर्शन करेगी। ऐसा करने के लिए, हम हर जगह बेतरतीब संचालन करते हैं: एक व्यक्ति इसे करता है, और दूसरा कॉल केवल "ओके" प्राप्त करता है।
हम पहले चरण (बिंदु 4) को कहते हैं और उसके बाद ही हम उस ग्राहक को जवाब देते हैं जिसने यह कार्रवाई शुरू की है।

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

यह सब कैसे जांचना है

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

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

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

कुल:

अधिक इकाई परीक्षण लिखें;
एकीकरण परीक्षण लिखें;
अंत-से-अंत परीक्षण लिखें।

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

सीडीसी का सार क्या है? एक सेवा है जो एक अनुबंध प्रदान करती है। उसके पास एक एपीआई है - यह एक प्रदाता है। और एक और सेवा है जो एपीआई को कॉल करती है, अर्थात, अनुबंध - उपभोक्ता का उपयोग करती है।

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

एविटो ने माइक्रोसर्विसेज फ्रोल क्रिकचकोव के परीक्षण के लिए सीडीसी दृष्टिकोण को कैसे लागू किया, इस बारे में RIT ++ में बात की। एब्सट्रैक्ट्स वेबसाइट बैकएंड.कॉन्फ़ पर पाए जा सकते हैं - मेरी सलाह है कि आप खुद को परिचित करें।

साग के प्रकार

फ़ंक्शन कॉल के क्रम में

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

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

फ़ंक्शन कॉल का परिणाम प्राप्त करके

a) सिंक्रोनस - फ़ंक्शन का परिणाम तुरंत ज्ञात होता है;
बी) अतुल्यकालिक - फ़ंक्शन तुरंत "ओके" लौटाता है, और परिणाम बाद में ग्राहक सेवा से शिग सर्विस एपीआई को कॉलबैक के माध्यम से वापस किया जाता है।

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

सैल स्केलिंग

स्केलिंग आपके द्वारा योजना बनाई गई प्रणाली के आकार पर निर्भर करती है। एकल संग्रहण उदाहरण वाले विकल्प पर विचार करें:

एक गाथा कदम हैंडलर, बैचों के साथ कदम प्रक्रिया;
n हैंडलर, हम एक "कंघी" को लागू करते हैं - हम विभाजन के शेष के लिए कदम उठाते हैं: जब प्रत्येक निष्पादक को अपने कदम मिलते हैं।
n हैंडलर और स्किप लॉक - और भी अधिक कुशल और अधिक लचीला होगा।

और उसके बाद ही, यदि आप पहले से जानते हैं कि आप DBMS में एक सर्वर के प्रदर्शन में भाग लेंगे, तो आपको शार्पिंग - n डेटाबेस इंस्टेंसेस करने की आवश्यकता है जो उनके डेटा सेट के साथ काम करेंगे। शेयरिंग सेवा सेवा एपीआई के पीछे छिपी हो सकती है।

अधिक लचीलापन

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

आपको लॉक की आवश्यकता कब होती है

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

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

यह कैसे करना है? , , , , , - , . . . : , , .

-, , . , , . , , . . — , , .

ACID —

, , . . — durability. . . , . - , - - ,

$Ti reads => other rtransaction writes => Tj (or Ci) writes$

— - , - , , - , . , - , - .

$Ti writes => other transaction reads => Ci writes$

— .

$Ti reads =>other transaction writes =>Tj reads$

, , , , .
, . , , , , , .
.
payload . eventual consistency — , , , . , , , -.

निगरानी

. , . . checker. . , .

(50%, 75%, 95%, 99%), , - .

, — , . . , - . , — .

. , - ( ) . healthchecker endpoint' info (keep-alive) .

. -. -, - , - . , , , end-to-end. - . , , — .
. .

:

, healthchecker, - , . , . .

, . , , . . choreography — - . , choreography- , . choreography , . , . , , , .

. , , . , + .

API

, - - ( API ), , API. API . — . API , , 100% .

, , , , . — , , . .

, , , . ( ) .

, , , , .

. , , .

saga call ID

. API , .

—

- legacy . , ( «» ). « »? - , , , , - , . , , , . , « », , -. . — . , .

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

यदि आपके पास प्रश्न हैं या सागाओं के बारे में अधिक जानने में रुचि रखते हैं, तो टिप्पणियों में लिखें। मुझे जवाब देने में खुशी होगी।

ऑर्केस्ट्रेटेड गाथा या प्रति सेवा पैटर्न के साथ डेटाबेस में सेवाओं में व्यापार लेनदेन का निर्माण कैसे करें