पुस्तक "माइक्रोसर्विसेस। विकास और रिफैक्टिंग पैटर्न »

हाय, हब्रोज़ितेली! यदि लंबे समय से यह आपको लगता है कि आपकी कंपनी में सभी विकास और परिनियोजन बेहद धीमा हो गया है - माइक्रोसिस्टवर्क वास्तुकला पर जाएं। यह किसी भी जटिलता के अनुप्रयोगों के निरंतर विकास, वितरण और तैनाती प्रदान करता है।

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

हम आपको स्वयं को "माइक्रोसॉफ़्ट आर्किटेक्चर में लेनदेन प्रबंधन" मार्ग से परिचित कराने की पेशकश करते हैं।

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

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

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

4.1.1। माइक्रोसिस्टवर्क वास्तुकला और वितरित लेनदेन की आवश्यकता

कल्पना करें कि आप FTGO में एक डेवलपर हैं और createOrder () सिस्टम ऑपरेशन को लागू करने के लिए जिम्मेदार हैं। जैसा कि अध्याय 2 में वर्णित है, इस ऑपरेशन को यह सुनिश्चित करना होगा कि ग्राहक ऑर्डर दे सकता है, ऑर्डर विवरण की जांच कर सकता है, ग्राहक के बैंक कार्ड को अधिकृत कर सकता है और डेटाबेस में ऑर्डर रिकॉर्ड बना सकता है। एक अखंड आवेदन में इन कार्यों का कार्यान्वयन अपेक्षाकृत सरल होगा। आदेश को सत्यापित करने के लिए आवश्यक सभी डेटा तैयार और उपलब्ध हैं। इसके अलावा, ACID लेनदेन का उपयोग डेटा स्थिरता सुनिश्चित करने के लिए किया जा सकता है। आप केवल createOrder () सेवा पद्धति के लिए @Transactional एनोटेशन निर्दिष्ट कर सकते हैं।

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

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

4.1.2। वितरित लेनदेन के मुद्दे

कई सेवाओं, डेटाबेस या संदेश दलालों के बीच डेटा स्थिरता सुनिश्चित करने के लिए पारंपरिक दृष्टिकोण वितरित लेनदेन का उपयोग है। वितरित लेनदेन प्रबंधन के लिए वास्तविक मानक X / Open XA है ( en.wikipedia.org/wiki/XA देखें)। XA मॉडल दो-चरण प्रतिबद्ध (2PC) का उपयोग करता है ताकि यह सुनिश्चित किया जा सके कि लेनदेन में सभी परिवर्तन सहेजे गए हैं या वापस रोल किए गए हैं। इसके लिए XA मानक का पालन करने के लिए डेटाबेस, संदेश ब्रोकर, डेटाबेस ड्राइवर और मैसेजिंग API की आवश्यकता होती है, और वैश्विक XA लेन-देन पहचानकर्ताओं को वितरित करने वाले एक इंटरप्रोसेस संचार तंत्र की भी आवश्यकता होती है। अधिकांश संबंधपरक डेटाबेस एक्सए संगत हैं, जैसा कि कुछ संदेश दलाल हैं। उदाहरण के लिए, एक जावा ईई-आधारित एप्लिकेशन जेटीए का उपयोग करके वितरित लेनदेन कर सकता है।


उनकी सादगी के बावजूद, वितरित लेनदेन में कई समस्याएं हैं। कई आधुनिक प्रौद्योगिकियां, जैसे कि NoSQL डेटाबेस जैसे MongoDB और Cassandra, उनका समर्थन नहीं करते हैं। वितरित लेनदेन को कुछ आधुनिक संदेश दलालों जैसे कि RabbitMQ और Apache Kafka द्वारा समर्थित नहीं है। इसलिए, यदि आप वितरित लेनदेन का उपयोग करने का निर्णय लेते हैं, तो कई आधुनिक उपकरण आपके लिए उपलब्ध नहीं होंगे।

वितरित लेनदेन के साथ एक और समस्या यह है कि वे सिंक्रोनस आईपीसी का एक रूप हैं, जो उपलब्धता को प्रभावित करता है। वितरित लेनदेन के लिए प्रतिबद्ध होने के लिए, इसमें शामिल सभी सेवाएं सुलभ होनी चाहिए। जैसा कि अध्याय 3 में वर्णित है, सिस्टम एक्सेसिबिलिटी सभी लेनदेन प्रतिभागियों की पहुंच का एक उत्पाद है। यदि 99.5% उपलब्धता वाली दो सेवाएं वितरित लेनदेन में भाग लेती हैं, तो कुल उपलब्धता 99% होगी, जो बहुत कम है। प्रत्येक अतिरिक्त सेवा उपलब्धता की डिग्री को कम करती है। एरिक ब्रेवर ने सीएपी प्रमेय तैयार किया, जिसमें कहा गया है कि एक प्रणाली में निम्नलिखित तीन गुणों में से केवल दो हो सकते हैं: स्थिरता, पहुंच और विभाजन प्रतिरोध (en.wikipedia.org/wiki/CAP_ प्रमेय)। आज, आर्किटेक्ट सस्ती प्रणालियों का पक्ष लेते हैं, निरंतरता का त्याग करते हैं।

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

4.1.3। डेटा स्थिरता बनाए रखने के लिए स्टोरीटेलिंग टेम्पलेट का उपयोग करें

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

कहानी का खाका

स्थानीय लेनदेन के अनुक्रम का उपयोग कर सेवाओं के बीच डेटा स्थिरता सुनिश्चित करता है जो अतुल्यकालिक संदेशों का उपयोग करके समन्वित होते हैं। Microservices.io/patterns/data/saga.html देखें।

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

विवरण में ACID लेनदेन से कई महत्वपूर्ण अंतर हैं। सबसे पहले, उनके पास अलगाव की कमी है (इस पर और अधिक के लिए, खंड 4.3 देखें)। इसके अलावा, चूंकि प्रत्येक स्थानीय लेनदेन कहानी को वापस लेने के लिए अपने परिवर्तनों को पकड़ लेता है, इसलिए आपको क्षतिपूर्ति लेनदेन का उपयोग करना होगा, जिसकी चर्चा हम इस खंड में बाद में करेंगे। एक कहानी उदाहरण पर विचार करें।

कथा उदाहरण: एक आदेश बनाना

इस अध्याय में, हम एक उदाहरण (चित्र। 4.2) के रूप में क्रिएट ऑर्डर कथा का उपयोग करते हैं। यह createOrder () ऑपरेशन को कार्यान्वित करता है। पहला स्थानीय लेनदेन बाहरी ऑर्डर निर्माण अनुरोध द्वारा ट्रिगर किया गया है। शेष पांच लेनदेन एक के बाद एक शुरू हो रहे हैं।


इस कथा में निम्नलिखित स्थानीय लेनदेन शामिल हैं।

1. आदेश सेवा। राज्य APPROVAL_PENDING के साथ एक आदेश बनाता है।

2. सेवा उपभोक्ता। जाँच करता है कि ग्राहक आदेश दे सकता है या नहीं।

3. रसोई सेवा। आदेश का विवरण जांचता है और स्थिति CREATE_PENDING के साथ एक अनुरोध बनाता है।

4. लेखा सेवा। ग्राहक के बैंक कार्ड को अधिकृत करता है।

5. रसोई सेवा। AWAITING_ACCEPTANCE के लिए एक आवेदन की स्थिति को बदलता है।

6. सेवा आदेश। APPROVED को ऑर्डर की स्थिति बदल देता है।

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

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

नैरेटिव वापस परिवर्तनों को रोल करने के लिए ऑफसेट लेनदेन का उपयोग करते हैं

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

मान लीजिए कि कहानी में लेनदेन (n + 1) विफल हो गया। पिछले एन लेनदेन के परिणामों को बेअसर करना आवश्यक है। एक वैचारिक स्तर पर, इन तिवारी चरणों में से प्रत्येक की अपनी क्षतिपूर्ति लेनदेन सीआई है, जो तिवारी के प्रभाव को रद्द करता है। पहले n चरणों के प्रभाव के लिए क्षतिपूर्ति करने के लिए, कथा को प्रत्येक लेनदेन को उल्टे क्रम में निष्पादित करना होगा। अनुक्रम इस तरह दिखता है: T1 ... Tn, Cn ... C1 (चित्र। 4.3)। इस उदाहरण में, चरण Tn + 1 विफल रहता है, जिसे चरण T1 ... Tn को रद्द करने की आवश्यकता होती है।


कथा मूल लोगों के लिए रिवर्स ऑर्डर में प्रतिपूरक लेनदेन करती है: Cn ... C1। यहां, एक ही अनुक्रमिक निष्पादन तंत्र तिवारी के मामले में संचालित होता है। सीआई की समाप्ति को सीआई - 1 शुरू करना चाहिए।

उदाहरण के लिए, क्रिएट ऑर्डर की कथा लें। यह कई कारणों से विफल हो सकता है।

1. ग्राहक के बारे में गलत जानकारी, या ग्राहक को आदेश बनाने की अनुमति नहीं है।

2. रेस्तरां के बारे में गलत जानकारी, या रेस्तरां आदेश को स्वीकार करने में सक्षम नहीं है।

3. ग्राहक के बैंक कार्ड को अधिकृत करने में असमर्थता।

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


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

यह समझने के लिए कि कैसे प्रतिपूरक लेनदेन का उपयोग किया जाता है, ऐसी स्थिति की कल्पना करें जिसमें ग्राहक के बैंक कार्ड का प्राधिकरण विफल हो जाता है। इस मामले में, कथा निम्नलिखित स्थानीय लेनदेन करती है।

1. आदेश सेवा। राज्य APPROVAL_PENDING के साथ एक आदेश बनाता है।

2. सेवा उपभोक्ता। जाँच करता है कि ग्राहक आदेश दे सकता है या नहीं।

3. रसोई सेवा। आदेश का विवरण जांचता है और स्थिति CREATE_PENDING के साथ एक अनुरोध बनाता है।

4. लेखा सेवा। ग्राहक के बैंक कार्ड को अधिकृत करने का असफल प्रयास करता है।

5. रसोई सेवा। CREATE_REJECTED को एप्लिकेशन की स्थिति बदल देता है।

6. सेवा आदेश। REJECTED को ऑर्डर की स्थिति में परिवर्तन।

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

लेखक के बारे में

क्रिस रिचर्डसन एक्शन (मैनिंग, 2006) में POJOs के डेवलपर, वास्तुकार और लेखक हैं, जो बताता है कि स्प्रिंग और हाइबरनेट फ्रेमवर्क का उपयोग करके उद्यम स्तर के जावा अनुप्रयोगों का निर्माण कैसे किया जाता है। वह जावा चैंपियन और जावाऑन रॉक स्टार की मानद उपाधियों को धारण करता है।

क्रिस ने CloudFoundry.com के मूल संस्करण को विकसित किया, जो कि Amazon EC2 के लिए जावा PaS प्लेटफ़ॉर्म का प्रारंभिक कार्यान्वयन है।

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

»पुस्तक की अधिक जानकारी प्रकाशक की वेबसाइट पर उपलब्ध है
» सामग्री
» अंश

फेरीवालों के लिए कूपन पर 25% की छूट - माइक्रोसैसवर्क पैटर्न
पुस्तक के पेपर संस्करण के भुगतान पर, एक इलेक्ट्रॉनिक पुस्तक ई-मेल द्वारा भेजी जाती है।